linux-kernel - Re: [PATCH] usb/mos7720: process deferred urbs in a workqueue

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]

Date:   Wed, 4 Nov 2020 17:25:34 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     johan@...nel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH] usb/mos7720: process deferred urbs in a workqueue

On Wed, Nov 04, 2020 at 12:06:57PM +0100, Johan Hovold wrote:
> On Tue, Nov 03, 2020 at 12:40:14PM -0800, Davidlohr Bueso wrote:
> > On Mon, 02 Nov 2020, Bueso wrote:
> > 
> > >There is
> > >also no need anymore for atomic allocations.
> > 
> > Bleh this is a brain fart - obviously not true as usb_submit_urb() is
> > called under mos_parport->listlock. I'll send a v2 unless you have
> > any objections.
> 
> The conversion looks good to me otherwise; it's not making this parport
> mess any worse than it already is...

Hmm. I took at closer look at the parport code and it seems the current
implementation is already racy but that removing the tasklet is going to
widen that that window.

Those register writes in restore() should be submitted before any
later requests. Perhaps setting a flag and flushing the work in
parport_prologue() could work?

On the other hand, the restore() implementation looks broken in that it
doesn't actually restore the provided state. I'll go fix that up.

Johan