[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80a295b9-8528-4f37-981c-29dc07d3053f@redhat.com>
Date: Tue, 24 Sep 2024 10:23:57 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Dmitry Antipov <dmantipov@...dex.ru>,
John Fastabend <john.fastabend@...il.com>,
Jakub Sitnicki <jakub@...udflare.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>, Jakub Kicinski <kuba@...nel.org>,
netdev@...r.kernel.org, lvc-project@...uxtesting.org,
syzbot+f363afac6b0ace576f45@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] net: sockmap: avoid race between
sock_map_destroy() and sk_psock_put()
On 9/19/24 11:26, Dmitry Antipov wrote:
> On 9/19/24 11:51 AM, Paolo Abeni wrote:
>
>> I think there is still Cong question pending: why this could not/ should not be addressed instead in the RDS code.
>
> Hm. Except 'rds_tcp_accept_xxx()' functions, the rest of the backtrace
> is contributed by generic TCP and IP things.
AFAICS most of RDS is build on top of TCP, most RDS-specific bugs will
show a lot tcp/ip in their backtrace.
i.e. with mptcp we had quite a few bugs with a 'tcp mostily' or 'tcp
only' backtrace and root caused in the mptcp code.
> I've tried to debug this
> issue starting from the closest innards and seems found an issue within
> sockmap code.
> Anyway, I'm strongly disagree with "unless otherwise proven,
> there are a lot of bugs everywhere except the subsystem I'm responsible
> to" bias, assuming that a bit more friendly and cooperative efforts
> should give us the better results.
I guess that the main point in Cong's feedback is that a sockmap update
is not supposed to race with sock_map_destroy() (???) @Cong, @John,
@JakubS: any comments on that?
Cheers,
Paolo
Powered by blists - more mailing lists