Messages in this thread | | | Date | Sat, 15 Nov 2003 20:14:46 +0000 | From | viro@parcelfa ... | Subject | Re: seq_file and exporting dynamically allocated data |
| |
On Sat, Nov 15, 2003 at 07:49:43PM +0000, Tigran Aivazian wrote: > Dear Harald, > > The thing to be aware of is that seq API is limited to 1 page of data per > read(2) call. Some people loudly proclaim "seq API is unlimited, unlike > the old /proc formalism which was limited to 1 page" but they are > quiet about 1-page limitation for a single read(2) (due to hardcoded > kmalloc(size) in seq_file.c). Why is this important? Because if your
What? It will happily return more than 1 page if you get an entry longer than that.
What hardcoded kmalloc(size)?
> ->start/stop routines take/drop some spinlocks then you have to know your > position and re-verify it on the next read(2) if your data is more than 1 > page and thus could not be read atomically (i.e. while holding the > spinlocks).
If you mean that read(2) can decide to return less than full user buffer even though more data is available - tough, that's something userland *must* be able to deal with.
Especially on syntetic and potentially large files - the only alternative would be immediate DoS on OOM. Regardless of the implementation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |