lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 Feb 2019 15:35:39 -0500 From: Jason Baron <jbaron@...mai.com> To: Al Viro <viro@...iv.linux.org.uk>, Rainer Weikusat <rweikusat@...ktalk.net> Cc: netdev@...r.kernel.org Subject: Re: [RFC] nasty corner case in unix_dgram_sendmsg() On 2/26/19 2:03 PM, Al Viro wrote: > On Tue, Feb 26, 2019 at 03:31:32PM +0000, Rainer Weikusat wrote: >> Al Viro <viro@...iv.linux.org.uk> writes: >>> On Tue, Feb 26, 2019 at 06:28:17AM +0000, Al Viro wrote: >> >> [...] >> >> >>>> * if after relocking we see that unix_peer(sk) now >>>> is equal to other, we arrange for wakeup forwarding from other's >>>> peer_wait *and* if that has (likely) succeeded we fail with -EAGAIN. >>>> Huh? >> >> This returns 1 if sending isn't possible at the moment, ie, if the >> process which tries to send has to wait. > > Except that in _this_ case we won't be waiting at all - we'll just > return -EAGAIN (as one could expect, what with no timeout given/left). > So what's the point of forwarding wakeups? IOW, what is it that we > expect to be waiting on sk_sleep(sk)? Note that it won't be this > call of sendmsg(2) (it'll bugger off without any further waiting). > It won't be subsequent calls of sendmsg(2) either - they either > sleep on skb allocation (which has nothing to do with destination) > _or_ they sleep directly on other->peer_wait. And poll(), while it > will be sleeping on sk_sleep(sk), will make sure to set the forwarding > up. > > I understand what the unix_dgram_peer_wake_me() is doing; I understand > what unix_dgram_poll() is using it for. What I do not understand is > what's the point of doing that in unix_dgram_sendmsg()... > Hi, So the unix_dgram_peer_wake_me() in unix_dgram_sendmsg() is there for epoll in edge-triggered mode. In that case, we want to ensure that if -EAGAIN is returned a subsequent epoll_wait() is not stuck indefinitely. Probably could use a comment... Thanks, -Jason
Powered by blists - more mailing lists