linux-kernel - Re: initialize a mutex into locked state?

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]

Date:	Fri, 17 Jun 2016 16:59:54 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Oleg Drokin <green@...uxhacker.ru>
Cc:	Mailing List <linux-kernel@...r.kernel.org>, mingo@...hat.com,
	arjan@...ux.intel.com, "J . Bruce Fields" <bfields@...ldses.org>,
	Jeff Layton <jlayton@...chiereds.net>
Subject: Re: initialize a mutex into locked state?

On Fri, Jun 17, 2016 at 10:40:14AM -0400, Oleg Drokin wrote:

> >> The problem is:
> >> 
> >> spin_lock(somelock);
> >> structure = some_internal_list_lookup(list);
> >> if (structure)
> >> 	goto out;
> >> 
> >> init_new_structure(new_structure);
> >> mutex_init(&new_structure->s_mutex);
> >> mutex_lock(&new_structure->s_mutex);  // XXX CANNOT DO THIS UNDER SPINLOCK!
> > 
> > 	mutex_trylock(&new_structure->s_mutex);
> > 
> > should work, since you know it cannot be acquired yet by anybody else,
> > since you've not published it yet.
> 
> This does work, but suddenly does not look so obvious anymore, does it?

Well, the whole thing is somewhat tricky and would require a comment
anyway.

> I got some feedback that doing this is not really preferred.

Much preferred to adding additional API I would think. Because if we add
it here, we'll also have to add it to rt_mutex.

Also, I'm not sure I want to promote this construct, it seems like a
very special case.

> Also once __must_check is added to mutex_try_lock() (surprised it's not yet),
> we'll need to also have the useless "but what if it did fail to lock" path?

The BUG_ON() suggested by Jeff seems like a good solution ;-)