linux-kernel - Re: [RFC 09/16] kgr: mark task

lists.openwall.net		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 linux-cve-announce 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:	Wed, 30 Apr 2014 20:33:27 +0200
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Jiri Slaby <jslaby@...e.cz>, linux-kernel@...r.kernel.org,
	jirislaby@...il.com, Michael Matz <matz@...e.de>,
	Jiri Kosina <jkosina@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Theodore Ts'o <tytso@....edu>,
	Dipankar Sarma <dipankar@...ibm.com>, Tejun Heo <tj@...nel.org>
Subject: Re: [RFC 09/16] kgr: mark task_safe in some kthreads

On Wed, Apr 30, 2014 at 09:55:32AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> > Some threads do not use kthread_should_stop. Before we enable a
> > kthread support in kgr, we must make sure all those mark themselves
> > safe explicitly.
> 
> Would it make sense to bury kgr_task_safe() in wait_event_interruptible()
> and friends?  The kgr_task_safe() implementation looks pretty lightweight,
> so it should not be a performance problem.

For userspace tasks, the kGraft in progress flag is cleared when
entering or exiting userspace. At that point it is safe to switch the
task to a post-patch world view.

For kernel threads, it's a bit more complicated: They never exit the
kernel, they keep executing within the kernel continuously. The
kgr_task_safe() call is thus inserted at a location within the main loop
where a 'new loop' begins - where there are no dependencies on results
of calls of functions from the previous loop.

Hence, putting kgr_task_safe() into every wait_event_interruptible()
wouldn't work, only a few of them are at that strategic spot where a
'new loop' can be indicated to kGraft.

The reason kgr_task_safe() is called from within the condition
evaluation statement in wait_event_interruptible() in this patch is
because we want it to be called as soon as a new loop begins - even if
that loop is empty because the condition to stop waiting has not been
met.

This also means that kGraft currently cannot patch the main loops of
kernel threads themselves as the thread of execution never exits them.

Jiří (Slabý) has some ideas about how to do without calling
kgr_task_safe() from within the kernel thread main loops, but for now,
the goal is to keep things simple and easy to understand.

> One reason might this might be a bad idea is that there are calls to
> wait_event_interruptible() all over the place, which might therefore
> constrain where grafting could be safely done.  That would be fair enough,
> but does that also imply new constraints on where kthread_should_stop()
> can be invoked?  Any new constraints might not be a big deal given that
> a very large fraction of the kthreads (and maybe all of them) invoke
> kthread_should_stop() from their top-level function, but would be good
> to call out.

> So, what is the story?

kGraft currently assumes that kthread_should_stop() is always in a part
of the main loop which doesn't carry over effect dependencies from the
previous iteration. This is currently true for all the uses of
kthread_should_stop(), but indeed it is an additional constraint for the
future.

Vojtech
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/