linux-kernel - Re: [PATCH] thunderbolt: Reduce retry timeout to speed up boot for some devices

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231221103718.GC2543524@black.fi.intel.com>
Date: Thu, 21 Dec 2023 12:37:18 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Greg KH <greg@...ah.com>
Cc: Werner Sembach <wse@...edocomputers.com>,
	Andreas Noever <andreas.noever@...il.com>,
	Michael Jamet <michael.jamet@...el.com>,
	Yehezkel Bernat <YehezkelShB@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] thunderbolt: Reduce retry timeout to speed up boot for
 some devices

Hi,

On Wed, Dec 20, 2023 at 06:30:53PM +0100, Greg KH wrote:
> On Wed, Dec 20, 2023 at 05:41:01PM +0100, Werner Sembach wrote:
> > 
> > Am 20.12.23 um 17:04 schrieb Greg KH:
> > > On Wed, Dec 20, 2023 at 04:23:15PM +0100, Werner Sembach wrote:
> > > > Am 20.12.23 um 16:09 schrieb Werner Sembach:
> > > > > This is a followup to "thunderbolt: Workaround an IOMMU fault on certain
> > > > > systems with Intel Maple Ridge".
> > > > > 
> > > > > It seems like the timeout can be reduced to 250ms. This reduces the overall
> > > > > delay caused by the retires to ~1s. This is about the time other things
> > > > > being initialized in parallel need anyway*, so like this the effective boot
> > > > > time is no longer compromised.
> > > > > 
> > > > > *I only had a single device available for my measurements: A Clevo X170KM-G
> > > > > desktop replacement notebook.
> > > > > 
> > > > > Signed-off-by: Werner Sembach <wse@...edocomputers.com>
> > > > I wonder if this could also land in stable? Or would it be to risky?
> > > If it's really a bugfix now, why would it _not_ be relevant for stable?
> > 
> > Because it changes a timeout that could cause issues if set to low: This
> > Patch sets to to 250ms. Set to 50ms it causes issues, currently it's 2000ms,
> > 2 people tested that 250ms is enough, but i don't know if this is a big
> > enough sample size for stable.
> 
> Remember, the next kernel will be a stable kernel tree, just like the
> one after that.  If it's good enough for Linus's tree, why wouldn't it
> be good enough for all stable trees?  Either it works or it doesn't,
> none of this "we will break things when you move to a new kernel" stuff
> please.

Since this is kind of "improvement" over already functioning code, I
would put it to v6.8 and not to stable trees. This way it gets more some
more exposure before landing to distro kernels.

It would be nice to get Tested-by from the folks involved on that
bugzilla as well, if that's possible. I can try this on my side on a
Maple Ridge based system (that does not have the original issue) so that
we know that it does not cause any issues on them.