[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZaapI9zDaP1YI7AA@C02YVCJELVCG>
Date: Tue, 16 Jan 2024 11:04:51 -0500
From: Andy Gospodarek <andrew.gospodarek@...adcom.com>
To: John Fastabend <john.fastabend@...il.com>
Cc: Andy Gospodarek <andrew.gospodarek@...adcom.com>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
netdev-driver-reviewers@...r.kernel.org
Subject: Re: [ANN] netdev call - Jan 16th
On Tue, Jan 16, 2024 at 07:29:19AM -0800, John Fastabend wrote:
> Andy Gospodarek wrote:
> > On Mon, Jan 15, 2024 at 05:54:40PM -0800, Jakub Kicinski wrote:
> > > Hi,
> > >
> > > The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
> > > is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).
> > >
> > > There's a minor CI update. Please suggest other topics.
> > >
> >
> > I would like to discuss a process question for posting a fix to a stable kernel
> > that isn't needed in the latest upstream as it was fixed another way.
> >
> > This is related to this thread:
> >
> > https://lore.kernel.org/linux-patches/ZZQqGtYqN3X9EuWo@C02YVCJELVCG.dhcp.broadcom.net/
> >
> > Thanks.
> >
>
> If you send it to stable with a tag like,
>
> CC: <stable@...r.kernel.org> # 5.15.x
>
> or whatever kernel you need this has worked from me. This has worked for
> me if I understood the above question correctly. The relevant docs are in
> Documentation/process/stable-kernel-rules.rst. The following bit seems to
> explain it.
>
> * For patches that may have kernel version prerequisites specify them using
> the following format in the sign-off area:
>
> .. code-block:: none
>
> Cc: <stable@...r.kernel.org> # 3.3.x
>
> The tag has the meaning of:
>
> .. code-block:: none
>
> git cherry-pick <this commit>
>
> For each "-stable" tree starting with the specified version.
>
> Note, such tagging is unnecessary if the stable team can derive the
> appropriate versions from Fixes: tags.
>
> * To delay pick up of patches, use the following format:
>
> .. code-block:: none
>
> Cc: <stable@...r.kernel.org> # after 4 weeks in mainline
>
> * For any other requests, just add a note to the stable tag. This for example
> can be used to point out known problems:
>
> .. code-block:: none
>
> Cc: <stable@...r.kernel.org> # see patch description, needs adjustments for <= 6.3
Thanks, John.
This one is a bit odd what happened is that by the time this problem was
reported (on an older kernel), the code changed out from underneath.
The new code was bug-compatible with the old code (whic is an indicator
that a good job was done porting bnxt_en to use DMA mapping from the
page pool infra.
So at the time when the patch was posted, the tip of tree code did need
a fixes tag of:
Fixes: 578fcfd26e2a ("bnxt_en: Let the page pool manage the DMA mapping")
In any kernel pre-6.6 (or if we found the patch a few months back) the
patch would have been different (since the dma mapping was handled
differently) and the fixes tag would have been:
Fixes: a7559bc8c17c ("bnxt: support transmit and free of aggregation buffers")
Greg's concern (at least as I read it) is that it looks like I'm asking
him to take a patch that is not upstream. That totally makes sense, but
now what?
Based on what I see in Documentation, I think I need to just resubmit to
stable as that would follow "Option 2" and explain why it 'deviates from
the original' patch.
Powered by blists - more mailing lists