[lkml]   [2009]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] net: add dataref destructor to sk_buff
    On 11/14/2009 05:04 AM, David Miller wrote:
    > From: Gregory Haskins<>
    > Date: Fri, 13 Nov 2009 20:33:35 -0500
    >> Well, not with respect to the overall protocol, of course not. But with
    >> respect to the buffer in question, it _has_ to be. Or am I missing
    >> something?
    > sendfile() absolutely, and positively, is not.
    > Any entity can write to the pages being send via sendfile(), at will,
    > and those writes will show up in the packet stream if they occur
    > before the NIC DMA's the memory backed by those pages into it's
    > buffer.
    > There is zero data synchronization whatsoever, we don't lock the
    > pages, we don't block their usage while they are queued up in the
    > socket send queue, nothing like that.

    But it must maintain a reference count on the page being dmaed and drop
    it only after dma is complete. Otherwise we risk the page being
    recycled and arbitrary memory sent out on the wire; and an application
    can trivially cause this by truncate()ing a sendfile.

    > The user returns long before it every hits the wire and there is zero
    > "notification" to the user that the pages in question for the
    > sendfile() request are no longer in use.

    The put_page() is a notification except it doesn't reach the caller.
    Gregory's patch (and previous shared info destructor patches) is an
    attempt to make it reach the caller, IIUC.

    error compiling committee.c: too many arguments to function

     \ /
      Last update: 2009-11-16 18:11    [W:0.032 / U:0.104 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site