linux-kernel - Re: [PATCH -tip/master 2/7] locking/mutex: Document quick lock release when unlocking

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: <1406744455.14047.2.camel@buesod1.americas.hpqcorp.net>
Date:	Wed, 30 Jul 2014 11:20:55 -0700
From:	Davidlohr Bueso <davidlohr@...com>
To:	Jason Low <jason.low2@...com>
Cc:	peterz@...radead.org, mingo@...nel.org, aswin@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -tip/master 2/7] locking/mutex: Document quick lock
 release when unlocking

On Wed, 2014-07-30 at 08:10 -0700, Jason Low wrote:
> On Sun, 2014-07-27 at 22:18 -0700, Davidlohr Bueso wrote:
> > - * Release the lock, slowpath:
> > + * Release the lock, slowpath.
> > + *  At this point, the lock counter is 0 or negative.
> 
> Hmm, so in the !__mutex_slowpath_needs_to_unlock() case, we could enter
> this function with the lock count == 1 right?

Yes, it is possible. So that comment should actually be moved down to:

> >   */
> >  static inline void
> >  __mutex_unlock_common_slowpath(struct mutex *lock, int nested)
> > @@ -684,9 +685,16 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int nested)
> >  	unsigned long flags;
> >  
> >  	/*
> > -	 * some architectures leave the lock unlocked in the fastpath failure
> > +	 * As a performance measurement, release the lock before doing other
> > +	 * wakeup related duties to follow. This allows other tasks to acquire
> > +	 * the lock sooner, while still handling cleanups in past unlock calls.
> > +	 * This can be done as we do not enforce strict equivalence between the
> > +	 * mutex counter and wait_list.
> > +	 *
> > +	 *
> > +	 * Some architectures leave the lock unlocked in the fastpath failure
> >  	 * case, others need to leave it locked. In the later case we have to
> > -	 * unlock it here
> > +	 * unlock it here.

... here.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/