linux-kernel - Re: [PATCH 4/7] sempahore: add a helper for a concurrency limiter

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: <ZCZd6GphMZ9tlISU@bombadil.infradead.org>
Date:   Thu, 30 Mar 2023 21:13:28 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        david@...hat.com, patches@...ts.linux.dev,
        linux-modules@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, petr.pavlu@...e.com,
        prarit@...hat.com, gregkh@...uxfoundation.org, rafael@...nel.org,
        christophe.leroy@...roup.eu, tglx@...utronix.de, song@...nel.org,
        rppt@...nel.org, vbabka@...e.cz, mhocko@...e.com,
        dave.hansen@...ux.intel.com
Subject: Re: [PATCH 4/7] sempahore: add a helper for a concurrency limiter

On Fri, Mar 31, 2023 at 05:06:17AM +0100, Matthew Wilcox wrote:
> On Thu, Mar 30, 2023 at 08:45:52PM -0700, Luis Chamberlain wrote:
> > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> > index 291d4167fab8..00c9fcd90e1a 100644
> > --- a/arch/x86/kernel/cpu/intel.c
> > +++ b/arch/x86/kernel/cpu/intel.c
> > @@ -1177,7 +1177,7 @@ static const struct {
> >  static struct ratelimit_state bld_ratelimit;
> >  
> >  static unsigned int sysctl_sld_mitigate = 1;
> > -static DEFINE_SEMAPHORE(buslock_sem);
> > +static DEFINE_MUTEX(buslock_sem);
> >  
> >  #ifdef CONFIG_PROC_SYSCTL
> >  static struct ctl_table sld_sysctls[] = {
> > @@ -1315,7 +1315,7 @@ static void split_lock_init(void)
> >  static void __split_lock_reenable_unlock(struct work_struct *work)
> >  {
> >  	sld_update_msr(true);
> > -	up(&buslock_sem);
> > +	mutex_unlock(&buslock_sem);
> >  }
> >  
> >  static DECLARE_DELAYED_WORK(sl_reenable_unlock, __split_lock_reenable_unlock);
> 
> ^^^ clearly unsafe.  __split_lock_reenable_unlock() is called as a
> delayed_work(), ie not in the context of the mutex locker.  lockdep
> will freak out at this.
> 
> > @@ -351,12 +351,12 @@ virt_efi_set_variable_nonblocking(efi_char16_t *name, efi_guid_t *vendor,
> >  {
> >  	efi_status_t status;
> >  
> > -	if (down_trylock(&efi_runtime_lock))
> > +	if (!mutex_trylock(&efi_runtime_lock))
> >  		return EFI_NOT_READY;
> 
> looks to me like this can be called while we're oopsing.  if that's in
> non-process context, lockdep will get angry.
> 
> > @@ -149,10 +149,10 @@ EXPORT_SYMBOL_NS_GPL(efivar_lock, EFIVAR);
> >   */
> >  int efivar_trylock(void)
> >  {
> > -	if (down_trylock(&efivars_lock))
> > +	if (!mutex_trylock(&efivars_lock))
> 
> also can be called from oops context.
> 
> > @@ -228,7 +228,7 @@ adb_probe_task(void *x)
> >  	do_adb_reset_bus();
> >  	pr_debug("adb: finished probe task...\n");
> >  
> > -	up(&adb_probe_mutex);
> > +	mutex_unlock(&adb_probe_mutex);
> 
> adb_probe_task() can be called from a different context than the lock
> holder.
> 
> > @@ -10594,7 +10594,7 @@ static bool bnx2x_prev_is_path_marked(struct bnx2x *bp)
> >  	struct bnx2x_prev_path_list *tmp_list;
> >  	bool rc = false;
> >  
> > -	if (down_trylock(&bnx2x_prev_sem))
> > +	if (!mutex_trylock(&bnx2x_prev_sem))
> 
> bet you this can be called from interrupt context.
> 
> this really isn't something to use coccinelle for.

Coccinelle gives you what *would* happen, its up to us to review
if the conversion is correct. Thanks for the feedback, seems like
we're not going there for some users, contrary to what we expected.

  Luis