Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

From: John Hubbard
Date: Wed Dec 12 2018 - 14:13:31 EST

On 12/7/18 9:18 PM, Matthew Wilcox wrote:
> On Fri, Dec 07, 2018 at 04:52:42PM -0800, John Hubbard wrote:
>> I see. OK, HMM has done an efficient job of mopping up unused fields, and now we are
>> completely out of space. At this point, after thinking about it carefully, it seems clear
>> that it's time for a single, new field:
> Sorry for not replying earlier; I'm travelling and have had trouble
> keeping on top of my mail.

Hi Matthew,

> Adding this field will grow struct page by 4-8 bytes, so it will no
> longer be 64 bytes. This isn't an acceptable answer.

I had to ask, though, just in case the historical rules might no longer
be ask pressing. But OK.

> We have a few options for bits. One is that we have (iirc) two
> bits available in page->flags on 32-bit. That'll force a few more
> configurations into using _last_cpupid and/or page_ext. I'm not a huge
> fan of this approach.
> The second is to use page-> bit 1. This requires some care
> because m68k allows misaligned pointers. If the list_head that it's
> joined to is misaligned, we'll be in trouble. This can get tricky because
> some pages are attached to list_heads which are on the stack ... and I
> don't think gcc guarantees __aligned attributes work for stack variables.
> The third is to use page->lru.prev bit 0. We'd want to switch pgmap
> and hmm_data around to make this work, and we'd want to record this
> in mm_types.h so nobody tries to use a field which aliases with
> page->lru.prev and has bit 0 set on a page which can be mapped to
> userspace (which I currently believe to be true).
> The fourth is to use a bit in page->flags for 64-bit and a bit in
> page_ext->flags for 32-bit. Or we could get rid of page_ext and grow
> struct page with a ->flags2 on 32-bit.
> Fifth, it isn't clear to me how many bits might be left in ->_last_cpupid
> at this point, and perhaps there's scope for using a bit in there.

Thanks for taking the time to collect and explain all of this, I'm stashing
it away as I'm sure it will come up again.

The latest approach to the gup/dma problem here might, or might not, actually
need a single page bit. I'll know in a day or two.

John Hubbard