From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932682AbaEEOKu (ORCPT ); Mon, 5 May 2014 10:10:50 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:33794 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932542AbaEEOKt (ORCPT ); Mon, 5 May 2014 10:10:49 -0400 Date: Mon, 5 May 2014 16:10:44 +0200 From: Frederic Weisbecker To: Josh Poimboeuf Cc: Ingo Molnar , Seth Jennings , Masami Hiramatsu , Steven Rostedt , Ingo Molnar , Jiri Slaby , linux-kernel@vger.kernel.org, Peter Zijlstra , Andrew Morton , Linus Torvalds , Thomas Gleixner Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching Message-ID: <20140505141038.GA27403@localhost.localdomain> References: <20140505085537.GA32196@gmail.com> <20140505132638.GA14432@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140505132638.GA14432@treble.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 05, 2014 at 08:26:38AM -0500, Josh Poimboeuf wrote: > On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote: > > > > * Josh Poimboeuf wrote: > > > > > [...] > > > > > > kpatch checks the backtraces of all tasks in stop_machine() to > > > ensure that no instances of the old function are running when the > > > new function is applied. I think the biggest downside of this > > > approach is that stop_machine() has to idle all other CPUs during > > > the patching process, so it inserts a small amount of latency (a few > > > ms on an idle system). > > > > When live patching the kernel, how about achieving an even 'cleaner' > > state for all tasks in the system: to freeze all tasks, as the suspend > > and hibernation code (and kexec) does, via freeze_processes()? > > > > That means no tasks in the system have any real kernel execution > > state, and there's also no problem with long-sleeping tasks, as > > freeze_processes() is supposed to be fast as well. > > > > I.e. go for the most conservative live patching state first, and relax > > it only once the initial model is upstream and is working robustly. > > I had considered doing this before, but the problem I found is that many > kernel threads are unfreezable. So we wouldn't be able to check whether > its safe to replace any functions in use by those kernel threads. OTOH many kernel threads are parkable. Which achieves kind of similar desired behaviour: the kernel threads then aren't running. And in fact we could implement freezing on top of park for kthreads. But unfortunately there are still quite some of them which don't support parking.