linux-kernel - Re: [PATCH AUTOSEL 4.9 08/10] Revert "usb: storage: Add quirk for Samsung Fit flash"

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

Message-ID: <Y01tU0BLnON2zfRz@kroah.com>
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