From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757931AbcBJK05 (ORCPT ); Wed, 10 Feb 2016 05:26:57 -0500 Received: from mx2.suse.de ([195.135.220.15]:49856 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757704AbcBJKTA (ORCPT ); Wed, 10 Feb 2016 05:19:00 -0500 Date: Wed, 10 Feb 2016 11:18:58 +0100 (CET) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Rusty Russell cc: Jessica Yu , Josh Poimboeuf , Seth Jennings , Vojtech Pavlik , Miroslav Benes , Petr Mladek , Steven Rostedt , Ingo Molnar , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 4/4] livepatch/module: remove livepatch module notifier In-Reply-To: <87r3glzbzj.fsf@rustcorp.com.au> Message-ID: References: <1454993424-31031-1-git-send-email-jeyu@redhat.com> <1454993424-31031-5-git-send-email-jeyu@redhat.com> <87r3glzbzj.fsf@rustcorp.com.au> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks! -- Jiri Kosina SUSE Labs