Re: [PATCH v2 10/16] mm: multigenerational lru: mm_struct list

On Tue, Apr 13, 2021 at 12:56:27AM -0600, Yu Zhao wrote: > In order to scan page tables, we add an infrastructure to maintain > either a system-wide mm_struct list or per-memcg mm_struct lists. > Multiple threads can concurrently work on the same mm_struct list, and > each of them w

[PATCH v2 10/16] mm: multigenerational lru: mm_struct list

In order to scan page tables, we add an infrastructure to maintain either a system-wide mm_struct list or per-memcg mm_struct lists. Multiple threads can concurrently work on the same mm_struct list, and each of them will be given a different mm_struct. This infrastructure also tracks whether

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Yu Zhao writes: > On Wed, Mar 24, 2021 at 12:58 AM Huang, Ying wrote: >> >> Yu Zhao writes: >> >> > On Mon, Mar 22, 2021 at 11:13:19AM +0800, Huang, Ying wrote: >> >> Yu Zhao writes: >> >> >> >> > On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: >> >> >> Yu Zhao writes: >> >> >>

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

On Wed, Mar 24, 2021 at 12:58 AM Huang, Ying wrote: > > Yu Zhao writes: > > > On Mon, Mar 22, 2021 at 11:13:19AM +0800, Huang, Ying wrote: > >> Yu Zhao writes: > >> > >> > On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: > >> >> Yu Zhao writes: > >> >> > >> >> > On Tue, Mar 16,

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Yu Zhao writes: > On Mon, Mar 22, 2021 at 11:13:19AM +0800, Huang, Ying wrote: >> Yu Zhao writes: >> >> > On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: >> >> Yu Zhao writes: >> >> >> >> > On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: >> >> > The scanning

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

On Mon, Mar 22, 2021 at 11:13:19AM +0800, Huang, Ying wrote: > Yu Zhao writes: > > > On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: > >> Yu Zhao writes: > >> > >> > On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: > >> > The scanning overhead is only one of the two

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Yu Zhao writes: > On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: >> Yu Zhao writes: >> >> > On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: >> > The scanning overhead is only one of the two major problems of the >> > current page reclaim. The other problem is the

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

