Re: [PATCH net-next] tcp: use 2-arg optimal variant of kfree_rcu()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 5, 2022 at 12:09 PM Uladzislau Rezki <urezki@xxxxxxxxx> wrote:
>
> Hello, Eric.
>
> > +rcu for archives
> >
> > > On Dec 2, 2022, at 7:16 PM, Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Sat, Dec 3, 2022 at 12:12 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote:
> > >>
> > >>> On Sat, Dec 3, 2022 at 12:03 AM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
> > >>>
> > >>> On Fri, Dec 02, 2022 at 11:49:59PM +0000, Joel Fernandes wrote:
> > >>>> On Fri, Dec 02, 2022 at 05:28:47AM +0000, Eric Dumazet wrote:
> > >>>>> kfree_rcu(1-arg) should be avoided as much as possible,
> > >>>>> since this is only possible from sleepable contexts,
> > >>>>> and incurr extra rcu barriers.
> > >>>>>
> > >>>>> I wish the 1-arg variant of kfree_rcu() would
> > >>>>> get a distinct name, like kfree_rcu_slow()
> > >>>>> to avoid it being abused.
> >
> <snip>
> tcp: use 2-arg optimal variant of kfree_rcu()
> Date: Fri,  2 Dec 2022 05:28:47 +0000   [thread overview]
> Message-ID: <20221202052847.2623997-1-edumazet@xxxxxxxxxx> (raw)
>
> kfree_rcu(1-arg) should be avoided as much as possible,
> since this is only possible from sleepable contexts,
> and incurr extra rcu barriers.
>
> I wish the 1-arg variant of kfree_rcu() would
> get a distinct name, like kfree_rcu_slow()
> to avoid it being abused.
>
> Fixes: 459837b522f7 ("net/tcp: Disable TCP-MD5 static key on tcp_md5sig_info destruction")
> Signed-off-by: Eric Dumazet <edumazet@xxxxxxxxxx>
> Cc: Dmitry Safonov <dima@xxxxxxxxxx>
> Cc: Paul E. McKenney <paulmck@xxxxxxxxxx>
> <snip>
>
> Could you please clarify a little bit about why/how have you came
> up with a patch that you posted with "Fixes" tag? I mean you run
> into:
>   - performance degrade;
>   - simple typo;
>   - etc.

Bug was added in the blamed commit, we use Fixes: tag to clearly
identify bug origin.

tcp_md5_key_copy()  is called from softirq context, there is no way it
could sleep in synchronize_rcu()




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux