lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 13:36:23 -0500
From:	Gregory Haskins <>
To:	"Michael S. Tsirkin" <>
Subject: Re: [RFC PATCH] net: add dataref destructor to sk_buff

Michael S. Tsirkin wrote:
> On Tue, Nov 10, 2009 at 10:45:16AM -0500, Gregory Haskins wrote:
>> I am not a stack expert, but I was under the impression that we use this
>> model for userspace pages today as well using the wmem callbacks in
>> skb->destructor().  If so, I do not see how you could do something like
>> detach a page from a pskb and still expect to have a proper event that
>> delineates the io-completion to the higher layers.
> I think linux only cares about that for accounting purposes (stuff like
> socket sndbuff size). If someone takes over the page, the socket can
> stop worrying about it.

Only if there isn't zero-copy.

>> So the questions are:
>> 1) do we in fact map userspace pages to pskbs today?
> I don't think so.

What about things like sendfile()?  There has to be *some* way to
synchronize with the io-completion event,  I would think.  Whatever that
is, I'd like to tap into it.

>>> which pages?
>> You said that there are paths that get_page() out of shinfo without
>> holding a shinfo reference.
> Without zero copy, application does not care about these,
> they have been allocated by kernel.

Agreed in the non-zero copy case.  I am not yet convinced that we do not
do zero copy in some form, however. Ill have to dig through the code
when I get a chance to confirm.

Kind Regards,

Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)

Powered by blists - more mailing lists