[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89i+OtPYN7U_noe_izHx5wYjV+kyq_JODD0-8LROA8noZ6w@mail.gmail.com>
Date: Tue, 26 Nov 2024 20:33:39 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: "Fernando F. Mancera" <ffmancera@...eup.net>
Cc: netdev@...r.kernel.org, willemb@...gle.com
Subject: Re: [PATCH net] udp: call sock_def_readable() if socket is not SOCK_FASYNC
On Tue, Nov 26, 2024 at 8:30 PM Fernando F. Mancera
<ffmancera@...eup.net> wrote:
>
>
>
> 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 :)
Please wait one day before sending a new patch, thanks.
Powered by blists - more mailing lists