Re: [ANN] netdev call - Jan 16th

[Andy Gospodarek <andrew.gospodarek@broadcom.com>]

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@vger.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@vger.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@vger.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@vger.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.