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
| ||
|
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.
Powered by blists - more mailing lists