Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932658AbaGEUE5 (ORCPT ); Sat, 5 Jul 2014 16:04:57 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42756 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932086AbaGEUE4 (ORCPT ); Sat, 5 Jul 2014 16:04:56 -0400 Date: Sat, 5 Jul 2014 22:04:52 +0200 (CEST) From: Jiri Kosina To: Tejun Heo cc: One Thousand Gnomes , Jiri Slaby , Stephen Rothwell , linux-kernel@vger.kernel.org, rostedt@goodmis.org, mingo@redhat.com, Andrew Morton , andi@firstfloor.org, paulmck@linux.vnet.ibm.com, Pavel Machek , jirislaby@gmail.com, Vojtech Pavlik , Michael Matz Subject: Re: kGraft to -next [was: 00/21 kGraft] In-Reply-To: <20140702133053.GB20071@mtj.dyndns.org> Message-ID: References: <1403694329-3064-1-git-send-email-jslaby@suse.cz> <53B3F556.7050002@suse.cz> <20140702123002.GA20071@mtj.dyndns.org> <20140702134721.00163886@alan.etchedpixels.co.uk> <20140702133053.GB20071@mtj.dyndns.org> 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, 2 Jul 2014, Tejun Heo wrote: > > static inline bool try_to_freeze(void) > > { > > + kgr_task_safe(current); > > + > > if (!(current->flags & PF_NOFREEZE)) > > debug_check_no_locks_held(); > > return try_to_freeze_unsafe(); > > Heh, I'm totally confused now. Why is this correct? What guarantees > that context is not carried across try_to_freeze()? I think we need to take a step back now, and ask ourselves a question "What is the actual goal here?". What we need is to have a defined point in execution where we can draw a line between "old" and "new" universes. For processess that are crossing the userspace/kernelspace boundary, the obvious choice, that covers most of the use-cases, has been made. There are still scenarios where this aproach can't be just-blindly-applied(TM) for various reasons (changing lock order might cause deadlocks, there are cases where state is lingering between two user <-> kernel transitions, etc). So we'll need to provide guidelines for kGraft patch writers anyway. The same holds for the kernel threads -- until all (or most of) the kthreads are converted to workqueues, the obivous choice, that should cover most of the use-cases, has been made. But manual/human inspection is absolutely unavoidably necessary in any case. Please keep in mind that this is designed for fixes that need immediate response (getting bounds checking right, adding an extra check, adding a missing lock, etc -- please see my previous mail on this topic in the old thread). It's absolutely by design not intended for implementing whole new features or exchanging the whole kernel on the fly; there are other solutions for that (such as the criu-based thing). As such, we tend to interfere with the rest of the kernel as little as possible, but it inadverently brings drawbacks in the form of putting burden of more work to the actual kGraft patch writers. I don't see that as a bad thing. Thanks, -- Jiri Kosina SUSE Labs -- 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/