[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZzWY3iAbgWEDcQzV@LQ3V64L9R2>
Date: Wed, 13 Nov 2024 22:29:50 -0800
From: Joe Damato <jdamato@...tly.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com,
amritha.nambiar@...el.com, sridhar.samudrala@...el.com,
mkarsten@...terloo.ca, "David S. Miller" <davem@...emloft.net>,
open list <linux-kernel@...r.kernel.org>,
Mina Almasry <almasrymina@...gle.com>,
Simon Horman <horms@...nel.org>
Subject: Re: [net v2 0/2] Fix rcu_read_lock issues in netdev-genl
On Wed, Nov 13, 2024 at 06:47:35PM -0800, Jakub Kicinski wrote:
> On Wed, 13 Nov 2024 02:17:50 +0000 Joe Damato wrote:
> > base-commit: a58f00ed24b849d449f7134fd5d86f07090fe2f5
>
> which is a net-next commit.. please rebase on net
I thought I asked about this in the previous thread, but I probably
wasn't clear with my question.
Let me try again:
Patch 1 will apply to net and is a fixes and CC's stable, and fixes
a similar issue to the one Paolo reported, not the exact same path,
though.
Patch 2 will not apply to net, because the code it fixes is not in
net yet. This fixes the splat Paolo reported.
So... back to the question in the cover letter from the RFC :) I
suppose the right thing to do is split the series:
- Rebase patch 1 on net (it applies as is) and send it on its own
- Send patch 2 on its own against net-next
Or... something else ?
Powered by blists - more mailing lists