Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 24 Aug 2021 20:37:41 +0300
From:   Mike Rapoport <rppt@linux.ibm.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "rppt@kernel.org" <rppt@kernel.org>,
        "Weiny, Ira" <ira.weiny@intel.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "vbabka@suse.cz" <vbabka@suse.cz>,
        "x86@kernel.org" <x86@kernel.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "Lutomirski, Andy" <luto@kernel.org>
Subject: Re: [RFC PATCH 3/4] mm/page_alloc: introduce __GFP_PTE_MAPPED flag
 to allocate pte-mapped pages
Message-ID: <YSUuZfUAub6wvG9L@linux.ibm.com>
References: <20210823132513.15836-1-rppt@kernel.org>
 <20210823132513.15836-4-rppt@kernel.org>
 <889bdfef8b4acbe840668f27782c3d39a987c368.camel@intel.com>
 <YSTt9XEDfbPOpab4@kernel.org>
 <f4a428040f822d7181acfc6c1658173373f28e40.camel@intel.com>
 <YSUkXqC7P+a0NZeE@linux.ibm.com>
 <c7ae898069360aff581be5eebeb74c0d03bb3bde.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c7ae898069360aff581be5eebeb74c0d03bb3bde.camel@intel.com>
Precedence: bulk

On Tue, Aug 24, 2021 at 05:23:04PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2021-08-24 at 19:54 +0300, Mike Rapoport wrote:
> > On Tue, Aug 24, 2021 at 04:38:03PM +0000, Edgecombe, Rick P wrote:
> > > On Tue, 2021-08-24 at 16:02 +0300, Mike Rapoport wrote:
> > > > > We probably want to exclude GFP_ATOMIC before calling into CPA
> > > > > unless
> > > > > debug page alloc is on, because it may need to split and sleep
> > > > > for
> > > > > the
> > > > > allocation. There is a page table allocation with GFP_ATOMIC
> > > > > passed
> > > > > actually.
> > > > 
> > > > Looking at the callers of alloc_low_pages() it seems that
> > > > GFP_ATOMIC
> > > > there
> > > > is stale...
> > > 
> > > Well two actually, there is also spp_getpage(). I tried to
> > > determine if
> > > that was also stale but wasn't confident. There were a lot of paths
> > > in.
> > 
> >   
> > It's also used at init and during memory hotplug, so I really doubt
> > it
> > needs GFP_ATOMIC.
> 
> Pretty sure it gets called after init by at least something besides
> hotplug. I saw it during debugging with a little sanitizer I built to
> find any unprotected page tables missed. Something tweaking the fixmap
> IIRC. Did you look at the set_fixmap_() and set_pte_vaddr() family of
> functions? Now whether any of them actually need GFP_ATOMIC, I am less
> sure. There were a fair amount of drivers to analyze.

Oh, I've missed set_pte_vaddr(). I still doubt anything that uses those two
would need GFP_ATOMIC, but it's surely way harder to analyze.

-- 
Sincerely yours,
Mike.