lkml.org 
[lkml]   [2022]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5.18 097/181] Revert "net/tls: fix tls_sk_proto_close executed repeatedly"
On Mon, Jun 27, 2022 at 08:57:28AM -0700, Jakub Kicinski wrote:
>On Mon, 27 Jun 2022 17:50:31 +0200 Greg Kroah-Hartman wrote:
>> On Mon, Jun 27, 2022 at 08:33:13AM -0700, Jakub Kicinski wrote:
>> > On Mon, 27 Jun 2022 13:21:10 +0200 Greg Kroah-Hartman wrote:
>> > > From: Jakub Kicinski <kuba@kernel.org>
>> > >
>> > > [ Upstream commit 1b205d948fbb06a7613d87dcea0ff5fd8a08ed91 ]
>> > >
>> > > This reverts commit 69135c572d1f84261a6de2a1268513a7e71753e2.
>> > >
>> > > This commit was just papering over the issue, ULP should not
>> > > get ->update() called with its own sk_prot. Each ULP would
>> > > need to add this check.
>> > >
>> > > Fixes: 69135c572d1f ("net/tls: fix tls_sk_proto_close executed repeatedly")
>> > > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>> >
>> > Mm? How did 69135c572d1f get into stableh?
>> > I reverted it before it hit Linus's tree.
>> > Don't see the notification about it either.
>>
>> It is commit 075/181 in this series as you can see here:
>> https://lore.kernel.org/r/20220627111946.738369250@linuxfoundation.org
>
>Argh, I forgot I'm not gonna get CCed if my tags aren't on the
>commit in question, sorry for the confusion.
>
>So I expected patches 075 and 097 would just get dropped since
>they are in the same series and are canceling each other out.
>But I guess people may edit reverts so you prefer not to
>automatically do that?

It's also the case that it's useful for historical purposes to keep
track of why a certain commit made it in or not.

--
Thanks,
Sasha

\
 
 \ /
  Last update: 2022-06-28 15:35    [W:0.229 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site