All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Miroslav Benes <mbenes@suse.cz>,
	linux-kernel@vger.kernel.org, jpoimboe@redhat.com,
	jikos@kernel.org, pmladek@suse.com, rostedt@goodmis.org,
	ast@kernel.org, daniel@iogearbox.net
Subject: Re: [RFC][PATCH] module: Propagate MODULE_STATE_COMING notifier errors
Date: Fri, 21 Jun 2019 18:31:46 +0200	[thread overview]
Message-ID: <20190621163146.GB24038@linux-8ccs> (raw)
In-Reply-To: <20190619112350.GN3419@hirez.programming.kicks-ass.net>

+++ Peter Zijlstra [19/06/19 13:23 +0200]:
>On Wed, Jun 19, 2019 at 01:12:12PM +0200, Miroslav Benes wrote:
>> > @@ -3780,7 +3781,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
>> >
>> >  	err = prepare_coming_module(mod);
>> >  	if (err)
>> > -		goto bug_cleanup;
>> > +		goto coming_cleanup;
>>
>> Not good. klp_module_going() is not prepared to be called without
>> klp_module_coming() succeeding. "Funny" things might happen.
>
>Bah, I did look at that but failed to spot it :/
>
>> So it calls for more fine-grained error handling.
>
>Another approach that I considered was trying to re-iterate the notifier
>list up until the point we got, but that was fairly non-trivial and
>needed changes to the notifier crud itself.
>
>I'll try again.

Hm.. I would prefer if we didn't complicate the error handling too
much, especially since you mention it seems non-trivial, and it
doesn't look too nice. You also checked that calling the GOING without
the COMING notifiers should be safe, so I think we can keep things
simple. I tried to look at how other places in the kernel handle
blocking_notifier_call_chain() errors and the places that do look at
the error code (most invocations of blocking_notifier_call_chain()
seem to just ignore the return value) just call the opposing notifiers
(module "going" in our case) to cleanup. I also would not mind
breaking up prepare_coming_module() to refine the error handling, as I
mentioned in my other mail.

Thanks,

Jessica

  parent reply	other threads:[~2019-06-21 16:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17  9:03 [RFC][PATCH] module: Propagate MODULE_STATE_COMING notifier errors Peter Zijlstra
2019-06-17 23:18 ` Steven Rostedt
2019-06-19 11:12 ` Miroslav Benes
2019-06-19 11:23   ` Peter Zijlstra
2019-06-19 11:33     ` Peter Zijlstra
2019-06-19 11:35       ` Peter Zijlstra
2019-06-19 12:01         ` Peter Zijlstra
2019-06-21 16:31     ` Jessica Yu [this message]
2019-06-19 11:25   ` Peter Zijlstra
2019-06-19 11:56   ` Petr Mladek
2019-06-21 16:18   ` Jessica Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190621163146.GB24038@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.