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

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

[Joel Fernandes]

+rcu for archives 

> On Dec 2, 2022, at 7:16 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
> 
> On Sat, Dec 3, 2022 at 12:12 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>> 
>>> On Sat, Dec 3, 2022 at 12:03 AM Paul E. McKenney <paulmck@kernel.org> 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.
>>>> 
>>>> Hi Eric,
>>>> Nice to see your patch.
>>>> 
>>>> Paul, all, regarding Eric's concern, would the following work to warn of
>>>> users? Credit to Paul/others for discussing the idea on another thread. One
>>>> thing to note here is, this debugging will only be in effect on preemptible
>>>> kernels, but should still help catch issues hopefully.
>>> 
>>> Mightn't there be some places where someone needs to invoke
>>> single-argument kfree_rcu() in a preemptible context, for example,
>>> due to the RCU-protected structure being very small and very numerous?
>> 
>> This could be possible but I am not able to find examples of such
>> cases, at the moment. Another approach could be to introduce a
>> dedicated API for such cases, where the warning will not fire. And
>> keep the warning otherwise.
>> 
>> Example: kfree_rcu_headless()
>> With a big comment saying, use only if you are calling from a
>> preemptible context and cannot absolutely embed an rcu_head. :-)
>> 
>> Thoughts?
>> 
> 
> Just to clarify, where I was getting at was to combine both ideas:
> 1. new API with suppression of the new warning mentioned above.
> 2. old API but add new warning mentioned above.
> 
> Cheers,
> 
> - Joel

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

[Uladzislau Rezki]

Hello, Eric.

> +rcu for archives 
> 
> > On Dec 2, 2022, at 7:16 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > 
> > On Sat, Dec 3, 2022 at 12:12 AM Joel Fernandes <joel@joelfernandes.org> wrote:
> >> 
> >>> On Sat, Dec 3, 2022 at 12:03 AM Paul E. McKenney <paulmck@kernel.org> 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@google.com> (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@google.com>
Cc: Dmitry Safonov <dima@arista.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
<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.

Thank you.

--
Uladzislau Rezki

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

[Eric Dumazet]

On Mon, Dec 5, 2022 at 12:09 PM Uladzislau Rezki <urezki@gmail.com> wrote:
>
> Hello, Eric.
>
> > +rcu for archives
> >
> > > On Dec 2, 2022, at 7:16 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > >
> > > On Sat, Dec 3, 2022 at 12:12 AM Joel Fernandes <joel@joelfernandes.org> wrote:
> > >>
> > >>> On Sat, Dec 3, 2022 at 12:03 AM Paul E. McKenney <paulmck@kernel.org> 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@google.com> (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@google.com>
> Cc: Dmitry Safonov <dima@arista.com>
> Cc: Paul E. McKenney <paulmck@kernel.org>
> <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()

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

[Uladzislau Rezki]

> On Mon, Dec 5, 2022 at 12:09 PM Uladzislau Rezki <urezki@gmail.com> wrote:
> >
> > Hello, Eric.
> >
> > > +rcu for archives
> > >
> > > > On Dec 2, 2022, at 7:16 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > > >
> > > > On Sat, Dec 3, 2022 at 12:12 AM Joel Fernandes <joel@joelfernandes.org> wrote:
> > > >>
> > > >>> On Sat, Dec 3, 2022 at 12:03 AM Paul E. McKenney <paulmck@kernel.org> 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@google.com> (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@google.com>
> > Cc: Dmitry Safonov <dima@arista.com>
> > Cc: Paul E. McKenney <paulmck@kernel.org>
> > <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()
>
So it was a typo then. How did you identify that BUG? Simple go through
the code? Or some test coverage?

Thank you!

--
Uladzislau Rezki

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

[Eric Dumazet]

On Mon, Dec 5, 2022 at 3:59 PM Uladzislau Rezki <urezki@gmail.com> wrote:

> So it was a typo then. How did you identify that BUG? Simple go through
> the code? Or some test coverage?

Code review. I am the TCP maintainer, in case you do not know.

>
> Thank you!
>
> --
> Uladzislau Rezki

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

[Uladzislau Rezki]

> On Mon, Dec 5, 2022 at 3:59 PM Uladzislau Rezki <urezki@gmail.com> wrote:
> 
> > So it was a typo then. How did you identify that BUG? Simple go through
> > the code? Or some test coverage?
> 
> Code review. I am the TCP maintainer, in case you do not know.
> 
OK, thank you.

--
Uladzislau Rezki