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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <552b3d67-2f43-5831-e4ea-666827de54fe@akamai.com>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