Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932368AbcKPPti (ORCPT ); Wed, 16 Nov 2016 10:49:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:44669 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752388AbcKPPtg (ORCPT ); Wed, 16 Nov 2016 10:49:36 -0500 Date: Wed, 16 Nov 2016 16:49:31 +0100 (CET) From: Miroslav Benes To: Jessica Yu cc: Rusty Russell , Aaron Tomlin , linux-kernel@vger.kernel.org, rostedt@goodmis.org Subject: Re: module: Ensure a module's state is set accordingly during module coming cleanup code In-Reply-To: <20161109101201.GA27196@packer-debian-8-amd64.digitalocean.com> Message-ID: References: <1476980293-19062-1-git-send-email-atomlin@redhat.com> <1476980293-19062-2-git-send-email-atomlin@redhat.com> <87funk3p6f.fsf@rustcorp.com.au> <20161109101201.GA27196@packer-debian-8-amd64.digitalocean.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2627 Lines: 73 On Wed, 9 Nov 2016, Jessica Yu wrote: > +++ Rusty Russell [26/10/16 11:24 +1030]: > > Aaron Tomlin writes: > > > In load_module() in the event of an error, for e.g. unknown module > > > parameter(s) specified we go to perform some module coming clean up > > > operations. At this point the module is still in a "formed" state > > > when it is actually going away. > > > > > > This patch updates the module's state accordingly to ensure anyone on the > > > module_notify_list waiting for a module going away notification will be > > > notified accordingly. > > > > I recall a similar proposal before. > > > > I've audited all the subscribers to check they didn't look at > > mod->state; they seem OK. > > > > We actually do this in the init-failed path, so this should be OK. > > We did discuss a similar proposal before: > > https://lkml.kernel.org/r/87a8m7ko6j.fsf@rustcorp.com.au > > The complaint back then was that we need to be in the COMING state for > strong_try_module_get() to fail. But it will also correctly fail for GOING > modules in the module_is_live() check in the subsequent call to > try_module_get(), so I believe we are still OK here. FWIW, I looked and this is true. Even the error -ENOENT could be better in this case than -EBUSY (since the module is going away). Reviewed-by: Miroslav Benes for the patch, if you want it. Anyway, the comment above strong_try_module_get() is not true for almost 9 nine years. So how about something like: -->8-- >From 872e11394fdaba8fb9a333e114dc92273d2d1bf5 Mon Sep 17 00:00:00 2001 From: Miroslav Benes Date: Wed, 16 Nov 2016 16:45:48 +0100 Subject: [PATCH] module: Fix a comment above strong_try_module_get() The comment above strong_try_module_get() function is not true anymore. Return values changed with commit c9a3ba55bb5d ("module: wait for dependent modules doing init."). Signed-off-by: Miroslav Benes --- kernel/module.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index f57dd63186e6..67160ca8110e 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -313,8 +313,9 @@ struct load_info { } index; }; -/* We require a truly strong try_module_get(): 0 means failure due to - ongoing or failed initialization etc. */ +/* We require a truly strong try_module_get(): 0 means success. + * Otherwise an error is returned due to ongoing or failed + * initialization etc. */ static inline int strong_try_module_get(struct module *mod) { BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED); -- 2.10.2