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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 21 Feb 2024 13:40:27 +0100
From: Johan Hovold <johan@...nel.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Konrad Dybcio <konrad.dybcio@...aro.org>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Jingoo Han <jingoohan1@...il.com>,
	Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof WilczyƄski <kw@...ux.com>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Marijn Suijten <marijn.suijten@...ainline.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	Johan Hovold <johan+linaro@...nel.org>
Subject: Re: [PATCH] PCI: dwc: Use the correct sleep function in wait_for_link

On Tue, Feb 20, 2024 at 05:00:48PM -0600, Bjorn Helgaas wrote:
> On Tue, Feb 20, 2024 at 09:23:24AM +0100, Johan Hovold wrote:
> > On Thu, Feb 15, 2024 at 06:46:55PM +0100, Konrad Dybcio wrote:
> > > On 15.02.2024 18:02, Bjorn Helgaas wrote:
> > > > On Thu, Feb 15, 2024 at 02:35:13PM +0100, Alexander Lobakin wrote:

> > > >> Just use fsleep(LINK_WAIT_USLEEP_MAX) and let the kernel decide which
> > > >> function to pick.
> > > 
> > > IMO, fsleep only makes sense when the argument is variable.. This way, we
> > > can save on bothering the compiler or adding an unnecessary branch
> > 
> > I fully agree. Using fsleep() with a constant just looks sloppy (e.g.
> > with that hardcoded usleep range) and hides what is really going on for
> > no good reason.
> 
> Why does it look sloppy?  I'd be surprised if using a constant led to
> more executable code, given that fsleep() is inline.  I'm all for
> having the compiler choose the right thing instead of having to look
> up the guidelines myself.

It's not about the generated code, but about hiding what's really going
from kernel developers that should be aware of such things. The fact
that you end up with an usleep range of 20 to 40 ms if you want to sleep
for 20 ms is not very nice either.

Except possibly for a few cases where you'd otherwise end up open-coding
fsleep() I don't think there's any reason to use it.

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