From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933147AbdKATGs (ORCPT ); Wed, 1 Nov 2017 15:06:48 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:33449 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932568AbdKATGr (ORCPT ); Wed, 1 Nov 2017 15:06:47 -0400 Date: Wed, 1 Nov 2017 20:06:44 +0100 From: Peter Zijlstra To: David Howells Cc: Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Pass mode to wait_on_atomic_t() action funcs and provide default actions Message-ID: <20171101190644.chwhfpoz3ywxx2m7@hirez.programming.kicks-ass.net> References: <20171101162713.o7njyehh43jrc5q5@hirez.programming.kicks-ass.net> <5838.1509550663@warthog.procyon.org.uk> <15510.1509561278@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15510.1509561278@warthog.procyon.org.uk> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 01, 2017 at 06:34:38PM +0000, David Howells wrote: > Peter Zijlstra 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.