Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 31 Oct 2018 10:18:59 +0100
From: Peter Zijlstra <>
To: Dave Hansen <>
Cc: Matthew Wilcox <>,
	Andy Lutomirski <>,
	Kees Cook <>,
	Igor Stoppa <>,
	Mimi Zohar <>,
	Dave Chinner <>,
	James Morris <>, Michal Hocko <>,
	Kernel Hardening <>,
	linux-integrity <>,
	linux-security-module <>,
	Igor Stoppa <>,
	Dave Hansen <>,
	Jonathan Corbet <>, Laura Abbott <>,
	Randy Dunlap <>,
	Mike Rapoport <>,
	"open list:DOCUMENTATION" <>,
	LKML <>,
	Thomas Gleixner <>
Subject: Re: [PATCH 10/17] prmem: documentation

On Tue, Oct 30, 2018 at 11:03:51AM -0700, Dave Hansen wrote:
> On 10/30/18 10:58 AM, Matthew Wilcox wrote:
> > Does this satisfy Igor's requirements?  We wouldn't be able to
> > copy_to/from_user() while rare_mm was active.  I think that's a feature
> > though!  It certainly satisfies my interests (kernel code be able to
> > mark things as dynamically-allocated-and-read-only-after-initialisation)
> It has to be more than copy_to/from_user(), though, I think.
> rare_modify(q) either has to preempt_disable(), or we need to teach the
> context-switching code when and how to switch in/out of the rare_mm.
> preempt_disable() would also keep us from sleeping.

Yes, I think we want to have preempt disable at the very least. We could
indeed make the context switch code smart and teach is about this state,
but I think allowing preemption in such section is a bad idea. We want
to keep these sections short and simple (and bounded), such that they
can be analyzed for correctness.

Once you allow preemption, things tend to grow large and complex.

Ideally we'd even disabled interrupts over this, to further limit what
code runs in the rare_mm context. NMIs need special care anyway.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.