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
On Wed, Jan 08, 2025 at 10:12:36PM +0100, David Hildenbrand wrote:
> On 08.01.25 21:54, Matthew Wilcox wrote:
> > On Wed, Jan 08, 2025 at 09:14:53PM +0100, David Hildenbrand wrote:
> > > On 08.01.25 18:32, Matthew Wilcox wrote:
> > > > On Wed, Jan 08, 2025 at 04:
On Wed, Jan 08, 2025 at 11:02:57PM +0100, David Hildenbrand wrote:
> On 08.01.25 22:55, Matthew Wilcox wrote:
> > On Wed, Jan 08, 2025 at 10:12:36PM +0100, David Hildenbrand wrote:
> > > On 08.01.25 21:54, Matthew Wilcox wrote:
> > > > Not necessarily! We already do that (since 2022) for DAX (see
On Wed, Jan 08, 2025 at 05:32:54PM +, Matthew Wilcox wrote:
> On Wed, Jan 08, 2025 at 04:18:42PM +0000, Lorenzo Stoakes wrote:
> > @@ -280,7 +269,10 @@ static void fb_deferred_io_work(struct work_struct
> > *work)
> > struct folio *folio = pag
On Wed, Jan 08, 2025 at 05:25:01PM +, Matthew Wilcox wrote:
> On Wed, Jan 08, 2025 at 04:18:41PM +0000, Lorenzo Stoakes wrote:
> > +++ b/include/linux/rmap.h
> > @@ -754,6 +754,26 @@ unsigned long page_address_in_vma(const struct folio
> > *folio,
> > */
> >
On Wed, Jan 08, 2025 at 04:38:57PM +, Matthew Wilcox wrote:
> On Wed, Jan 08, 2025 at 04:18:40PM +0000, Lorenzo Stoakes wrote:
> > +/*
> > + * rmap_walk_file - do something to file page using the object-based rmap
> > method
> > + * @folio: the folio to be ha
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 | 34 ++---
include/linux/fb.h | 1 +
2 files changed, 12 insertions(
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 | 20
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 | 81 +--
1 file
/scm/linux/kernel/git/akpm/mm.git/
Lorenzo Stoakes (3):
mm: refactor rmap_walk_file() to separate out traversal logic
mm: provide rmap_wrprotect_file_page() function
fb_defio: do not use deprecated page->mapping, index fields
drivers/video/fbdev/core/fb_defio.c | 34 +++
include/linu
r some functions
> maple_tree: separate ma_state node from status
> maple_tree: remove mas_searchable()
> maple_tree: use maple state end for write operations
> maple_tree: don't find node end in mtree_lookup_walk()
> maple_tree: mtree_range_walk() clean up
>
> Lorenzo Stoake
On Thu, Oct 24, 2024 at 09:22:25PM +0800, Yu Kuai wrote:
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 5328e08723d7..c57b6fc4db2e 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -2239,6 +2239,8 @@ static inline void mas_node_or_none(struct ma_state
> *mas,
>
> /*
> *
)
Signed-off-by: Lorenzo Stoakes
---
arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/misc/sgi-gru/grufault.c | 2 +-
include/linux/mm.h | 3 +--
mm/gup.c| 9 +++--
mm/gup_test.c | 5
vmas parameter
altogether.
Suggested-by: Matthew Wilcox (Oracle)
Acked-by: Greg Kroah-Hartman
Acked-by: David Hildenbrand
Reviewed-by: Jason Gunthorpe
Acked-by: Christian König (for radeon parts)
Acked-by: Jarkko Sakkinen
Signed-off-by: Lorenzo Stoakes
---
arch/x86/kernel/cpu/sgx/ioctl.c
On Fri, May 05, 2023 at 10:47:58AM +0800, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 145e5cddfe8b4bf607510b2dcf630d95f4db420f Add linux-next
> specific files for 20230504
>
> Error/Warning reports:
>
> https
vmas parameter
altogether.
Suggested-by: Matthew Wilcox (Oracle)
Acked-by: Greg Kroah-Hartman
Acked-by: David Hildenbrand
Reviewed-by: Jason Gunthorpe
Signed-off-by: Lorenzo Stoakes
---
arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/misc/sgi-gru
vmas parameter
altogether.
Signed-off-by: Lorenzo Stoakes
Suggested-by: Matthew Wilcox (Oracle)
---
arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/misc/sgi-gru/grufault.c | 2 +-
include/linux/mm.h | 3 +--
mm/gup.c
vmas parameter
altogether.
Signed-off-by: Lorenzo Stoakes
Suggested-by: Matthew Wilcox (Oracle)
Acked-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/misc/sgi-gru/grufault.c | 2 +-
include/linux/mm.h
vmas parameter
altogether.
Signed-off-by: Lorenzo Stoakes
Suggested-by: Matthew Wilcox (Oracle)
Acked-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/misc/sgi-gru/grufault.c | 2 +-
include/linux/mm.h
On Mon, Mar 13, 2023 at 08:47:21AM +0100, Christian König wrote:
> Am 13.03.23 um 00:40 schrieb Lorenzo Stoakes:
> > This function no longer exists, however the prot != vma->vm_page_prot case
> > discussion has been retained and moved to vmf_insert_pfn_prot() so refer t
escription of the prot != vma->vm_page_prot case, moving it to
vmf_insert_pfn_prot() instead.
Signed-off-by: Lorenzo Stoakes
---
include/linux/mm.h | 2 --
include/linux/mm_types.h | 7 +
mm/memory.c | 57 +---
3 files changed, 19 inse
This functionality's sole user, the drm ttm module, removed support for it
in commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()") as the
whole approach is currently unworkable without a PMD/PUD special bit and
updates to GUP.
Signed-off-by: Lorenzo Stoakes
---
.
Lorenzo Stoakes (3):
mm: remove unused vmf_insert_mixed_prot()
mm: Remove vmf_insert_pfn_xxx_prot() for huge page-table entries
drm/ttm: Remove comment referencing now-removed
vmf_insert_mixed_prot()
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
include/linux/huge_mm.h | 39
This function no longer exists, however the prot != vma->vm_page_prot case
discussion has been retained and moved to vmf_insert_pfn_prot() so refer to
this instead.
Signed-off-by: Lorenzo Stoakes
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
patches were simply a
mechanical/cautious replacement for code that is more or less exactly
equivalent but if this would make sense perhaps it'd be worth using
gup_fast() where possible?
--
Lorenzo Stoakes
https://ljs.io
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
Signed-off-by: Lorenzo Stoakes
---
drivers/gpu/drm/via/via_dmablit.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff
On 6 January 2017 at 07:09, Lorenzo Stoakes wrote:
>
> Adding Andrew, as this may be another less active corner of the corner,
> thanks!
Hi all,
Thought I'd also give this one a gentle nudge now the merge window has
re-opened, Andrew - are you ok to pick this up? I've check
On 3 January 2017 at 20:23, Lorenzo Stoakes wrote:
> Hi All,
>
> Just a gentle ping on this one :)
>
> Cheers, Lorenzo
>
> On 1 November 2016 at 19:43, Lorenzo Stoakes wrote:
>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
>> and
Hi All,
Just a gentle ping on this one :)
Cheers, Lorenzo
On 1 November 2016 at 19:43, Lorenzo Stoakes wrote:
> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>
> Signed-off
On Mon, Nov 07, 2016 at 11:49:18AM +0100, Jesper Nilsson wrote:
> For the cris-part:
> Acked-by: Jesper Nilsson
Thanks very much for that, however just to avoid any confusion, I realised this
series was not not the right way forward after discussion with Paolo and rather
it makes more sense to ke
Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
Signed-off-by: Lorenzo Stoakes
---
drivers/gpu/drm/via/via_dmablit.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff
On Mon, Oct 31, 2016 at 06:55:33PM +0100, Paolo Bonzini wrote:
> > 2. There is currently only one caller of get_user_pages_locked() in
> >mm/frame_vector.c which seems to suggest this function isn't widely
> >used/known.
>
> Or not widely necessary. :)
Well, quite :)
>
> > 3. This change r
On Mon, Oct 31, 2016 at 12:45:36PM +0100, Paolo Bonzini wrote:
>
>
> On 31/10/2016 11:02, Lorenzo Stoakes wrote:
> > - *
> > - * get_user_pages should be phased out in favor of
> > - * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
> > - * sho
get_user_pages() now has an int *locked parameter which renders
get_user_pages_locked() redundant, so remove it.
This patch should not introduce any functional changes.
Signed-off-by: Lorenzo Stoakes
---
include/linux/mm.h | 2 --
mm/frame_vector.c | 4 ++--
mm/gup.c | 56
behaviour
when faulting in pages.
It should not introduce any functional changes, however it does allow for
subsequent changes to get_user_pages() callers to take advantage of
VM_FAULT_RETRY.
Signed-off-by: Lorenzo Stoakes
---
arch/cris/arch-v32/drivers/cryptocop.c| 2
.
Lorenzo Stoakes (2):
mm: add locked parameter to get_user_pages()
mm: remove get_user_pages_locked()
arch/cris/arch-v32/drivers/cryptocop.c | 2 +
arch/ia64/kernel/err_inject.c | 2 +-
arch/x86/mm/mpx.c | 2 +-
drivers/gpu
, this flag was originally silently dropped by 1e9877902dc7e
("mm/gup: Introduce get_user_pages_remote()"), so this appears to have been
unintentional and reintroducing it is therefore not an issue.
Signed-off-by: Lorenzo Stoakes
---
v2: updated patch to apply against mainline rather t
VM_FAULT_RETRY
behaviour when faulting in pages.
It should not introduce any functional changes, however it does allow for
subsequent changes to get_user_pages_remote() callers to take advantage of
VM_FAULT_RETRY.
Signed-off-by: Lorenzo Stoakes
---
v2: updated description
drivers/gpu/drm/etnaviv
eplacement - get_user_pages_unlocked() if the current
task and memory descriptor are referenced, or get_user_pages_remote() if other
task/memory descriptors are referenced (having acquiring mmap_sem.)
Lorenzo Stoakes (2):
mm: add locked parameter to get_user_pages_remote()
mm: unexport __get_user_page
On Thu, Oct 27, 2016 at 10:51:39AM +0100, Lorenzo Stoakes wrote:
> This patch series continues the cleanup of get_user_pages*() functions taking
> advantage of the fact we can now pass gup_flags as we please.
Note that this patch series has an unfortunate trivial dependency on my recent
&
, this flag was originally silently dropped by 1e9877902dc7e
("mm/gup: Introduce get_user_pages_remote()"), so this appears to have been
unintentional and reintroducing it is therefore not an issue.
Signed-off-by: Lorenzo Stoakes
---
include/linux/mm.h | 3 ---
mm/gup.c
__get_user_pages_unlocked() need only be exported for his ability to allow
VM_FAULT_RETRY behaviour, this adjustment allows us to subsequently unexport
__get_user_pages_unlocked() as well as allowing for future flexibility in the
use of get_user_pages_remote().
Signed-off-by: Lorenzo Stoakes
eplacement - get_user_pages_unlocked() if the current
task and memory descriptor are referenced, or get_user_pages_remote() if other
task/memory descriptors are referenced (having acquiring mmap_sem.)
Lorenzo Stoakes (2):
mm: add locked parameter to get_user_pages_remote()
mm: unexport __get_user_page
On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> yes this is the desirable and expected behavior.
>
> > wonder if this is desirable behaviour or whether this ought to be limited to
> > ptrace system calls. Regardless, by making the flag more visible it makes it
> > easier to see that
On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> I am wondering whether we can go further. E.g. it is not really clear to
> me whether we need an explicit FOLL_REMOTE when we can in fact check
> mm != current->mm and imply that. Maybe there are some contexts which
> wouldn't work, I
On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > This patch removes the write parameter from __access_remote_vm() and
> > > replaces it
> > >
On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned
> > long nr_pages,
> > int write, int force, struct page **pages,
> > struct vm_area_struct **vmas);
> > long get_u
behaviour
(and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
arch/alpha/kernel/ptrace.c | 9 ++---
arch/blackfin/kernel/ptrace.c | 5 +++--
arch/cris/arch-v32/kernel/ptrace.c | 4 ++--
arch/ia64/kernel/ptrace.c | 14 +-
arch/m32r
behaviour
(and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
fs/proc/base.c | 19 +--
include/linux/mm.h | 2 +-
mm/memory.c| 11 +++
mm/nommu.c | 7 +++
4 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/fs/proc
behaviour
(and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
mm/memory.c | 23 +++
mm/nommu.c | 9 ++---
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 20a9adb..79ebed3 100644
--- a/mm/memory.c
+++ b
This patch removes the write and force parameters from get_user_pages_remote()
and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo
This patch removes the write and force parameters from get_user_pages() and
replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit
in callers as use of this flag can result in surprising behaviour (and hence
bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
This patch removes the write and force parameters from get_vaddr_frames() and
replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit
in callers as use of this flag can result in surprising behaviour (and hence
bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
This patch removes the write and force parameters from get_user_pages_locked()
and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo
1 - 100 of 104 matches
Mail list logo
