Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751768AbbBVIqL (ORCPT ); Sun, 22 Feb 2015 03:46:11 -0500 Received: from mail-we0-f171.google.com ([74.125.82.171]:39611 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbbBVIqH (ORCPT ); Sun, 22 Feb 2015 03:46:07 -0500 Date: Sun, 22 Feb 2015 09:46:01 +0100 From: Ingo Molnar To: Jiri Kosina Cc: Vojtech Pavlik , Josh Poimboeuf , Peter Zijlstra , Andrew Morton , Ingo Molnar , Seth Jennings , linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task_call()) Message-ID: <20150222084601.GA23491@gmail.com> References: <20150220104418.GD25076@gmail.com> <20150220194901.GB3603@gmail.com> <20150220214613.GA21598@suse.com> <20150221181852.GA8406@gmail.com> <20150221191607.GA9534@gmail.com> <20150221194840.GA10126@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3049 Lines: 81 * Jiri Kosina wrote: > > > Or think of kernel that has some 3rd party vendor > > > module loaded, and this module spawning a ktrehad > > > that is not capable of parking itself. > > > > The kernel will refuse to live patch until the module > > is fixed. It is a win by any measure. > > Depends on your point of view. If you are an > administrator of the vulnerable system, you have no to > very little clue why patching your system is not possible > (and what you should to to have it fixed in the coming > days, before your system is taken down by attackers, for > example), and would be really sad to be forced to run > with unpatched system. I don't see what precise argument you are making here. That we are unable to fix possible bugs in binary only modules? News at 11. Or are you making the argument that we should design our core kernel capabilities to be deficient, just to accomodate hypothetical scenarios with buggy third party modules that create unparkable kernel threads? That would be a crazy proposition. > > Why would __notrace__ functions be a problem in the > > 'simple' method? Live patching with this method will > > work even if ftrace is not built in, we can just patch > > out the function in the simplest possible fashion, > > because we do it atomically and don't have to worry > > about per task 'transition state' - like kGraft does. > > > > It's a massive simplification and there's no need to > > rely on ftrace's mcount trick. (Sorry Steve!) > > This would indeed be possible iff we take the "global > synchronizing point" aproach you are proposing. [...] Yes. > [...] Still technicalities to be solved (what happens if > you are patching that already has ftrace on it, etc), but > probably nothing principal. Correct. > > > So it's not black and white, it's really a rather > > > philosophical question where to draw the line (and > > > make sure that everyone is aware of where the line is > > > and what it means). > > > > Out of the three examples you mentioned, two are > > actually an advantage to begin with - so I'd suggest > > you stop condescending me ... > > Ugh, if you feel my e-mails like attempts to condescend > you, I am really surprised; I thought we are discussing > technical details. If you feel otherwise, we should > probably just stop discussing then. I am making specific technical arguments, but you attempted to redirect my very specific arguments towards 'differences in philosophy' and 'where to draw the line'. Lets discuss the merits and brush them aside as 'philosophical differences' or a made up category of 'consistency models'. Anyway, let me try to reboot this discussion back to technological details by summing up my arguments in another mail. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/