From: Peter Xu <peterx@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: James Houghton <jthoughton@google.com>,
David Hildenbrand <david@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-mm@kvack.org,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Jiang <dave.jiang@intel.com>,
x86@kernel.org, Hugh Dickins <hughd@google.com>,
Matthew Wilcox <willy@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Huang Ying <ying.huang@intel.com>,
Rik van Riel <riel@surriel.com>,
Nicholas Piggin <npiggin@gmail.com>,
Borislav Petkov <bp@alien8.de>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Dan Williams <dan.j.williams@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Oscar Salvador <osalvador@suse.de>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Rick P Edgecombe <rick.p.edgecombe@intel.com>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH v4 0/7] mm/mprotect: Fix dax puds
Date: Wed, 7 Aug 2024 17:47:13 -0400 [thread overview]
Message-ID: <ZrPrYdmyUDRdz1QN@x1n> (raw)
In-Reply-To: <20240807142316.bbad141a106093b6f36249e2@linux-foundation.org>
On Wed, Aug 07, 2024 at 02:23:16PM -0700, Andrew Morton wrote:
> On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu <peterx@redhat.com> wrote:
>
> >
> > Tests
> > =====
> >
> > What I did test:
> >
> > - cross-build tests that I normally cover [1]
> >
> > - smoke tested on x86_64 the simplest program [2] on dev_dax 1G PUD
> > mprotect() using QEMU's nvdimm emulations [3] and ndctl to create
> > namespaces with proper alignments, which used to throw "bad pud" but now
> > it'll run through all fine. I checked sigbus happens if with illegal
> > access on protected puds.
> >
> > - vmtests.
> >
> > What I didn't test:
> >
> > - fsdax: I wanted to also give it a shot, but only until then I noticed it
> > doesn't seem to be supported (according to dax_iomap_fault(), which will
> > always fallback on PUD_ORDER). I did remember it was supported before, I
> > could miss something important there.. please shoot if so.
>
> OK. Who are you addressing this question to?
Anyone who is familiar with fsdax + 1g. Maybe Matthew would be the most
suitable, but I didn't track further on fsdax.
>
> > - userfault wp-async: I also wanted to test userfault-wp async be able to
> > split huge puds (here it's simply a clear_pud.. though), but it won't
> > work for devdax anyway due to not allowed to do smaller than 1G faults in
> > this case. So skip too.
>
> Sounds OK. So that's an additional project if anyone cares enough?
Right.
>
> > - Power, as no hardware on hand.
>
> Hopefully the powerpc people can help with that. What tests do you ask
> that they run?
The test program [2] in cover letter should work as a very basic test; one
needs to setup the dax device to use 1g mapping first, though:
[2] https://github.com/xzpeter/clibs/blob/master/misc/dax.c
At least per my experience not much fancy things we can do there, e.g., I
think at least dev_dax has a limitation on vma split that it must be 1g
aligned when use 1g mappings, so even split can't happen (as iirc I used to
try some random mprotect on smaller ranges)..
Thanks,
--
Peter Xu
WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Oscar Salvador <osalvador@suse.de>,
Dan Williams <dan.j.williams@intel.com>,
James Houghton <jthoughton@google.com>,
Matthew Wilcox <willy@infradead.org>,
Nicholas Piggin <npiggin@gmail.com>,
Rik van Riel <riel@surriel.com>,
Dave Jiang <dave.jiang@intel.com>,
x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
Rick P Edgecombe <rick.p.edgecombe@intel.com>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
linuxppc-dev@lists.ozlabs.org,
Mel Gorman <mgorman@techsingularity.net>,
Hugh Dickins <hughd@google.com>, Borislav Petkov <bp@alien8.de>,
David Hildenbrand <david@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Vlastimil Babka <vbabka@suse.cz>,
Dave Hansen <dave.hansen@linux.intel.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Huang Ying <ying.huang@intel.com>
Subject: Re: [PATCH v4 0/7] mm/mprotect: Fix dax puds
Date: Wed, 7 Aug 2024 17:47:13 -0400 [thread overview]
Message-ID: <ZrPrYdmyUDRdz1QN@x1n> (raw)
In-Reply-To: <20240807142316.bbad141a106093b6f36249e2@linux-foundation.org>
On Wed, Aug 07, 2024 at 02:23:16PM -0700, Andrew Morton wrote:
> On Wed, 7 Aug 2024 15:48:04 -0400 Peter Xu <peterx@redhat.com> wrote:
>
> >
> > Tests
> > =====
> >
> > What I did test:
> >
> > - cross-build tests that I normally cover [1]
> >
> > - smoke tested on x86_64 the simplest program [2] on dev_dax 1G PUD
> > mprotect() using QEMU's nvdimm emulations [3] and ndctl to create
> > namespaces with proper alignments, which used to throw "bad pud" but now
> > it'll run through all fine. I checked sigbus happens if with illegal
> > access on protected puds.
> >
> > - vmtests.
> >
> > What I didn't test:
> >
> > - fsdax: I wanted to also give it a shot, but only until then I noticed it
> > doesn't seem to be supported (according to dax_iomap_fault(), which will
> > always fallback on PUD_ORDER). I did remember it was supported before, I
> > could miss something important there.. please shoot if so.
>
> OK. Who are you addressing this question to?
Anyone who is familiar with fsdax + 1g. Maybe Matthew would be the most
suitable, but I didn't track further on fsdax.
>
> > - userfault wp-async: I also wanted to test userfault-wp async be able to
> > split huge puds (here it's simply a clear_pud.. though), but it won't
> > work for devdax anyway due to not allowed to do smaller than 1G faults in
> > this case. So skip too.
>
> Sounds OK. So that's an additional project if anyone cares enough?
Right.
>
> > - Power, as no hardware on hand.
>
> Hopefully the powerpc people can help with that. What tests do you ask
> that they run?
The test program [2] in cover letter should work as a very basic test; one
needs to setup the dax device to use 1g mapping first, though:
[2] https://github.com/xzpeter/clibs/blob/master/misc/dax.c
At least per my experience not much fancy things we can do there, e.g., I
think at least dev_dax has a limitation on vma split that it must be 1g
aligned when use 1g mappings, so even split can't happen (as iirc I used to
try some random mprotect on smaller ranges)..
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-08-07 21:48 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 19:48 [PATCH v4 0/7] mm/mprotect: Fix dax puds Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 19:48 ` [PATCH v4 1/7] mm/dax: Dump start address in fault handler Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 19:48 ` [PATCH v4 2/7] mm/mprotect: Push mmu notifier to PUDs Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-08 15:33 ` Sean Christopherson
2024-08-08 15:33 ` Sean Christopherson
2024-08-08 21:21 ` Peter Xu
2024-08-08 21:21 ` Peter Xu
2024-08-08 21:31 ` Sean Christopherson
2024-08-08 21:31 ` Sean Christopherson
2024-08-08 21:47 ` Peter Xu
2024-08-08 21:47 ` Peter Xu
2024-08-08 22:45 ` Sean Christopherson
2024-08-08 22:45 ` Sean Christopherson
2024-08-07 19:48 ` [PATCH v4 3/7] mm/powerpc: Add missing pud helpers Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 19:48 ` [PATCH v4 4/7] mm/x86: Make pud_leaf() only care about PSE bit Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 22:22 ` Thomas Gleixner
2024-08-07 22:22 ` Thomas Gleixner
2024-08-08 14:54 ` Peter Xu
2024-08-08 14:54 ` Peter Xu
2024-08-09 12:08 ` Thomas Gleixner
2024-08-09 12:08 ` Thomas Gleixner
2024-08-09 13:53 ` Peter Xu
2024-08-09 13:53 ` Peter Xu
2024-08-07 19:48 ` [PATCH v4 5/7] mm/x86: arch_check_zapped_pud() Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 22:28 ` Thomas Gleixner
2024-08-07 22:28 ` Thomas Gleixner
2024-08-08 15:49 ` Peter Xu
2024-08-08 15:49 ` Peter Xu
2024-08-08 20:45 ` David Hildenbrand
2024-08-08 20:45 ` David Hildenbrand
2024-08-07 19:48 ` [PATCH v4 6/7] mm/x86: Add missing pud helpers Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 22:37 ` Thomas Gleixner
2024-08-07 22:37 ` Thomas Gleixner
2024-08-08 20:25 ` Peter Xu
2024-08-08 20:25 ` Peter Xu
2024-08-07 19:48 ` [PATCH v4 7/7] mm/mprotect: fix dax pud handlings Peter Xu
2024-08-07 19:48 ` Peter Xu
2024-08-07 21:17 ` [PATCH v4 0/7] mm/mprotect: Fix dax puds Andrew Morton
2024-08-07 21:17 ` Andrew Morton
2024-08-07 21:34 ` Peter Xu
2024-08-07 21:34 ` Peter Xu
2024-08-07 21:44 ` Andrew Morton
2024-08-07 21:44 ` Andrew Morton
2024-08-08 14:34 ` Peter Xu
2024-08-08 14:34 ` Peter Xu
2024-08-07 21:23 ` Andrew Morton
2024-08-07 21:23 ` Andrew Morton
2024-08-07 21:47 ` Peter Xu [this message]
2024-08-07 21:47 ` Peter Xu
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=ZrPrYdmyUDRdz1QN@x1n \
--to=peterx@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=bp@alien8.de \
--cc=christophe.leroy@csgroup.eu \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jthoughton@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=rick.p.edgecombe@intel.com \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=ying.huang@intel.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.