lkml.org 
[lkml]   [2003]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: seq_file and exporting dynamically allocated data
On Sat, 15 Nov 2003 viro@parcelfarce.linux.theplanet.co.uk wrote:
> 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.

I think I now understand better what you mean. And that is not what I
meant. Yes, of course userspace must be able to deal with less data than
what it asked for. I agree.

But I was referring to the complication on the kernel side, whereby if the
data (collectively, all the entries) is more than 1 page then ->stop()
must be called and a page returned to user and then the kernel must build
another page but all it knows is the integer 'offset'. Anything could have
happened to the list (task list in this case) since ->stop() routine
dropped the spinlock. So, it is not obvious from which position to
start building the data for the new page.

Looking at mm/slab.c implementation I see that it just walks the integer
distance from the head of the list. Simple but not 100% correct, I think.
I.e. it can miss an entry if the list has changed between two read(2)s.

Kind regards
Tigran

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans