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

[Peter Zijlstra]

On Wed, Nov 01, 2017 at 06:34:38PM +0000, David Howells wrote:
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.