The module notifier call chain for MODULE_STATE_COMING was moved up before
the parsing of args, into the complete_formation() call. But if the module failed
to load after that, the notifier call chain for MODULE_STATE_GOING was
never called and that prevented the users of those call chains from
cleaning up anything that was allocated.
Link: http://lkml.kernel.org/r/[email protected]
Reported-by: Pontus Fuchs <[email protected]>
Fixes: 4982223e51e8 "module: set nx before marking module MODULE_STATE_COMING"
Cc: [email protected] # 3.16+
Signed-off-by: Steven Rostedt <[email protected]>
---
kernel/module.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/module.c b/kernel/module.c
index 42a1d2afb217..cfc9e843a924 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3370,6 +3370,9 @@ static int load_module(struct load_info *info, const char __user *uargs,
module_bug_cleanup(mod);
mutex_unlock(&module_mutex);
+ blocking_notifier_call_chain(&module_notify_list,
+ MODULE_STATE_GOING, mod);
+
/* we can't deallocate the module until we clear memory protection */
unset_module_init_ro_nx(mod);
unset_module_core_ro_nx(mod);
--
1.8.3.1
On Fri, 8 May 2015 11:17:36 -0400
Steven Rostedt <[email protected]> wrote:
>
> The module notifier call chain for MODULE_STATE_COMING was moved up before
> the parsing of args, into the complete_formation() call. But if the module failed
> to load after that, the notifier call chain for MODULE_STATE_GOING was
> never called and that prevented the users of those call chains from
> cleaning up anything that was allocated.
>
> Link: http://lkml.kernel.org/r/[email protected]
You can nuke the "Link". I didn't realize Pontus didn't Cc any mailing
lists, and I manually just added it. Usually my scripts will check if
lkml was Cc'd and only add the "Link" tag if it was. Just shows you
that my scripts are smarter than I am.
-- Steve
>
> Reported-by: Pontus Fuchs <[email protected]>
> Fixes: 4982223e51e8 "module: set nx before marking module MODULE_STATE_COMING"
> Cc: [email protected] # 3.16+
> Signed-off-by: Steven Rostedt <[email protected]>
> ---
> kernel/module.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 42a1d2afb217..cfc9e843a924 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3370,6 +3370,9 @@ static int load_module(struct load_info *info, const char __user *uargs,
> module_bug_cleanup(mod);
> mutex_unlock(&module_mutex);
>
> + blocking_notifier_call_chain(&module_notify_list,
> + MODULE_STATE_GOING, mod);
> +
> /* we can't deallocate the module until we clear memory protection */
> unset_module_init_ro_nx(mod);
> unset_module_core_ro_nx(mod);
Steven Rostedt <[email protected]> writes:
> On Fri, 8 May 2015 11:17:36 -0400
> Steven Rostedt <[email protected]> wrote:
>
>>
>> The module notifier call chain for MODULE_STATE_COMING was moved up before
>> the parsing of args, into the complete_formation() call. But if the module failed
>> to load after that, the notifier call chain for MODULE_STATE_GOING was
>> never called and that prevented the users of those call chains from
>> cleaning up anything that was allocated.
>>
>> Link: http://lkml.kernel.org/r/[email protected]
>
> You can nuke the "Link". I didn't realize Pontus didn't Cc any mailing
> lists, and I manually just added it. Usually my scripts will check if
> lkml was Cc'd and only add the "Link" tag if it was. Just shows you
> that my scripts are smarter than I am.
Thanks for this.
Applied,
Rusty.