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    [W:0.019 / U:241.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site