linux-kernel - Re: [PATCH] usb: storage: ene_ub6250: Fix right shift warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024091228-bootie-name-4867@gregkh>
Date: Thu, 12 Sep 2024 07:06:45 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Abhishek Tamboli <abhishektamboli9@...il.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
	usb-storage@...ts.one-eyed-alien.net, linux-usb@...r.kernel.org,
	skhan@...uxfoundation.org, dan.carpenter@...aro.org,
	rbmarliere@...il.com,
	linux-kernel-mentees@...ts.linuxfoundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: storage: ene_ub6250: Fix right shift warnings

On Thu, Sep 12, 2024 at 06:15:18AM +0530, Abhishek Tamboli wrote:
> Hi Alan,
> On Thu, Aug 01, 2024 at 10:51:35AM -0400, Alan Stern wrote:
> > On Thu, Aug 01, 2024 at 08:54:18AM +0200, 'Oliver Neukum' via USB Mass Storage on Linux wrote:
> > > 
> > > 
> > > On 31.07.24 20:19, Alan Stern wrote:
> > > > On Wed, Jul 31, 2024 at 11:34:45PM +0530, Abhishek Tamboli wrote:
> > > > > On Wed, Jul 31, 2024 at 10:04:33AM -0400, Alan Stern wrote:
> > > 
> > > Hi,
> > > 
> > > I should make my reasoning clearer.
> > > 
> > > > > > Replacing the variable with a constant won't make much difference.  The
> > > > > > compiler will realize that bl_len has a constant value and will generate
> > > > > > appropriate code anyway.  I think just changing the type is a fine fix.
> > > 
> > > While that is absolutely true, it kind of removes the reason for the patch
> > > in the first place. The code gcc generates is unlikely to be changed.
> > > 
> > > We are reacting to a warning an automatic tool generates. That is a good thing.
> > > We should have clean code. The question is how we react to such a report.
> > > It just seems to me that if we fix such a warning, the code should really be clean
> > > after that. Just doing the minimum that will make the checker shut up is
> > > no good.
> > 
> > With this fix, the code seems clean to me.  It may not be as short as 
> > possible, but it's clean.
> 
> I noticed that the patch has not yet been pulled into linux-next, 
> even though it has been acked-by you for over a month. Is there 
> anything else I need to do on my end?

Yes, please resend it, it is long gone from my review queue, sorry.

thanks,

greg k-h