[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171115213434.GA6982@bombadil.infradead.org>
Date: Wed, 15 Nov 2017 13:34:34 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Tycho Andersen <tycho@...ho.ws>
Cc: Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, kernel-hardening@...ts.openwall.com,
Marco Benatto <marco.antonio.780@...il.com>,
Juerg Haefliger <juerg.haefliger@...onical.com>, x86@...nel.org
Subject: Re: Re: [PATCH v6 03/11] mm, x86: Add support for
eXclusive Page Frame Ownership (XPFO)
On Wed, Nov 15, 2017 at 08:20:57AM -0800, Tycho Andersen wrote:
> On Wed, Nov 15, 2017 at 06:58:35AM -0800, Matthew Wilcox wrote:
> > On Tue, Nov 14, 2017 at 11:00:20PM -0800, Dave Hansen wrote:
> > > On 11/14/2017 07:44 PM, Matthew Wilcox wrote:
> > > > We don't need to kmap in order to access MOVABLE allocations. kmap is
> > > > only needed for HIGHMEM allocations. So there's nothing wrong with ext4
> > > > or set_bh_page().
> > >
> > > Yeah, it's definitely not _buggy_.
> > >
> > > Although, I do wonder what we should do about these for XPFO. Should we
> > > just stick a kmap() in there and comment it? What we really need is a
> > > mechanism to say "use this as a kernel page" and "stop using this as a
> > > kernel page". kmap() does that... kinda. It's not a perfect fit, but
> > > it's pretty close.
> >
> > It'd be kind of funny if getting XPFO working better means improving
> > how well Linux runs on 32-bit machines with HIGHMEM. I think there's
> > always going to be interest in those -- ARM developed 36 bit physmem
> > before biting the bullet and going to arm64. Maybe OpenRISC will do
> > that next ;-)
>
> Oh, sorry, I didn't realize that this wasn't a bug. In any case, this
> seems like sort of an uphill battle -- lots of places are going to do
> stuff like this since it's legal, adding code to work around it just
> for XPFO seems like a lot of burden on the kernel. (Of course, I'm
> open to convincing :)
>
> How common are these MOVABLE allocations that the kernel does? What if
> we did some hybrid approach, where we re-map the lists based on
> MOVABLE/UNMOVABLE, but then check the actual GFP flags on allocation
> to see if they match what we set when populating the free list, and
> re-map accordingly if they don't.
The assumption is that HIGHMEM allocations aren't mapped (on 32-bit
systems) and so we always use kmap/kmap_atomic to access them.
The emphasis has been on moving the largest consumers of memory over to
HIGHMEM; we were trying to manage 64GB of memory in 1GB of kernel address
space, so the page cache was the first and obvious biggest consumer to
get booted out of the permanent mapping. I know page tables were also
pushed into HIGHMEM. So large chunks of the kernel use kmap() because they
don't know whether they'll be operating on highmem or lowmem, and it'll
do the right thing for either kind of memory.
I didn't think MOVABLE allocations were particularly common. But I haven't
been paying close attention to MM development.
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.
