[lkml]   [2001]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: large & fragmented TUX requests

On Thu, 2 Aug 2001, Peter J. Braam wrote:

> I have two basic questions about the code (looking at 2.4.6-3.1)
> 1) input.c
> If a request arrives in multiple pieces, req->proto->parse_message
> returns 0 and read_request is called multiple times. Why is read
> request not overwriting data that was already received?

because the parser uses linear strings. Parsers are one of the main cause
of security problems, so i tried to keep the TUX parser as simple and
robust as possible.

> 2) large requests
> Some of the RPC's I want to handle are for receiving file data. Would
> it make sense when it is known that a large page aligned buffer with
> file data is coming, to simply allocate buffers of the right size (say
> up to 64K max) and point req->req_headers at it?
> In that way I can read the chunk in and later map the pages into a
> file to get it to disk.

there is /proc/sys/net/tux/max_header_len, which you can set to any
(reasonable) size. Right now the interface is kmalloc(), which has a
per-CPU cache so allocation/deallocation is very fast and SMP-friendly.
You can set the value of max_header_len to 64k, but there could be kmalloc
related fragmentation issues. (If you ever encounter this fragmentation
problem then we can cache header buffers within the tux-request cache,
and/or can fall back to vmalloc().)

right now TUX assumes that req_headers is a kmalloc-ed buffer, so you
cannot simply replace the pointer with a page-aligned (and possible
gfp()-allocated) memory buffer.

> There is no standard "recv_file" (ala sendfile) api, right?

there is none at the moment - but TUX does an effective zero-copy
recv_file() for small requests: it takes the raw skbs and parses them, if
the skb is 'simple' (nonfragmented, nonoffsetted). (which they are in 99%
of the cases)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.036 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site