linux-kernel - Re: [PATCH v5] staging: r8188eu: Remove _enter/_exit_critical

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: <YTCaF5Ure2tjfbZB@kroah.com>
Date:   Thu, 2 Sep 2021 11:32:07 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc:     Larry Finger <Larry.Finger@...inger.net>,
        Phillip Potter <phil@...lpotter.co.uk>,
        Martin Kaiser <martin@...ser.cx>,
        Michael Straube <straube.linux@...il.com>,
        Pavel Skripkin <paskripkin@...il.com>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        Aakash Hemadri <aakashhemadri123@...il.com>
Subject: Re: [PATCH v5] staging: r8188eu: Remove _enter/_exit_critical_mutex()

On Sat, Aug 28, 2021 at 01:36:56PM +0200, Fabio M. De Francesco wrote:
> Remove _enter_critical_mutex() and _exit_critical_mutex(). They are
> unnecessary wrappers, respectively to mutex_lock_interruptible() and
> to mutex_unlock(). They also have an odd interface that takes an unused
> argument named pirqL of type unsigned long.
> The original code enters the critical section if the mutex API is
> interrupted while waiting to acquire the lock; therefore it could lead
> to a race condition. Use mutex_lock() because it is uninterruptible and
> so avoid that above-mentioned potential race condition.
> 
> Tested-by: Pavel Skripkin <paskripkin@...il.com>
> Reviewed-by: Pavel Skripkin <paskripkin@...il.com>
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@...il.com>
> ---
> 
> v5: Fix a typo in the subject line. Reported by Aakash Hemadri.
> 
> v4: Tested and reviewed by Pavel Skripkin. No changes to the code.
> 
> v3: Assume that the original authors don't expect that
> mutex_lock_interruptible() can be really interrupted and then lead to 
> a potential race condition. Furthermore, Greg Kroah-Hartman makes me
> notice that "[] one almost never needs interruptable locks in a driver".
> Therefore, replace the calls to mutex_lock_interruptible() with calls to
> mutex_lock() since the latter is uninterruptible and avoid race
> conditions without the necessity to handle -EINTR errors.

Based on a recent conversation on the linux-usb mailing list, perhaps I
was wrong:
	https://lore.kernel.org/r/20210829015825.GA297712@rowland.harvard.edu

Can you check what happens with your change when you disconnect the
device and these code paths are being called?  That is when you do want
the lock interrupted.

Yes, the logic still seems wrong, but I don't want to see the code now
just lock up entirely with this change as it is a change in how things
work from today.

thanks,

greg k-h