From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934172AbdKBQpz convert rfc822-to-8bit (ORCPT ); Thu, 2 Nov 2017 12:45:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33088 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932428AbdKBQpx (ORCPT ); Thu, 2 Nov 2017 12:45:53 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 76F0F356CE Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dhowells@redhat.com Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20171101190644.chwhfpoz3ywxx2m7@hirez.programming.kicks-ass.net> References: <20171101190644.chwhfpoz3ywxx2m7@hirez.programming.kicks-ass.net> <20171101162713.o7njyehh43jrc5q5@hirez.programming.kicks-ass.net> <5838.1509550663@warthog.procyon.org.uk> <15510.1509561278@warthog.procyon.org.uk> To: Peter Zijlstra Cc: dhowells@redhat.com, Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Pass mode to wait_on_atomic_t() action funcs and provide default actions MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10659.1509641151.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Thu, 02 Nov 2017 16:45:51 +0000 Message-ID: <10660.1509641151@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 02 Nov 2017 16:45:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra wrote: > > 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. Yeah, the assumption is that the *wait* side is where the deallocation is happening. So I have something like: net->live = false; // Tell the cell managers to delete the cells ... foreach (cell) queue_work(cell); ... wait_on_atomic_t(&net->cells_outstanding, atomic_t_wait, TASK_UNINTERRUPTIBLE); ... destroy(net); > ... We can certainly start with your patch, as that does clean things up. Can I put that down as a Grudgingly-acked-by? David