Received-SPF: pass (google.com: domain of linux-kernel+bounces-203450-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240605212146.994486-1-peterx@redhat.com> <CA+CK2bCCeamiaoTFybTd5nW39ixVPDM2gV2rMmK+2PfFAyE+9w@mail.gmail.com>
 <666100d39dee4_2d412294b3@dwillia2-mobl3.amr.corp.intel.com.notmuch>
In-Reply-To: <666100d39dee4_2d412294b3@dwillia2-mobl3.amr.corp.intel.com.notmuch>
From: Pasha Tatashin <pasha.tatashin@soleen.com>
Date: Wed, 5 Jun 2024 20:24:55 -0400
Message-ID: <CA+CK2bD2=Nd+wDtvphS-x+2xQWnMKwy-V4jVD2drV=xxKhqUnA@mail.gmail.com>
Subject: Re: [PATCH] mm/page_table_check: Fix crash on ZONE_DEVICE
To: Dan Williams <dan.j.williams@intel.com>
Cc: Peter Xu <peterx@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
	Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 5, 2024 at 8:20=E2=80=AFPM Dan Williams <dan.j.williams@intel.c=
om> wrote:
>
> Pasha Tatashin wrote:
> > On Wed, Jun 5, 2024 at 5:21=E2=80=AFPM Peter Xu <peterx@redhat.com> wro=
te:
> > >
> > > Not all pages may apply to pgtable check.  One example is ZONE_DEVICE
> > > pages: they map PFNs directly, and they don't allocate page_ext at al=
l even
> > > if there's struct page around.  One may reference devm_memremap_pages=
().
> > >
> > > When both ZONE_DEVICE and page-table-check enabled, then try to map s=
ome
> > > dax memories, one can trigger kernel bug constantly now when the kern=
el was
> > > trying to inject some pfn maps on the dax device:
> > >
> > >  kernel BUG at mm/page_table_check.c:55!
> > >
> > > While it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for=
 page
> > > fault resolutions, skip all the checks if page_ext doesn't even exist=
 in
> > > pgtable checker, which applies to ZONE_DEVICE but maybe more.
> >
> > Thank you for reporting this bug. A few comments below:
> >
> > >
> > > Cc: Dan Williams <dan.j.williams@intel.com>
> > > Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> > > Signed-off-by: Peter Xu <peterx@redhat.com>
> > > ---
> > >  mm/page_table_check.c | 11 ++++++++++-
> > >  1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/page_table_check.c b/mm/page_table_check.c
> > > index 4169576bed72..509c6ef8de40 100644
> > > --- a/mm/page_table_check.c
> > > +++ b/mm/page_table_check.c
> > > @@ -73,6 +73,9 @@ static void page_table_check_clear(unsigned long pf=
n, unsigned long pgcnt)
> > >         page =3D pfn_to_page(pfn);
> > >         page_ext =3D page_ext_get(page);
> > >
> > > +       if (!page_ext)
> > > +               return;
> >
> > I would replace the above with the following, here and in other places:
> >
> > if (!page_ext) {
> >   WARN_ONCE(!is_zone_device_page(page),
> >                           "page_ext is missing for a non-device page\n"=
);
> >   return;
> > }
>
> Hmm, but this function is silent for the !pfn_valid(@pfn) case, and the
> old cold has BUG_ON(!page_ext). So we know the caller is not being
> careful about @pfn, and existing code is likely avoiding the BUG_ON().
>
> The justification for the WARN_ONCE(), or maybe VM_WARN_ONCE(), would
> be if there is a high likelihood that ongoing kernel changes introduce
> more pfn_valid() but not page_ext covered pages? Is that a realistic
> scenario?

Good point, it is unlikely we will have scenarios without page_ext.
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>