From: Alistair Popple <apopple@nvidia.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
peterx@redhat.com, Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH] mm/page_table_check: Fix crash on ZONE_DEVICE
Date: Thu, 06 Jun 2024 08:58:08 +1000 [thread overview]
Message-ID: <87wmn3q9lv.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <6660ec883d31c_1ad63294f4@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Dan Williams <dan.j.williams@intel.com> writes:
> [ add Alistair ]
>
> Peter Xu wrote:
>> 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 all 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 some
>> dax memories, one can trigger kernel bug constantly now when the kernel 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.
>
> This looks correct to me, and needed in the near term. You can add:
>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
>
> In the long term, the page_ext check may not be needed. I.e. the reason
> I added Alistair was in case his work to make DAX pages behave like
> typical pages for reference counting would also make them behave the
> same for the presence of page_ext.
It doesn't currently. However I did run into this bug while I was
developing those so please add:
Reviewed-by: Alistair Popple <apopple@nvidia.com>
next prev parent reply other threads:[~2024-06-05 22:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 21:21 [PATCH] mm/page_table_check: Fix crash on ZONE_DEVICE Peter Xu
2024-06-05 22:05 ` Andrew Morton
2024-06-06 13:14 ` Peter Xu
2024-06-05 22:54 ` Dan Williams
2024-06-05 22:58 ` Alistair Popple [this message]
2024-06-06 0:01 ` Pasha Tatashin
2024-06-06 0:20 ` Dan Williams
2024-06-06 0:24 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmn3q9lv.fsf@nvdebian.thelocal \
--to=apopple@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=peterx@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.