On Wed, Mar 17, 2021 at 11:37:38AM +0800, Huang, Ying wrote: > Yu Zhao writes: > > > On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: > >> Yu Zhao writes: > >> > >> > On Tue, Mar 16, 2021 at 10:07:36AM +0800, Huang, Ying wrote: > >> >> Rik van Riel writes: > >> >> > >> >> > On

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Yu Zhao writes: > On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: >> Yu Zhao writes: >> >> > On Tue, Mar 16, 2021 at 10:07:36AM +0800, Huang, Ying wrote: >> >> Rik van Riel writes: >> >> >> >> > On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: >> >> > >> >> >> +/* >> >> >> + *

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

On Tue, Mar 16, 2021 at 02:44:31PM +0800, Huang, Ying wrote: > Yu Zhao writes: > > > On Tue, Mar 16, 2021 at 10:07:36AM +0800, Huang, Ying wrote: > >> Rik van Riel writes: > >> > >> > On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: > >> > > >> >> +/* > >> >> + * After pages are faulted in,

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Yu Zhao writes: > On Tue, Mar 16, 2021 at 10:07:36AM +0800, Huang, Ying wrote: >> Rik van Riel writes: >> >> > On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: >> > >> >> +/* >> >> + * After pages are faulted in, they become the youngest generation. >> >> They must >> >> + * go through aging

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

On Tue, Mar 16, 2021 at 10:07:36AM +0800, Huang, Ying wrote: > Rik van Riel writes: > > > On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: > > > >> +/* > >> + * After pages are faulted in, they become the youngest generation. > >> They must > >> + * go through aging process twice before they

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Rik van Riel writes: > On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: > >> +/* >> + * After pages are faulted in, they become the youngest generation. >> They must >> + * go through aging process twice before they can be evicted. After >> first scan, >> + * their accessed bit set during

Re: [PATCH v1 09/14] mm: multigenerational lru: mm_struct list

On Sat, 2021-03-13 at 00:57 -0700, Yu Zhao wrote: > +/* > + * After pages are faulted in, they become the youngest generation. > They must > + * go through aging process twice before they can be evicted. After > first scan, > + * their accessed bit set during initial faults are cleared and they >

[PATCH v1 09/14] mm: multigenerational lru: mm_struct list

Add an infrastructure that maintains either a system-wide mm_struct list or per-memcg mm_struct lists. Multiple threads can concurrently work on the same mm_struct list, and each of them will be given a different mm_struct. Those who finish early can optionally wait on the rest after the iterator

Re: [PATCH v2 14/19] mm: Add vdso_base in mm_struct

On Mon, Nov 23, 2020 at 4:29 PM Dmitry Safonov wrote: > > Instead of having every architecture to define vdso_base/vdso_addr etc, > provide a generic mechanism to track vdso_base for landing in userspace. > It'll minimize per-architecture difference, the number of callbacks to > provide. > >

[PATCH v2 14/19] mm: Add vdso_base in mm_struct

flags) +static int aio_ring_mremap(struct vm_area_struct *old_vma, + struct vm_area_struct *vma, unsigned long flags) { struct file *file = vma->vm_file; struct mm_struct *mm = vma->vm_mm; diff --git a/include/linux/mm.h b/include/linux/mm.h

Re: [PATCH 14/19] mm: Add user_landing in mm_struct

On 11/8/20 7:04 PM, Andy Lutomirski wrote: > On Sat, Nov 7, 2020 at 9:18 PM Dmitry Safonov wrote: >> >> Instead of having every architecture to define vdso_base/vdso_addr etc, >> provide a generic mechanism to track landing in userspace. >> It'll minimize per-architecture difference, the number

Re: [PATCH 14/19] mm: Add user_landing in mm_struct

On Sat, Nov 7, 2020 at 9:18 PM Dmitry Safonov wrote: > > Instead of having every architecture to define vdso_base/vdso_addr etc, > provide a generic mechanism to track landing in userspace. > It'll minimize per-architecture difference, the number of callbacks to > provide. > > Originally, it

[PATCH 14/19] mm: Add user_landing in mm_struct

) +static int aio_ring_mremap(struct vm_area_struct *old_vma, + struct vm_area_struct *vma, unsigned long flags) { struct file *file = vma->vm_file; struct mm_struct *mm = vma->vm_mm; diff --git a/include/linux/mm.h b/include/linux/mm.h index 427911

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

+0200, Jann Horn wrote: Currently, mm_struct has two refcounts: ... Either way can work, I liked the suggestion because it suggests an good name for the ref: 'mmget_pgd' or somesuch What I don't like is how nonsensical the names here are becoming: mmget/mmgrab/mm_ref Gives no impression

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

09:12AM +0200, Jann Horn wrote: > > > > > Currently, mm_struct has two refcounts: > > > > > > > > > > - mm_users: preserves everything - the mm_struct, the page tables, > > > > > the > > > > >memory mappings, and so on

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

On Tue, Nov 3, 2020 at 3:11 AM Jann Horn wrote: > On Sat, Oct 17, 2020 at 2:30 AM Jann Horn wrote: > > On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe wrote: > > > On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote: > > > > Currentl

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

On Sat, Oct 17, 2020 at 2:30 AM Jann Horn wrote: > On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe wrote: > > On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote: > > > Currently, mm_struct has two refcounts: > > > > > > - mm_users: preserves everyth

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe wrote: > On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote: > > Currently, mm_struct has two refcounts: > > > > - mm_users: preserves everything - the mm_struct, the page tables, the > >memory mappings

Re: [RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote: > Currently, mm_struct has two refcounts: > > - mm_users: preserves everything - the mm_struct, the page tables, the >memory mappings, and so on > - mm_count: preserves the mm_struct and pgd > > However,

[RFC PATCH resend 3/6] mm: Add refcount for preserving mm_struct without pgd

Currently, mm_struct has two refcounts: - mm_users: preserves everything - the mm_struct, the page tables, the memory mappings, and so on - mm_count: preserves the mm_struct and pgd However, there are three types of users of mm_struct: 1. users that want page tables, memory mappings and so

[RFC PATCH 3/6] mm: Add refcount for preserving mm_struct without pgd

Currently, mm_struct has two refcounts: - mm_users: preserves everything - the mm_struct, the page tables, the memory mappings, and so on - mm_count: preserves the mm_struct and pgd However, there are three types of users of mm_struct: 1. users that want page tables, memory mappings and so

[tip: x86/pasid] mm: Add a pasid member to struct mm_struct

: Borislav Petkov CommitterDate: Thu, 17 Sep 2020 20:22:15 +02:00 mm: Add a pasid member to struct mm_struct A PASID is shared by all threads in a process. So the logical place to keep track of it is in the mm_struct. Both ARM and x86 would use this PASID. [ bp: Massage commit message

Re: [PATCH 0/7] Record the mm_struct in the page table pages

gt; Pages which are in use as page tables have some space unused in struct > > > page. It would be handy to have a pointer to the struct mm_struct that > > > they belong to so that we can handle uncorrectable errors in page tables > > > more gracefully. There are a few o

Re: [PATCH 4/7] arm64: Thread mm_struct throughout page table allocation

Hi Matthew, On Tue, Apr 28, 2020 at 12:44:46PM -0700, Matthew Wilcox wrote: > From: "Matthew Wilcox (Oracle)" > > An upcoming patch will pass mm_struct to the page table constructor. > Make sure arm64 has the appropriate mm_struct at the point it needs to > call the con

Re: [PATCH 5/7] m68k: Thread mm_struct throughout page table allocation

On Tue, Apr 28, 2020 at 9:45 PM Matthew Wilcox wrote: > From: "Matthew Wilcox (Oracle)" > > An upcoming patch will pass mm_struct to the page table constructor. > Make sure m68k has the appropriate mm_struct at the point it needs to > call the constructor. > >

Re: [PATCH 0/7] Record the mm_struct in the page table pages

It would be handy to have a pointer to the struct mm_struct that > > they belong to so that we can handle uncorrectable errors in page tables > > more gracefully. There are a few other things we could use it for too, > > such as checking that the page table entry actually be

Re: [PATCH 0/7] Record the mm_struct in the page table pages

On Tue, Apr 28, 2020 at 12:44:42PM -0700, Matthew Wilcox wrote: > From: "Matthew Wilcox (Oracle)" > > Pages which are in use as page tables have some space unused in struct > page. It would be handy to have a pointer to the struct mm_struct that > they belong

[PATCH 3/7] arm: Thread mm_struct throughout page table allocation

From: "Matthew Wilcox (Oracle)" An upcoming patch will pass mm_struct to the page table constructor. Make sure ARM has the appropriate mm_struct at the point it needs to call the constructor. Signed-off-by: Matthew Wilcox (Oracle) --- arch/arm/mm/

[PATCH 4/7] arm64: Thread mm_struct throughout page table allocation

From: "Matthew Wilcox (Oracle)" An upcoming patch will pass mm_struct to the page table constructor. Make sure arm64 has the appropriate mm_struct at the point it needs to call the constructor. Signed-off-by: Matthew Wilcox (Oracle) --- arch/arm64/mm/

[PATCH 5/7] m68k: Thread mm_struct throughout page table allocation

From: "Matthew Wilcox (Oracle)" An upcoming patch will pass mm_struct to the page table constructor. Make sure m68k has the appropriate mm_struct at the point it needs to call the constructor. Signed-off-by: Matthew Wilcox (Oracle) --- arch/m68k/include/asm/motorola_pgal

[PATCH 0/7] Record the mm_struct in the page table pages

From: "Matthew Wilcox (Oracle)" Pages which are in use as page tables have some space unused in struct page. It would be handy to have a pointer to the struct mm_struct that they belong to so that we can handle uncorrectable errors in page tables more gracefully. There are a few ot

[PATCH v12 18/22] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v12 17/22] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v12 16/22] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v11 17/22] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v11 18/22] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v11 16/22] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v10 18/22] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v10 16/22] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v10 17/22] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v9 17/21] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v9 16/21] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v9 18/21] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH RESEND 8/8] mm: Remove mmap_legacy_base and mmap_compat_legacy_code fields from mm_struct

/mm_types.h index 1d1093474c1a..9a5935f9cc7e 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -364,11 +364,9 @@ struct mm_struct { unsigned long pgoff, unsigned long flags); #endif unsigned long mmap_base;/* base of mmap area

[RFC PATCH v2] binfmt_elf: Protect mm_struct access with mmap_sem

find_extend_vma assumes the caller holds mmap_sem as a reader (explained in expand_downwards()). The path when we are extending the stack VMA to accommodate argv[] pointers happens without the lock. I was not able to cause an mm_struct corruption but an inserted BUG_ON(!rwsem_is_locked(>mmap_

Re: [RFC PATCH] binfmt_elf: Protect mm_struct access with mmap_sem

On Wed, Jun 12, 2019 at 10:51:59AM -0700, Matthew Wilcox wrote: > On Wed, Jun 12, 2019 at 07:29:15PM +0200, Michal Koutný wrote: > > On Wed, Jun 12, 2019 at 10:00:34AM -0700, Matthew Wilcox > > wrote: > > > On Wed, Jun 12, 2019 at 04:28:11PM +0200, Michal Koutný wrote: > > > > - /* N.B.

Re: [RFC PATCH] binfmt_elf: Protect mm_struct access with mmap_sem

t able to cause an mm_struct corruption but > BUG_ON(!rwsem_is_locked(>mmap_sem)) in find_extend_vma could be > triggered as > > # xargs: echo: terminated by signal 11 > > (bigfile needs to have more than RLIMIT_STACK / sizeof(char *) rows) > > Other access

Re: [RFC PATCH] binfmt_elf: Protect mm_struct access with mmap_sem

On Wed, Jun 12, 2019 at 07:29:15PM +0200, Michal Koutný wrote: > On Wed, Jun 12, 2019 at 10:00:34AM -0700, Matthew Wilcox > wrote: > > On Wed, Jun 12, 2019 at 04:28:11PM +0200, Michal Koutný wrote: > > > - /* N.B. passed_fileno might not be initialized? */ > > > + > > > > Why did you delete

