linux-kernel - Re: PROBLEM: Long Workqueue delays.

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: <1838f2c3-7915-9e5b-3112-6b082b945410@mentor.com>
Date:   Tue, 18 Aug 2020 11:54:51 +0100
From:   Jim Baxter <jim_baxter@...tor.com>
To:     Alan Stern <stern@...land.harvard.edu>
CC:     Greg KH <gregkh@...uxfoundation.org>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <linux-usb@...r.kernel.org>,
        "Resch Carsten (CM/ESO6)" <Carsten.Resch@...bosch.com>,
        "Rosca, Eugeniu (ADITG/ESB)" <erosca@...adit-jv.com>
Subject: Re: PROBLEM: Long Workqueue delays.

On 17/08/2020 19:47, Alan Stern wrote:
> 
> Unplugging a R/W USB drive without unmounting it first is a great way to 
> corrupt the data.
> 
Thank you, post development we will only mount the USB stick as R/O.

>> Using perf Iidentified the hub_events workqueue was spending a lot of time in
>> invalidate_partition(), I have included a cut down the captured data from perf in
>> [2] which shows the additional functions where the kworker spends most of its time.
> 
> invalidate_partition() is part of the block layer, not part of USB.  It 
> gets called whenever a drive is removed from the system, no matter what 
> type of drive it is.  You should ask the people involved in that 
> subsystem why it takes so long.
> 

I included the linux-mm list but missed the filesystem, I will ask the question
to the linux-fsdevel too.

>> I realise that not unmounting the USB stick is not ideal, though I wonder what 
>> additional work is done when unplugging the USB stick compared to unmounting it.
> 
> Unmounting a drive flushes all the dirty buffers from memory back to the 
> drive.  Obviously that can't be done if the drive is unplugged first.
> 
> As far as the USB subsystem is concerned, exactly the same amount of 
> work is done during disconnect regardless of whether or not the drive is 
> mounted.  (In fact, the USB subsystem doesn't even know whether a drive 
> is mounted; that concept is part of the block and filesystem layers.)
>>> I guess it may be waiting for a time-out during the operation without the unmount.
> 
> That seems very unlikely.  When a USB device gets unplugged the system 
> realizes it.  Any I/O meant for that device is immediately cancelled; 
> there are no timeouts.
> 
> (Okay, not strictly true; there is a fraction-of-a-second timeout during 
> which the system waits to see whether the disconnect was permanent or 
> just a temporary glitch.  But you're talking about 6-second long 
> delays.)
> 

Thank you, no I don't expect that to cause the issue and it is very likely the delay
is in another subsystem.

Regards,
Jim Baxter


> Alan Stern
>