Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756840AbcCaNMr (ORCPT ); Thu, 31 Mar 2016 09:12:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:35696 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752017AbcCaNMp (ORCPT ); Thu, 31 Mar 2016 09:12:45 -0400 Date: Thu, 31 Mar 2016 15:12:39 +0200 (CEST) From: Miroslav Benes To: Josh Poimboeuf cc: Jiri Kosina , Jessica Yu , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Vojtech Pavlik Subject: Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model In-Reply-To: <74a2b37cea7a64a185e50876dba031137aa59a24.1458933243.git.jpoimboe@redhat.com> Message-ID: References: <74a2b37cea7a64a185e50876dba031137aa59a24.1458933243.git.jpoimboe@redhat.com> 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 Content-Length: 1362 Lines: 42 On Fri, 25 Mar 2016, Josh Poimboeuf wrote: [...] > diff --git a/kernel/fork.c b/kernel/fork.c > index d277e83..27b181e 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -76,6 +76,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1615,6 +1616,7 @@ static struct task_struct *copy_process(unsigned long clone_flags, > total_forks++; > spin_unlock(¤t->sighand->siglock); > syscall_tracepoint_update(p); > + klp_update_task_universe(p); Shouldn't we copy transition and TIF from the parent? I deal with a race in kgraft and the solution seems to be this code exactly at this place in copy_process(). I need to think about it. [...] > +static void klp_schedule_work(void) > +{ > + if (IS_ENABLED(CONFIG_RELIABLE_STACKTRACE)) > + schedule_delayed_work(&klp_work, round_jiffies_relative(HZ)); > +} As mentioned in my cover letter reply I'd allow to schedule delayed work even for !CONFIG_RELIABLE_STACKTRACE archs and configurations. There is a check in klp_try_switch_task() for CONFIG_RELIABLE_STACKTRACE so the change should be trivial. The patching could be successful even without reliable stack traces especially in combination with a fake signal and a syscall boundary migration. Miroslav