netdev - Re: [PATCH net] udp: call sock_def_readable() if socket is not SOCK

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8506e3ba-c2fc-4981-9a51-041565a9337b@riseup.net>
Date: Tue, 26 Nov 2024 20:30:17 +0100
From: "Fernando F. Mancera" <ffmancera@...eup.net>
To: Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org, willemb@...gle.com
Subject: Re: [PATCH net] udp: call sock_def_readable() if socket is not
 SOCK_FASYNC



On 26/11/2024 20:26, Eric Dumazet wrote:
> On Tue, Nov 26, 2024 at 8:18 PM Fernando F. Mancera
> <ffmancera@...eup.net> wrote:
>>
>> Hi,
>>
>> On 26/11/2024 19:41, Eric Dumazet wrote:
>>> On Tue, Nov 26, 2024 at 7:32 PM Eric Dumazet <edumazet@...gle.com> wrote:
>>>>
>>>> On Tue, Nov 26, 2024 at 6:56 PM Fernando Fernandez Mancera
>>>> <ffmancera@...eup.net> wrote:
>>>>>
>>>>> If a socket is not SOCK_FASYNC, sock_def_readable() needs to be called
>>>>> even if receive queue was not empty. Otherwise, if several threads are
>>>>> listening on the same socket with blocking recvfrom() calls they might
>>>>> hang waiting for data to be received.
>>>>>
>>>>
>>>> SOCK_FASYNC seems completely orthogonal to the issue.
>>>>
>>>> First sock_def_readable() should wakeup all threads, I wonder what is happening.
>>>
>>
>> Well, it might be. But I noticed that if SOCK_FASYNC is set then
>> sk_wake_async_rcu() do its work and everything is fine. This is why I
>> thought checking on the flag was a good idea.
>>
> 
> How have you tested SOCK_FASYNC ?
> 
> SOCK_FASYNC is sending signals. If SIGIO is blocked, I am pretty sure
> the bug is back.
> 

Ah, I didn't know SIGIO was going to be blocked.

> 
>>> Oh well, __skb_wait_for_more_packets() is using
>>> prepare_to_wait_exclusive(), so in this case sock_def_readable() is
>>> waking only one thread.
>>>
>>
>> Yes, this is what I was expecting. What would be the solution? Should I
>> change it to "prepare_to_wait()" instead? Although, I don't know the
>> implication that change might have.
> 
> Sadly, we will have to revert, this exclusive wake is subtle.

If that is the case, let me send a revert patch. Thanks for the fast 
replies :)