Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1517880
| From | Jessica Yu <jeyu@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: module: Ensure a module's state is set accordingly during module coming cleanup code |
| Date | 2016-11-09 11:20 +0100 |
| Message-ID | <sBy94-5YV-19@gated-at.bofh.it> (permalink) |
| References | <suoet-1uW-3@gated-at.bofh.it> <suoeu-1uW-19@gated-at.bofh.it> <swlma-58c-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
+++ 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.
Jessica
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: module: Ensure a module's state is set accordingly during module coming cleanup code Jessica Yu <jeyu@redhat.com> - 2016-11-09 11:20 +0100
csiph-web