Date: Wed, 23 Nov 2016 15:41:59 -0800
From: Jessica Yu <jeyu@redhat.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
        Aaron Tomlin <atomlin@redhat.com>, linux-kernel@vger.kernel.org,
        rostedt@goodmis.org
Subject: Re: module: Ensure a module's state is set accordingly during module
 coming cleanup code
Message-ID: <20161123234159.aji3xsnjxrlii55f@jeyu>
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>
 <alpine.LNX.2.00.1611161635330.12580@pobox.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <alpine.LNX.2.00.1611161635330.12580@pobox.suse.cz>
User-Agent: NeoMutt/20161014 (1.7.1)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2167
Lines: 57

+++ Miroslav Benes [16/11/16 16:49 +0100]:
>On Wed, 9 Nov 2016, Jessica Yu wrote:
>
>> +++ Rusty Russell [26/10/16 11:24 +1030]:
>> > Aaron Tomlin <atomlin@redhat.com> 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 <mbenes@suse.cz>
>
>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 <mbenes@suse.cz>
>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 <mbenes@suse.cz>

Thanks Miroslav, that comment was confusing and needed updating. I've
queued this on top of the other patches.

Jessica