Re: [PATCH V2][5.15.y] bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Dec 12, 2024 at 12:40:19PM +0530, Harshit Mogalapalli wrote:
> Hi Greg,
> 
> On 12/12/24 12:24, Greg KH wrote:
> ...
> > > 
> > > Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation")
> > > Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> > > Link: https://lore.kernel.org/r/20240507103929.30003-1-mschmidt@redhat.com
> > > Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
> > > Signed-off-by: Leon Romanovsky <leon@kernel.org>
> > > Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > I have not signed off on this backport, why did you add this here?  You
> > do know what this is saying right?
> > 
> 
> Note: I think Guocai cherry-picked 6.1.y commit: (probable reason for your
> SOB and Xiangyu Chen's SOB there)

Maybe, but how am I supposed to know that?

> stable-6.1      : v6.1.117  - 84d2f2915218 bnxt_re: avoid shift undefined
> behavior in bnxt_qplib_alloc_init_hwq
> 
> This clean cherry-picks to 5.15.y
> 
> Question: In cases like this where we benefit from cherry-picking a commit
> from another stable branch as opposed to upstream commit(if we used original
> upstream for cherry-picking, we would get conflicts and probably have to
> resolve in the same way as we did for 6.1.y], how do we differentiate that
> in commit message ? May be with a comment before SOB [ Harshit:
> Cherry-picked it from 6.1.y branch, it is a clean cherry-pick], as per
> Option 3 documented in [1], the first line (commit
> 78cfd17142ef70599d6409cbd709d94b3da58659 upstream) should still point to
> upstream commit right ?
> 
> [1] https://www.kernel.org/doc/html/v6.12/process/stable-kernel-rules.html

What would you want to see if you get a random backport sent to you to
do something with and the signed-off-by lines do NOT match with what is
upstream?

Be reasonable here people, realize that someone is on the other side of
these emails and I have to verify that they are actually what they claim
to be (hint, that's getting harder recently with the uptick in backports
that are not correct...)

Make it simple for us please.

thanks,

greg k-h