Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1346295 > unrolled thread
| Started by | Rusty Russell <rusty@rustcorp.com.au> |
|---|---|
| First post | 2016-03-01 03:10 +0100 |
| Last post | 2016-03-01 04:10 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v4 4/4] livepatch/module: remove livepatch module notifier Rusty Russell <rusty@rustcorp.com.au> - 2016-03-01 03:10 +0100
Re: livepatch/module: remove livepatch module notifier Jessica Yu <jeyu@redhat.com> - 2016-03-01 04:10 +0100
| From | Rusty Russell <rusty@rustcorp.com.au> |
|---|---|
| Date | 2016-03-01 03:10 +0100 |
| Subject | Re: [PATCH v4 4/4] livepatch/module: remove livepatch module notifier |
| Message-ID | <r7HV9-2Mh-9@gated-at.bofh.it> |
Jiri Kosina <jikos@kernel.org> writes: > On Wed, 10 Feb 2016, Rusty Russell wrote: > >> > Remove the livepatch module notifier in favor of directly enabling and >> > disabling patches to modules in the module loader. Hard-coding the >> > function calls ensures that ftrace_module_enable() is run before >> > klp_module_coming() during module load, and that klp_module_going() is >> > run before ftrace_release_mod() during module unload. This way, ftrace >> > and livepatch code is run in the correct order during the module >> > load/unload sequence without dependence on the module notifier call chain. >> > >> > This fixes a notifier ordering issue in which the ftrace module notifier >> > (and hence ftrace_module_enable()) for coming modules was being called >> > after klp_module_notify(), which caused livepatch modules to initialize >> > incorrectly. >> >> Without a Fixes: line, it's not absolutely clear whether this needs >> CC:stable, needs to go to Linus now, or can wait for the next merge >> window. >> >> I *think* you want all four merged this merge window, and 3 and 4 are >> required to fix a regression introduced since 4.4... > > Your understanding is correct; #3 and #4 are needed to fix a 4.4 > regression. It makes sense for the whole lot go to together, but for #1 > and #2 I absolutely need your Ack before I take it to my tree, as I don't > want to be merging this behind your back. > > Once you Ack #1 and #2, I plan to take this to Linus immediately so that > we avoid doing these changes as very last minute. Sorry Jiri, I am on paternity leave. Am happy with all these patches; please use your best judgement: Acked-by: Rusty Russell <rusty@rustcorp.com.au> Thanks, Rusty.
[toc] | [next] | [standalone]
| From | Jessica Yu <jeyu@redhat.com> |
|---|---|
| Date | 2016-03-01 04:10 +0100 |
| Subject | Re: livepatch/module: remove livepatch module notifier |
| Message-ID | <r7IRc-3lp-23@gated-at.bofh.it> |
| In reply to | #1346295 |
+++ Rusty Russell [29/02/16 11:00 +1030]: >Jiri Kosina <jikos@kernel.org> writes: >> On Wed, 10 Feb 2016, Rusty Russell wrote: >> >>> > Remove the livepatch module notifier in favor of directly enabling and >>> > disabling patches to modules in the module loader. Hard-coding the >>> > function calls ensures that ftrace_module_enable() is run before >>> > klp_module_coming() during module load, and that klp_module_going() is >>> > run before ftrace_release_mod() during module unload. This way, ftrace >>> > and livepatch code is run in the correct order during the module >>> > load/unload sequence without dependence on the module notifier call chain. >>> > >>> > This fixes a notifier ordering issue in which the ftrace module notifier >>> > (and hence ftrace_module_enable()) for coming modules was being called >>> > after klp_module_notify(), which caused livepatch modules to initialize >>> > incorrectly. >>> >>> Without a Fixes: line, it's not absolutely clear whether this needs >>> CC:stable, needs to go to Linus now, or can wait for the next merge >>> window. >>> >>> I *think* you want all four merged this merge window, and 3 and 4 are >>> required to fix a regression introduced since 4.4... >> >> Your understanding is correct; #3 and #4 are needed to fix a 4.4 >> regression. It makes sense for the whole lot go to together, but for #1 >> and #2 I absolutely need your Ack before I take it to my tree, as I don't >> want to be merging this behind your back. >> >> Once you Ack #1 and #2, I plan to take this to Linus immediately so that >> we avoid doing these changes as very last minute. > >Sorry Jiri, I am on paternity leave. Am happy with all these patches; >please use your best judgement: > >Acked-by: Rusty Russell <rusty@rustcorp.com.au> > Thanks Rusty. No worries, we got the regression out of the way already. :-) Jiri, I'll resend the remaining 3 patches in the series separately, since we've merged the ftrace patch already. Jessica
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web