linux-kernel - Re: [PATCH] Pass mode to wait_on_atomic_t() action funcs and provide default actions

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, 1 Nov 2017 20:06:44 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Pass mode to wait_on_atomic_t() action funcs and provide
 default actions

On Wed, Nov 01, 2017 at 06:34:38PM +0000, David Howells wrote:
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > > I'd like to propose this change for the next merge window.  One question,
> > > though: rather than providing an exported default function, should the
> > > default be used automatically if a NULL function pointer is passed?
> > > 
> > 
> > The default being atomic_t_wait?
> 
> Yes.

Seems OK I suppose, saves the immediate need to export that and saves a
bunch of typing.

> > FWIW, I think the whole wait_atomic_t thing is an utter piece of crap
> > that should be killed out right. It uses this hashed waitqueue crap and
> > does not in fact do anything with the variable that needs it to be
> > atomic_t.
> 
> What would you replace it with?  Bear in mind that the atomic_t may have been
> deallocated by the time wake_up_atomic_t() is called.  I'm using it like:
> 
> 	static void afs_dec_cells_outstanding(struct afs_net *net)
> 	{
> 		if (atomic_dec_and_test(&net->cells_outstanding))
> 			wake_up_atomic_t(&net->cells_outstanding);
> 	}
> 
> The moment atomic_dec_and_test() is called, *net is at liberty to disappear,
> so there's no way to find a waitqueue - unless that waitqueue is guaranteed
> not to be deallocated, eg. by being global.

But any possible wait side will still need to dereference *net at an
indeterminate point in the future to ascertain the value does now indeed
read 0.

But sure, I see the use-case for an external waitqueue. And I suppose I
could even live with atomic_t_waitqueue() if that was it.

So ideally it'd look something like:

	wait_event(var_waitqueue(&foo->atomic), !atomic_read(&foo->atomic));

Except the current wait_event() doesn't do the whole key part that makes
the hash-table 'work'.

So I see why its all put together the way it is, but I do dislike it
lots for having that one atomic_read()==0 case hard coded like this.

Maybe something like: wait_on_var(var, cond_expr);
where we use the var's address to hash on etc. Dunno.. We can certainly
start with your patch, as that does clean things up.