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
| ||
|
Date: Mon, 17 Oct 2022 16:57:23 +0200 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: Pavel Machek <pavel@...x.de> Cc: Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org, stable@...r.kernel.org, sunghwan jung <onenowy@...il.com>, stern@...land.harvard.edu, linux-usb@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net Subject: Re: [PATCH AUTOSEL 4.9 08/10] Revert "usb: storage: Add quirk for Samsung Fit flash" On Mon, Oct 17, 2022 at 02:46:32PM +0200, Pavel Machek wrote: > Hi! > > > From: sunghwan jung <onenowy@...il.com> > > > > [ Upstream commit ad5dbfc123e6ffbbde194e2a4603323e09f741ee ] > > > > This reverts commit 86d92f5465958752481269348d474414dccb1552, > > which fix the timeout issue for "Samsung Fit Flash". > > > > But the commit affects not only "Samsung Fit Flash" but also other usb > > storages that use the same controller and causes severe performance > > regression. > > > > # hdparm -t /dev/sda (without the quirk) > > Timing buffered disk reads: 622 MB in 3.01 seconds = 206.66 MB/sec > > > > # hdparm -t /dev/sda (with the quirk) > > Timing buffered disk reads: 220 MB in 3.00 seconds = 73.32 MB/sec > > > > The commit author mentioned that "Issue was reproduced after device has > > bad block", so this quirk should be applied when we have the timeout > > issue with a device that has bad blocks. > > > > We revert the commit so that we apply this quirk by adding kernel > > paramters using a bootloader or other ways when we really need it, > > without the performance regression with devices that don't have the > > issue. > > Re-introducing timeouts for users in middle of stable series... may > not be nice. Is there better fix in a follow up to this that was not > backported? No. thanks, greg k-h
Powered by blists - more mailing lists