Re: [RFC PATCH] binfmt_elf: Protect mm_struct access with mmap_sem

On Wed, Jun 12, 2019 at 10:00:34AM -0700, Matthew Wilcox wrote: > On Wed, Jun 12, 2019 at 04:28:11PM +0200, Michal Koutný wrote: > > - /* N.B. passed_fileno might not be initialized? */ > > + > > Why did you delete this comment? The variable got removed in d20894a23708 ("Remove a.out

Re: [RFC PATCH] binfmt_elf: Protect mm_struct access with mmap_sem

On Wed, Jun 12, 2019 at 04:28:11PM +0200, Michal Koutný wrote: > - /* N.B. passed_fileno might not be initialized? */ > + Why did you delete this comment?

[RFC PATCH] binfmt_elf: Protect mm_struct access with mmap_sem

find_extend_vma assumes the caller holds mmap_sem as a reader (explained in expand_downwards()). The path when we are extending the stack VMA to accomodate argv[] pointers happens without the lock. I was not able to cause an mm_struct corruption but BUG_ON(!rwsem_is_locked(>mmap_

Re: [PATCH] mm: fix protection of mm_struct fields in get_cmdline()

Hi, Konstantin, On 15.05.2019 11:15, Konstantin Khlebnikov wrote: > Since commit 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start| > end and env_start|end in mm_struct") related mm fields are protected with > separate spinlock and mmap_sem held for read is not en

Re: [PATCH] mm: fix protection of mm_struct fields in get_cmdline()

On 15.05.2019 11:22, Oscar Salvador wrote: On Wed, May 15, 2019 at 11:15:37AM +0300, Konstantin Khlebnikov wrote: Since commit 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start| end and env_start|end in mm_struct") related mm fields are protected with separate spinlock an

Re: [PATCH] mm: fix protection of mm_struct fields in get_cmdline()

On Wed, May 15, 2019 at 11:15:37AM +0300, Konstantin Khlebnikov wrote: > Since commit 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start| > end and env_start|end in mm_struct") related mm fields are protected with > separate spinlock and mmap_sem held for read is not en

[PATCH] mm: fix protection of mm_struct fields in get_cmdline()

Since commit 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start| end and env_start|end in mm_struct") related mm fields are protected with separate spinlock and mmap_sem held for read is not enough for protection. Fixes: 88aa7cc688d4 ("mm: introduce arg_lock to protec

[PATCH v8 17/20] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v8 19/20] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v8 18/20] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v7 19/20] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v7 18/20] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v7 17/20] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v6 16/19] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v6 18/19] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v6 17/19] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v5 17/19] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v5 18/19] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v5 16/19] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v4 18/19] x86: mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v4 16/19] x86: mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v4 17/19] x86: mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v3 32/34] x86/mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH v3 33/34] x86/mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v3 31/34] x86/mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v2 12/13] x86/mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

