Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 Aug 2021 18:48:47 +0000
From: "Edgecombe, Rick P" <>
To: "" <>
CC: "" <>,
	"" <>, ""
	<>, "Weiny, Ira" <>,
	"" <>,
	"" <>, "" <>,
	"" <>, ""
	<>, "Williams, Dan J" <>,
	"Lutomirski, Andy" <>, ""
	<>, "Hansen, Dave"
	<>, "" <>
Subject: Re: [RFC PATCH v2 10/19] x86/mm: Use alloc_table() for fill_pte(),

On Tue, 2021-08-31 at 11:47 +0300, Mike Rapoport wrote:
> On Mon, Aug 30, 2021 at 04:59:18PM -0700, Rick Edgecombe wrote:
> > fill_pte(), set_pte_vaddr(), etc allocate page tables with
> > spp_getpage(). Use alloc_table() for these allocations in order to
> > get
> > tables from the cache of protected pages when needed.
> I can't say I tracked all the users of set_pte_vaddr(), but I don't
> see a
> fundamental reason why spp_getpage() would need GFP_ATOMIC.
Yea, I couldn't find why it was done that way in the first place, and
there were almost too many callers to audit. I guess I could roll up my
sleeves an audit it all, but its not foolproof. Or put a warn for
atomic context and pull all of the GFP_ATOMIC code if it doesn't get
triggered after awhile. Also seems weird that it just panics here if
the allocation fails.

>  Even if there
> is a caller of set_pte_vaddr() that cannot sleep, it seems that page
> tables
> can be prepopulated so that set_pte_vaddr() will not need to allocate
> anything.  
Hmm, could work for the fixmap callers I guess (maybe already happening
in practice). Xen and a few other things seems to use this for non-
fixmap things, but it's during init and easier to audit.

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.