lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 5 Jul 2014 22:04:52 +0200 (CEST)
From:	Jiri Kosina <>
To:	Tejun Heo <>
cc:	One Thousand Gnomes <>,
	Jiri Slaby <>,
	Stephen Rothwell <>,,,, Andrew Morton <>,,,
	Pavel Machek <>,,
	Vojtech Pavlik <>, Michael Matz <>
Subject: Re: kGraft to -next [was: 00/21 kGraft]

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 

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.


Jiri Kosina
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists