From: Jiri Kosina <jkosina@suse.cz>
To: Tejun Heo <tj@kernel.org>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Jiri Slaby <jslaby@suse.cz>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kernel@vger.kernel.org, rostedt@goodmis.org,
mingo@redhat.com, Andrew Morton <akpm@linux-foundation.org>,
andi@firstfloor.org, paulmck@linux.vnet.ibm.com,
Pavel Machek <pavel@ucw.cz>,
jirislaby@gmail.com, Vojtech Pavlik <vojtech@suse.cz>,
Michael Matz <matz@suse.de>
Subject: Re: kGraft to -next [was: 00/21 kGraft]
Date: Sat, 5 Jul 2014 22:04:52 +0200 (CEST) [thread overview]
Message-ID: <alpine.LNX.2.00.1407052148410.1655@pobox.suse.cz> (raw)
In-Reply-To: <20140702133053.GB20071@mtj.dyndns.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
next prev parent reply other threads:[~2014-07-05 20:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 11:05 [PATCH 00/21] kGraft Jiri Slaby
2014-06-25 12:54 ` One Thousand Gnomes
2014-06-25 15:54 ` Jiri Kosina
2014-06-26 5:50 ` Vojtech Pavlik
2014-07-02 12:04 ` kGraft to -next [was: 00/21 kGraft] Jiri Slaby
2014-07-02 12:30 ` Tejun Heo
2014-07-02 12:47 ` One Thousand Gnomes
2014-07-02 13:01 ` Jiri Kosina
2014-07-02 13:30 ` Tejun Heo
2014-07-05 20:04 ` Jiri Kosina [this message]
2014-07-05 20:36 ` Tejun Heo
2014-07-05 20:49 ` Jiri Kosina
2014-07-05 21:04 ` Tejun Heo
2014-07-05 21:06 ` Jiri Kosina
2014-07-05 21:08 ` Tejun Heo
2014-07-29 14:05 ` Jiri Kosina
2014-07-02 12:47 ` Steven Rostedt
2014-07-02 16:28 ` Josh Poimboeuf
2014-07-03 0:26 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1407052148410.1655@pobox.suse.cz \
--to=jkosina@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jirislaby@gmail.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=matz@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pavel@ucw.cz \
--cc=rostedt@goodmis.org \
--cc=sfr@canb.auug.org.au \
--cc=tj@kernel.org \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.