From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751502AbdIENaC (ORCPT ); Tue, 5 Sep 2017 09:30:02 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:33907 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750858AbdIEN35 (ORCPT ); Tue, 5 Sep 2017 09:29:57 -0400 X-Google-Smtp-Source: ADKCNb5C1kTbzXJ4GoXr9LDnQT54vhp0glpqOsXiJcqIWhP6KvXI4LV/37kjGJJ6VDb2dFsUrBjN2w== Date: Tue, 5 Sep 2017 06:29:51 -0700 From: Tejun Heo To: David Howells Cc: linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, Lai Jiangshan , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 01/11] workqueue: Add a decrement-after-return and wake if 0 facility Message-ID: <20170905132951.GB1774378@devbig577.frc2.facebook.com> References: <150428045304.25051.1778333106306853298.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150428045304.25051.1778333106306853298.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, David. On Fri, Sep 01, 2017 at 04:40:53PM +0100, David Howells wrote: > Add a facility to the workqueue subsystem whereby an atomic_t can be > registered by a work function such that the work function dispatcher will > decrement the atomic after the work function has returned and then call > wake_up_atomic() on it if it reached 0. > > This is analogous to complete_and_exit() for kernel threads and is used to > avoid a race between notifying that a work item is about to finish and the > .text segment from a module being discarded. > > The way this is used is that the work function calls: > > dec_after_work(atomic_t *counter); > > to register the counter and then process_one_work() calls it, potentially > wakes it and clears the registration. > > The reason I've used an atomic_t rather than a completion is that (1) it > takes up less space and (2) it can monitor multiple objects. Given how work items are used, I think this is too inviting to abuses where people build complex event chains through these counters and those chains would be completely opaque. If the goal is protecting .text of a work item, can't we just do that? Can you please describe your use case in more detail? Why can't it be done via the usual "flush from exit"? Thanks. -- tejun