[PATCH v2 10/13] x86/mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH v2 11/13] x86/mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH 10/13] x86/mm+efi: Convert ptdump_walk_pgd_level() to take a mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level() need to pass an mm_struct rather than the raw pgd_t pointer. Luckily since commit 7e904a91bf60 ("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct for EFI on x86.

[PATCH 11/13] x86/mm: Convert ptdump_walk_pgd_level_debugfs() to take an mm_struct

To enable x86 to use the generic walk_page_range() function, the callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct. This means that ptdump_walk_pgd_level_core() is now always passed a valid pgd, so drop the support for pgd==NULL. Signed-off-by: Steven Price --- arch/x86

[PATCH 12/13] x86/mm: Convert ptdump_walk_pgd_level_core() to take an mm_struct

An mm_struct is needed to enable x86 to use of the generic walk_page_range() function. In the case of walking the user page tables (when CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a fake_mm structure because there isn't an mm_struct with a pointer to the pgd of the user

Re: [RFC][PATCH v2 14/21] kvm: register in mm_struct

On 02/02/19 07:57, Peter Xu wrote: > > I'm thinking whether it's legal for multiple VMs to run on a single mm > address space. I don't see a limitation so far but it's very possible > I am just missing something there (if there is, IMHO they might be > something nice to put into the commit

Re: [RFC][PATCH v2 14/21] kvm: register in mm_struct

x/mm_types.h 2018-12-23 19:58:06.993417137 +0800 @@ -27,6 +27,7 @@ typedef int vm_fault_t; struct address_space; struct mem_cgroup; struct hmm; +struct kvm; /* * Each physical page in the system has a struct page associated with @@ -496,6 +497,10 @@ struct mm_struct { /* HMM ne

Re: [RFC][PATCH v2 14/21] kvm: register in mm_struct

mm_types.h2018-12-23 19:58:06.993417137 +0800 > @@ -27,6 +27,7 @@ typedef int vm_fault_t; > struct address_space; > struct mem_cgroup; > struct hmm; > +struct kvm; > > /* > * Each physical page in the system has a struct page associated with > @@ -496,6

[RFC][PATCH v2 14/21] kvm: register in mm_struct

t_t; struct address_space; struct mem_cgroup; struct hmm; +struct kvm; /* * Each physical page in the system has a struct page associated with @@ -496,6 +497,10 @@ struct mm_struct { /* HMM needs to track a few things per mm */ struct hmm *hmm; #en

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

0x20/0x40 >>>    [] proc_pid_cmdline_read+0xd9/0x4e0 >>>    [] ? do_filp_open+0xa5/0x100 >>>    [] __vfs_read+0x37/0x150 >>>    [] ? security_file_permission+0x9b/0xc0 >>>    [] vfs_read+0x96/0x130 >>>    [] SyS_read+0x55/0xc0 >>>    [] en

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

0x20/0x40 >>>    [] proc_pid_cmdline_read+0xd9/0x4e0 >>>    [] ? do_filp_open+0xa5/0x100 >>>    [] __vfs_read+0x37/0x150 >>>    [] ? security_file_permission+0x9b/0xc0 >>>    [] vfs_read+0x96/0x130 >>>    [] SyS_read+0x55/0xc0 >>>    [] en

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

mmap_sem. So, introduce a new spinlock in mm_struct to protect the concurrent access to arg_start|end, env_start|end and others, as well as replace write map_sem to read to protect the race condition between prctl and sys_brk which might break check_data_rlimit(), and makes prctl more friendl

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

mmap_sem. So, introduce a new spinlock in mm_struct to protect the concurrent access to arg_start|end, env_start|end and others, as well as replace write map_sem to read to protect the race condition between prctl and sys_brk which might break check_data_rlimit(), and makes prctl more friendl

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On 4/18/18 2:40 AM, Cyrill Gorcunov wrote: On Wed, Apr 18, 2018 at 11:03:14AM +0200, Michal Hocko wrote: What about something like the following? " arg_lock protects concurent updates but we still need mmap_sem for read to exclude races with do_brk. " Acked-by: Michal Hocko

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On 4/18/18 2:40 AM, Cyrill Gorcunov wrote: On Wed, Apr 18, 2018 at 11:03:14AM +0200, Michal Hocko wrote: What about something like the following? " arg_lock protects concurent updates but we still need mmap_sem for read to exclude races with do_brk. " Acked-by: Michal Hocko Yes, thanks!

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

xey Dobriyan and Michal Hocko suggested to use dedicated lock > for them to mitigate the abuse of mmap_sem. > > So, introduce a new spinlock in mm_struct to protect the concurrent > access to arg_start|end, env_start|end and others, as well as replace > write map_sem to read to prot

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

xey Dobriyan and Michal Hocko suggested to use dedicated lock > for them to mitigate the abuse of mmap_sem. > > So, introduce a new spinlock in mm_struct to protect the concurrent > access to arg_start|end, env_start|end and others, as well as replace > write map_sem to read to prot

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Wed, Apr 18, 2018 at 11:03:14AM +0200, Michal Hocko wrote: > > > > > > What about something like the following? > > > " > > > arg_lock protects concurent updates but we still need mmap_sem for read > > > to exclude races with do_brk. > > > " > > > Acked-by: Michal Hocko > >

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Wed, Apr 18, 2018 at 11:03:14AM +0200, Michal Hocko wrote: > > > > > > What about something like the following? > > > " > > > arg_lock protects concurent updates but we still need mmap_sem for read > > > to exclude races with do_brk. > > > " > > > Acked-by: Michal Hocko > > > > Yes, thanks!

  1   2   3   4   5   6   >