On Sat, Sep 06, 2025 at 08:56:48AM +0200, David Hildenbrand wrote:
> On 06.09.25 03:05, John Hubbard wrote:
> >
> > Probably a similar sentiment as Lorenzo here...the above diffs make the code
> > *worse* to read. In fact, I recall adding record_subpages() here long ago,
> > specifically to help cl
for (; refs; refs--)
> *(pages++) = page++;
> @@ -3024,6 +3025,7 @@ static int gup_fast_pud_leaf(pud_t orig, pud_t *pudp,
> unsigned long addr,
> return 0;
> }
> + pages += *nr;
> *nr += refs;
> for (; refs; r
On Fri, Aug 29, 2025 at 03:41:40PM +0200, David Hildenbrand wrote:
> On 28.08.25 18:37, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:22AM +0200, David Hildenbrand wrote:
> > > nth_page() is no longer required when iterating over pages within a
> > > single f
On Fri, Aug 29, 2025 at 03:44:20PM +0200, David Hildenbrand wrote:
> On 29.08.25 14:51, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 10:51:46PM +0200, David Hildenbrand wrote:
> > > On 28.08.25 18:57, Lorenzo Stoakes wrote:
> > > > On Thu, Aug 28, 2025 at 12:01
On Fri, Aug 29, 2025 at 04:34:54PM +0200, David Hildenbrand wrote:
> On 28.08.25 19:28, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:25AM +0200, David Hildenbrand wrote:
> > > Let's disallow handing out PFN ranges with non-contiguous pages, so we
> > >
On Thu, Aug 28, 2025 at 10:51:46PM +0200, David Hildenbrand wrote:
> On 28.08.25 18:57, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:24AM +0200, David Hildenbrand wrote:
> > > Let's make it clearer that we are operating within a single folio by
> > >
On Fri, Aug 29, 2025 at 12:06:21PM +0200, David Hildenbrand wrote:
> On 28.08.25 16:37, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:10AM +0200, David Hildenbrand wrote:
> > > Let's reject them early, which in turn makes folio_alloc_gigantic() reject
> > &g
On Fri, Aug 29, 2025 at 12:07:44PM +0200, David Hildenbrand wrote:
> On 28.08.25 16:45, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:12AM +0200, David Hildenbrand wrote:
> > > Let's check that no hstate that corresponds to an unreasonable folio size
&g
On Fri, Aug 29, 2025 at 12:10:30PM +0200, David Hildenbrand wrote:
> On 28.08.25 17:00, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:14AM +0200, David Hildenbrand wrote:
> > > Let's sanity-check in folio_set_order() whether we would be trying to
> > > c
On Fri, Aug 29, 2025 at 02:02:02PM +0200, David Hildenbrand wrote:
> On 28.08.25 17:45, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:19AM +0200, David Hildenbrand wrote:
> > > The nth_page() is not really required anymore, so let's remove it.
> > > While
On Fri, Aug 29, 2025 at 01:59:19PM +0200, David Hildenbrand wrote:
> On 28.08.25 17:37, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:17AM +0200, David Hildenbrand wrote:
> > > We can now safely iterate over all pages in a folio, so no need for the
> > > pfn_
On Fri, Aug 29, 2025 at 01:57:22PM +0200, David Hildenbrand wrote:
> On 28.08.25 17:10, Lorenzo Stoakes wrote:
> > On Thu, Aug 28, 2025 at 12:01:15AM +0200, David Hildenbrand wrote:
> > > Let's limit the maximum folio size in problematic kernel config where
> > > th
comparison.
>
> Signed-off-by: David Hildenbrand
Nice! :)
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/bvec.h | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/bvec.h b/include/linux/bvec.h
> index 0a80e1f9aa2
l configs.
Sounds iffy though.
>
> Let's keep it simple and simply use pfn_to_page() by iterating PFNs.
Yes.
>
> Cc: Alexander Potapenko
> Cc: Marco Elver
> Cc: Dmitry Vyukov
> Signed-off-by: David Hildenbrand
Stared at this and can't see anything wrong, so -
On Thu, Aug 28, 2025 at 12:01:40AM +0200, David Hildenbrand wrote:
> Now that all users are gone, let's remove it.
>
> Signed-off-by: David Hildenbrand
HAPPY DAYYS
Happy to have reached this bit, great work! :)
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
>
E.J. Bottomley"
> Cc: "Martin K. Petersen"
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/scsi/sg.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
ay, on that basis, LGTM (though 1 small nit below), so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/gup.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 89ca0813791ab..c24f6009a7a44 100644
> --- a/mm/gup.c
> +++ b/m
avid Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> crypto/ahash.c | 4 ++--
> crypto/scompress.c | 8
> include/crypto/scatterwalk.h | 4 ++--
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/crypto/ahash.c b
: Shameer Kolothum
> Cc: Kevin Tian
> Cc: Alex Williamson
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/vfio/pci/pds/lm.c | 3 +--
> drivers/vfio/pci/virtio/migrate.c | 3 +--
> 2 files changed, 2 insertions(+), 4 delet
gt; Cc: "Martin K. Petersen"
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/scsi/scsi_lib.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.
Cc: Jesper Nilsson
> Cc: Lars Persson
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/mmc/host/tifm_sd.c| 4 ++--
> drivers/mmc/host/usdhi6rol0.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/
c: Ulf Hansson
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/memstick/host/jmb38x_ms.c | 3 +--
> drivers/memstick/host/tifm_ms.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/memstick/hos
c: Ulf Hansson
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/memstick/core/mspro_block.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/memstick/core/mspro_block.c
> b/drivers/memstick/cor
Cc: Tvrtko Ursulin
> Cc: David Airlie
> Cc: Simona Vetter
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/
nbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/ata/libata-sff.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 7fc407255eb46..1e2a2c33cdc80 100644
> --- a/drivers/
rote end of this first :)
>
> We can now drop the nth_page() usage in sg_page_iter_page().
>
> Acked-by: Marek Szyprowski
> Signed-off-by: David Hildenbrand
All LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/scatterlist.h | 3 ++-
> mm/util.c
will hand out problematic page
> ranges.
>
> Acked-by: Marek Szyprowski
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Signed-off-by: David Hildenbrand
Nice!
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> kernel/dma/remap.c | 2 +-
> 1 file changed, 1 insertion(+),
ed-off-by: David Hildenbrand
LGTM other than refactoring point below.
CMA stuff looks fine afaict after staring at it for a while, on proviso
that handing out ranges within the same section is always going to be the
case.
Anyway overall,
LGTM, so:
Reviewed-by: Lorenzo Stoakes
On Thu, Aug 28, 2025 at 12:01:24AM +0200, David Hildenbrand wrote:
> Let's make it clearer that we are operating within a single folio by
> providing both the folio and the page.
>
> This implies that for flush_dcache_folio() we'll now avoid one more
> page->folio lookup, and that we can safely dro
l Begunkov
> Signed-off-by: David Hildenbrand
On basis of src pages being within the same folio, LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> io_uring/zcrx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
>
anding suggestion below, LGTM and:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/gup.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index b2a78f0291273..89ca0813791ab 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -488,12
On Thu, Aug 28, 2025 at 12:01:21AM +0200, David Hildenbrand wrote:
> It's no longer required to use nth_page() within a folio, so let's just
> drop the nth_page() in folio_walk_start().
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
>
re than 1.
Lord above.
Also semantics of 'if bytes == 0, then check first page anyway' which you do
capture.
OK think I have convinced myself this is right, so hopefully no deeply subtle
off-by-one issues here :P
Anyway, LGTM, so:
Reviewed-by: Lorenzo Stoak
ned-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> fs/hugetlbfs/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 34d496a2b7de6..c5a46d10afaa0 100644
> --- a/fs/hugetlbf
Oh hello! Now it all comes together :)
nth_tag():
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/percpu-km.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/percpu-km.c b/mm/percpu-km.c
> index fe31aa19db81a..4efa74a495cb6 100644
> --
vmemmap.
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/hugetlb.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4a97e4f14c0dc..1f42186a85ea
> kernel doc for folio_page_idx().
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/mm.h | 16 ++--
> include/linux/page-flags.h | 5 -
> 2 files changed, 18 insertions(+), 3 d
page / folio.
>
> Reviewed-by: Zi Yan
> Acked-by: Mike Rapoport (Microsoft)
> Signed-off-by: David Hildenbrand
Realy great comments, like this!
I wonder if we could have this be part of the first patch where you fiddle
with MAX_FOLIO_ORDER etc. but not a big deal.
Anyway LGTM,
ge is initialized
> through prepare_compound_head() / prepare_compound_page().
NIT: with CONFIG_DEBUG_VM set :)
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
LGTM (apart from nit below), so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/internal.h | 1 +
> 1 file chang
Mike Rapoport (Microsoft)
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/mm_init.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index 5c21b3af216b2..df614556741a
his check:
> either SPARSEMEM without SPARSEMEM_VMEMMAP cannot be configured or
> gigantic folios will not exceed a memory section (the case on sparse).
I am guessing it's implicit that MAX_FOLIO_ORDER <= section size?
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by:
gt; Acked-by: SeongJae Park
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/memremap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/memremap.c b/mm/memremap.c
> index b0ce0d8254bd8..a2d4bb88f64b6 100644
> --- a/mm/
IO_NR_PAGES based on that.
>
> Reviewed-by: Zi Yan
> Acked-by: SeongJae Park
> Signed-off-by: David Hildenbrand
Some nits, but overall LGTM so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/mm.h | 6 --
> mm/page_alloc.c| 5 -
> 2 files changed, 8 insertions(
(Microsoft)
> Cc: "Jason A. Donenfeld"
> Cc: Shuah Khan
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> tools/testing/selftests/wireguard/qemu/kernel.config | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/tes
Hansen
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 58d890fe2100e..e431d1c06fecd 100644
> --- a/arch/x86/Kconf
Cc: Alexander Gordeev
> Cc: Christian Borntraeger
> Cc: Sven Schnelle
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> arch/s390/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfi
t (Microsoft)
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> arch/arm64/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e9bbfacc3
d-by: SeongJae Park
> Cc: Huacai Chen
> Cc: WANG Xuerui
> Cc: Madhavan Srinivasan
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: Alexandre Ghiti
> Cc: "David S. Miller"
On Thu, Aug 21, 2025 at 11:30:43AM +0200, David Hildenbrand wrote:
> > I will add this xen/apply_to_page_range() thing to my TODOs, which atm
> > would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
> >
>
> Busy today (want to reply to Christian) but
>
> a) Re: performance, we
+cc Liam as he's also had some fun with PAT in the past.
On Wed, Aug 20, 2025 at 05:23:07PM +0200, David Hildenbrand wrote:
> CCing Lorenzo
>
> On 20.08.25 16:33, Christian König wrote:
> > Hi everyone,
> >
> > sorry for CCing so many people, but that rabbit hole turned out to be
> > deeper than o
On Tue, Jun 17, 2025 at 09:45:32AM -0400, Jeff Layton wrote:
> On Mon, 2025-06-16 at 21:41 +0100, Al Viro wrote:
> > On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:
> > > REVIEWER'S NOTES
> > >
> > >
> > > I am bas
On Tue, Jun 17, 2025 at 03:05:59PM +0100, David Howells wrote:
> Lorenzo Stoakes wrote:
>
> > This is preferred to the existing f_op->mmap() hook as it does require a
> > VMA to be established yet,
>
> Did you mean ".. doesn't require a VMA to be established
On Thu, May 29, 2025 at 04:32:04PM +1000, Alistair Popple wrote:
> Previously dax pages were skipped by the pagewalk code as pud_special() or
> vm_normal_page{_pmd}() would be false for DAX pages. Now that dax pages are
> refcounted normally that is no longer the case, so add explicit checks to
> s
On Tue, May 13, 2025 at 11:10:45AM +0200, David Hildenbrand wrote:
> On 12.05.25 18:42, Lorenzo Stoakes wrote:
> > On Mon, May 12, 2025 at 02:34:17PM +0200, David Hildenbrand wrote:
> > > Let's use our new interface. In remap_pfn_range(), we'll now decide
> > &g
learer.
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype_interval.c | 33 +-
> 1 file changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/arch/x86/mm/pat/memtype_interval.c
> b/arch/x86/mm/pat/memtype_interval.c
> index 9d03f
be an issue, we could hook into VM splitting
> code and split the tracking; however, that adds complexity that might
> not be required, so we'll keep it simple for now.
>
> Acked-by: Ingo Molnar # x86 bits
> Signed-off-by: David Hildenbrand
Other than small nit belo
d and this looks good to me :)
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype.c | 24 ++
> include/linux/pgtable.h | 52 +--
> mm/huge_memory.c | 5 ++--
> mm/memory.c | 4 +--
> 4 file
On Wed, May 07, 2025 at 03:25:42PM +0200, David Hildenbrand wrote:
> > >
> > > Obviously my series will break this but should be _fairly_ trivial to
> > > update.
> > >
> > > You will however have to make sure to update tools/testing/vma/* to handle
> > > the new functions in userland testing (they
On Mon, May 05, 2025 at 02:10:53PM +0200, David Hildenbrand wrote:
> On 28.04.25 22:23, Lorenzo Stoakes wrote:
> > On Fri, Apr 25, 2025 at 10:17:13AM +0200, David Hildenbrand wrote:
> > > The "memramp() shrinking" scenario no longer applies, so let's remove
&g
On Fri, Apr 25, 2025 at 10:17:14AM +0200, David Hildenbrand wrote:
> track_pfn() does not exist, let's simply refer to it as "pfnmap
> tracking".
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/gpu/drm/i915/i915_mm.c | 4 ++-
l.
>
> Signed-off-by: David Hildenbrand
More lovely removal...
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype_interval.c | 44 --
> 1 file changed, 6 insertions(+), 38 deletions(-)
>
> diff --git a/arch/x86/mm/pat/memtype_interval
On Fri, Apr 25, 2025 at 10:17:12AM +0200, David Hildenbrand wrote:
> Always set to 0, so let's remove it.
>
> Signed-off-by: David Hildenbrand
Ah yes here is where you remove it :)
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype.c | 12 +++-
e!
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype.c | 147 --
> include/linux/pgtable.h | 66 -
> 2 files changed, 213 deletions(-)
>
> diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> i
On Fri, Apr 25, 2025 at 10:17:11AM +0200, David Hildenbrand wrote:
> It's unused, so let's remove it.
>
> Signed-off-by: David Hildenbrand
I have only <3 for this patch :) beee VM_PAT!
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/mm.h | 4
On Fri, Apr 25, 2025 at 10:17:09AM +0200, David Hildenbrand wrote:
> Let's use our new interface. In remap_pfn_range(), we'll now decide
> whether we have to track (full VMA covered) or only sanitize the pgprot
> (partial VMA covered).
Yeah I do agree with Peter that 'sanitize' is not great here,
+cc Suren, who has worked HEAVILY on VMA field manipulation and such :)
Suren - David is proposing adding a new field. AFAICT this does not add a
new cache line so I think we're all good.
But FYI!
On Fri, Apr 25, 2025 at 10:17:09AM +0200, David Hildenbrand wrote:
> Let's use our new interface. I
On Mon, Apr 28, 2025 at 07:23:18PM +0200, David Hildenbrand wrote:
> On 28.04.25 18:24, Peter Xu wrote:
> > On Mon, Apr 28, 2025 at 06:16:21PM +0200, David Hildenbrand wrote:
> > > > Probably due to what config you have. E.g., when I'm looking mine it's
> > > > much bigger and already consuming 25
On Mon, Apr 28, 2025 at 07:12:11PM +0200, David Hildenbrand wrote:
>
> > >
> > > +int pfnmap_track(unsigned long pfn, unsigned long size, pgprot_t *prot)
> > > +{
> > > + const resource_size_t paddr = (resource_size_t)pfn << PAGE_SHIFT;
> > > +
> > > + return reserve_pfn_range(paddr, size, prot, 0)
this should be
merged with prior patch, though FWIW:
Reviewed-by: Lorenzo Stoakes
> > ---
> > mm/memremap.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/memremap.c b/mm/memremap.c
> > index 2aebc1b192da9..c417c8
On Fri, Apr 25, 2025 at 04:00:42PM -0400, Peter Xu wrote:
> On Fri, Apr 25, 2025 at 10:17:08AM +0200, David Hildenbrand wrote:
> > Let's use the new, cleaner interface.
> >
> > Signed-off-by: David Hildenbrand
> > ---
> > mm/memremap.c | 8
> > 1 file changed, 4 insertions(+), 4 deletion
rand
There's some pedantry below, but this looks fine generally, so
notwithstanding that,
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype.c | 14 ++
> include/linux/pgtable.h | 33 +
> 2 files changed, 47 insertions(+)
oing a function call, no need to care about this
> micro-optimization.
Ah my kind of patch :)
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> arch/x86/mm/pat/memtype.c | 33 +++--
> 1 file changed, 15 insertion
On Fri, Apr 25, 2025 at 10:17:15AM +0200, David Hildenbrand wrote:
> track_pfn() does not exist, let's simply refer to it as "pfnmap
> tracking".
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/io-mapping.c | 2 +-
>
On Fri, Feb 21, 2025 at 05:31:29PM +, Matthew Wilcox (Oracle) wrote:
> There is no need to print out page->index as part of the debug message.
>
> Signed-off-by: Matthew Wilcox (Oracle)
LGTM from my side,
Reviewed-by: Lorenzo Stoakes
> ---
> drivers/staging/fbtf
t;From f428a950a5a932c0e4404a89f2a34b0683728016 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes
Date: Sun, 9 Feb 2025 06:29:25 +
Subject: [PATCH] mm: fixup unused variable warnings
Unfortunately fb_defio being enabled by nommu devices seems enormously
ingrained in the kernel to the point that it's not feasible to a
remove.
This eliminates the use of folio_mkclean() entirely but otherwise should
have no functional change.
Signed-off-by: Lorenzo Stoakes
Tested-by: Kajtar Zsolt
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fb_defio.c | 43 ++---
include/linu
traverse mappings of userland-mapped kernel memory,
write-protecting those mappings to enable page_mkwrite() or pfn_mkwrite()
fault handlers to be retriggered on subsequent dirty.
Signed-off-by: Lorenzo Stoakes
---
mm/rmap.c | 79 +--
1 file
moved compound_nr() in fb_deferred_io_work() as per Matthew.
RFC v1:
https://lore.kernel.org/all/1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoa...@oracle.com/
Lorenzo Stoakes (3):
mm: refactor rmap_walk_file() to separate out traversal logic
mm: provide mapping_wrprotect_range
d, we can subsequently adjust the fb_defio implementation
to make use of this function and avoid incorrect invocation of
folio_mkclean() and more importantly, incorrect manipulation of
page->index and mapping fields.
Signed-off-by: Lorenzo Stoakes
---
include/linux/rmap.h | 3 ++
mm/rmap.c
traverse mappings of userland-mapped kernel memory,
write-protecting those mappings to enable page_mkwrite() or pfn_mkwrite()
fault handlers to be retriggered on subsequent dirty.
Signed-off-by: Lorenzo Stoakes
---
mm/rmap.c | 79 +--
1 file
d, we can subsequently adjust the fb_defio implementation
to make use of this function and avoid incorrect invocation of
folio_mkclean() and more importantly, incorrect manipulation of
page->index and mapping fields.
Signed-off-by: Lorenzo Stoakes
---
include/linux/rmap.h | 3 ++
mm/rmap.c
David.
* Removed folio lock when invoking mapping_wrprotect_page() in
fb_deferred_io_work() as per Matthew.
* Removed compound_nr() in fb_deferred_io_work() as per Matthew.
RFC v1:
https://lore.kernel.org/all/1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoa...@oracle.com/
Lor
remove.
This eliminates the use of folio_mkclean() entirely but otherwise should
have no functional change.
Signed-off-by: Lorenzo Stoakes
Tested-by: Kajtar Zsolt
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/core/Kconfig| 1 +
drivers/video/fbdev/core/fb_defio.
On Tue, Feb 04, 2025 at 09:21:55AM +0100, Thomas Zimmermann wrote:
> Hi
>
>
> Am 31.01.25 um 19:28 schrieb Lorenzo Stoakes:
> > With the introduction of mapping_wrprotect_page() there is no need to use
> > folio_mkclean() in order to write-protect mappings of frame buffer
On Mon, Feb 03, 2025 at 04:49:34PM +0100, Simona Vetter wrote:
> On Fri, Jan 31, 2025 at 06:28:57PM +0000, Lorenzo Stoakes wrote:
> > in the fb_defio video driver, page dirty state is used to determine when
> > frame buffer pages have been changed, allowing for batched, deferre
On Mon, Feb 03, 2025 at 11:24:50AM +0100, Thomas Zimmermann wrote:
> Hi
>
>
> Am 14.01.25 um 00:15 schrieb Lorenzo Stoakes:
> [...]
> >
> > *** REVIEWERS NOTES: ***
> >
> > I do not have any hardware that uses fb_defio, so I'm asking for help with
&g
On Mon, Jan 13, 2025 at 11:15:48PM +, Lorenzo Stoakes wrote:
> With the introduction of mapping_wrprotect_page() there is no need to use
> folio_mkclean() in order to write-protect mappings of frame buffer pages,
> and therefore no need to inappropriately set kernel-allocated pa
(This time sent in reply to the correct series...)
On Fri, Jan 31, 2025 at 06:28:58PM +, Lorenzo Stoakes wrote:
> With the introduction of mapping_wrprotect_page() there is no need to use
> folio_mkclean() in order to write-protect mappings of frame buffer pages,
> and therefore n
Andrew - Ugh sorry - please disregard the below, I sent it to the wrong
thread. It's Saturday and I'm tired and brain not working :>)
Let me resend this against the correct non-RFC thread!
On Sat, Feb 01, 2025 at 05:01:15PM +0000, Lorenzo Stoakes wrote:
> On Mon, Jan 13, 2025 at
.
* Removed folio lock when invoking mapping_wrprotect_page() in
fb_deferred_io_work() as per Matthew.
* Removed compound_nr() in fb_deferred_io_work() as per Matthew.
RFC v1:
https://lore.kernel.org/all/1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.stoa...@oracle.com/
*** B
remove.
This eliminates the use of folio_mkclean() entirely but otherwise should
have no functional change.
Signed-off-by: Lorenzo Stoakes
Tested-by: Kajtar Zsolt
---
drivers/video/fbdev/core/fb_defio.c | 38 +
include/linux/fb.h | 1 +
2 files chang
bequently adjust the fb_defio implementation
to make use of this function and avoid incorrect invocation of
folio_mkclean() and more importantly, incorrect manipulation of
page->index, mapping fields.
Signed-off-by: Lorenzo Stoakes
---
include/linux/rmap.h | 3 ++
mm/rmap.c
traverse mappings of userland-mapped kernel memory,
write-protecting those mappings to enable page_mkwrite() or pfn_mkwrite()
fault handlers to be retriggered on subsequent dirty.
Signed-off-by: Lorenzo Stoakes
---
mm/rmap.c | 79 +--
1 file
here - as struct page fields
that defio relies upon prior to this series are being removed
non-optionally.
Thanks, Lorenzo
On Mon, Jan 13, 2025 at 11:15:45PM +0000, Lorenzo Stoakes wrote:
> Right now the only means by which we can write-protect a range using the
> reverse mapping is via fo
I tried 3 separate machines...).
In effect I provide a whole new mechanism just so defio can do the right
thing and retain the exact same behaviour, so just need to confirm it does
what you need from our side.
Thanks, Lorenzo
On Mon, Jan 13, 2025 at 11:15:45PM +0000, Lorenzo Stoakes wrote:
>
bequently adjust the fb_defio implementation
to make use of this function and avoid incorrect invocation of
folio_mkclean() and more importantly, incorrect manipulation of
page->index, mapping fields.
Signed-off-by: Lorenzo Stoakes
---
include/linux/rmap.h | 3 ++
mm/rmap.c
remove.
This eliminates the use of folio_mkclean() entirely but otherwise should
have no functional change.
Signed-off-by: Lorenzo Stoakes
---
drivers/video/fbdev/core/fb_defio.c | 38 +
include/linux/fb.h | 1 +
2 files changed, 12 insertions(
traverse mappings of userland-mapped kernel memory,
write-protecting those mappings to enable page_mkwrite() or pfn_mkwrite()
fault handlers to be retriggered on subsequent dirty.
Signed-off-by: Lorenzo Stoakes
---
mm/rmap.c | 79 +--
1 file
page pointer as per David.
* Removed folio lock when invoking mapping_wrprotect_page() in
fb_deferred_io_work() as per Matthew.
* Removed compound_nr() in fb_deferred_io_work() as per Matthew.
RFC v1:
https://lore.kernel.org/all/1e452b5b65f15a9a5d0c2ed3f5f812fdd1367603.1736352361.git.lorenzo.st
On Wed, Jan 08, 2025 at 07:41:31PM +, Lorenzo Stoakes wrote:
> On Wed, Jan 08, 2025 at 05:32:54PM +, Matthew Wilcox wrote:
> > On Wed, Jan 08, 2025 at 04:18:42PM +, Lorenzo Stoakes wrote:
> > > @@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_s
1 - 100 of 157 matches
Mail list logo
