Re: seq_file and exporting dynamically allocated data

[viro]

On Sat, Nov 15, 2003 at 08:41:45PM +0000, Tigran Aivazian wrote:
> in fs/seq_file.c:seq_read()
> 
>         if (!m->buf) {
>                 m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);

... and below
                m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);

> are you saying that it is possible for userspace to request, say, 256K and 
> say 250K of available data could be returned (with seq_file API) on a 
> single read(2) call? I thought this is impossible and hence in the 

> So, as soon as ->show() is asked to display an element which didn't fit in
> the m->buf page it returns -1 and so the user gets a page (or almost a
> page, i.e.  as many entries as fit in there).

a) it's not a page; if any ->show() will need more, buffer will grow.

b) unless you are willing to allocate 250Kb per read(), you *can't* do
what you are asking for.  Regardless of implementation.  Which is an
immediate DoS (again, regardless of implementation).

read() is not atomic.  Never had been.  With seq_file you are guaranteed
that what you get will consist of entire entries (IOW, if previous read()
had ended inside the entry, the rest will be preserved for the next read()).
There are no stronger warranties and there never had been.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/