On Wed, Aug 9, 2023 at 2:07 PM Mateusz Guzik wrote:
>
> On 8/5/23, Suren Baghdasaryan wrote:
> > On Fri, Aug 4, 2023 at 6:06 PM Mateusz Guzik wrote:
> >>
> >> On 8/5/23, Linus Torvalds wrote:
> >> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrot
On Fri, Aug 4, 2023 at 6:17 PM Mateusz Guzik wrote:
>
> On 8/5/23, Suren Baghdasaryan wrote:
> > On Fri, Aug 4, 2023 at 5:49 PM Mateusz Guzik wrote:
> >> However, the other users (that I know of ) go through the mmap
> >> semaphore to mess with anyth
On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
wrote:
>
> On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> >
> > I know of these guys, I think they are excluded as is -- they go
> > through access_remote_vm, starting with:
> > if (mmap_read_lock_killable(mm))
> > return
On Fri, Aug 4, 2023 at 5:26 PM Suren Baghdasaryan wrote:
>
> On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
> wrote:
> >
> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> > >
> > > I know of these guys, I think they are excluded as is -- they go
&
On Fri, Aug 4, 2023 at 5:49 PM Mateusz Guzik wrote:
>
> On 8/5/23, Suren Baghdasaryan wrote:
> > On Fri, Aug 4, 2023 at 5:26 PM Suren Baghdasaryan
> > wrote:
> >>
> >> On Fri, Aug 4, 2023 at 5:15 PM Linus Torvalds
> >> wrote:
> >> >
On Fri, Aug 4, 2023 at 6:06 PM Mateusz Guzik wrote:
>
> On 8/5/23, Linus Torvalds wrote:
> > On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
> >>
> >> I know of these guys, I think they are excluded as is -- they go
> >> through access_remote_vm, starting with:
> >> if
On Thu, Jun 29, 2023 at 7:40 AM Jiri Slaby wrote:
>
> Hi,
>
> On 27. 02. 23, 18:36, Suren Baghdasaryan wrote:
> > Attempt VMA lock-based page fault handling first, and fall back to the
> > existing mmap_lock-based handling if that fails.
> >
> &g
On Fri, Jun 30, 2023 at 1:43 AM Jiri Slaby wrote:
>
> On 30. 06. 23, 10:28, Jiri Slaby wrote:
> > > 2348
> > clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> > child_tid=0x7fcaa5882990,
://lore.kernel.org/all/20231006195318.4087158-6-wi...@infradead.org/
Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
Cc: Matthew Wilcox
Signed-off-by: Suren Baghdasaryan
---
arch/arm64/mm/fault.c | 2 ++
arch/powerpc/mm/fault.c | 2 ++
arch/riscv/mm/fault.c | 2 ++
ar
On Thu, Jan 25, 2024 at 6:04 PM Andrew Morton wrote:
>
> On Mon, 22 Jan 2024 22:43:05 -0800 Suren Baghdasaryan
> wrote:
>
> > The change [1] missed ARM architecture when fixing major fault accounting
> > for page fault retry under per-VMA lock. Add missing code to fix AR
On Sun, Jan 21, 2024 at 11:38 PM Suren Baghdasaryan wrote:
>
> On Sat, Jan 20, 2024 at 1:15 PM Russell King (Oracle)
> wrote:
> >
> > On Sat, Jan 20, 2024 at 09:09:47PM +,
> > patchwork-bot+linux-ri...@kernel.org wrote:
> > > Hello:
> > >
&g
a1992 ("mm: handle read faults under the VMA lock")
Reported-by: Russell King (Oracle)
Signed-off-by: Suren Baghdasaryan
---
arch/arm/mm/fault.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index e96fb40b9cc3..07565b593ed6 100644
--- a
On Sat, Jan 20, 2024 at 1:15 PM Russell King (Oracle)
wrote:
>
> On Sat, Jan 20, 2024 at 09:09:47PM +,
> patchwork-bot+linux-ri...@kernel.org wrote:
> > Hello:
> >
> > This patch was applied to riscv/linux.git (fixes)
> > by Andrew Morton :
> >
> > On Tue, 26 Dec 2023 13:46:10 -0800 you
On Wed, Apr 3, 2024 at 12:58 AM Kefeng Wang wrote:
>
>
>
> On 2024/4/3 13:59, Suren Baghdasaryan wrote:
> > On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang
> > wrote:
> >>
> >> The vm_flags of vma already checked under per-VMA lock, if it is a
> &g
safe to me.
Using (mm != NULL) to indicate that we are holding mmap_lock is not
ideal but I guess that works.
Reviewed-by: Suren Baghdasaryan
> ---
> arch/x86/mm/fault.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang wrote:
>
> The __do_page_fault() only check vma->flags and call handle_mm_fault(),
> and only called by do_page_fault(), let's squash it into do_page_fault()
> to cleanup code.
>
> Signed-off-by: Kefeng Wang
Reviewed-b
34% in lmbench 'lat_sig -P 1 prot lat_sig'.
The change makes sense to me. Per-VMA lock is enough to keep
vma->vm_flags stable, so no need to retry with mmap_lock.
>
> Signed-off-by: Kefeng Wang
Reviewed-by: Suren Baghdasaryan
> ---
> arch/arm64/mm/fault.c | 4 +++-
> 1
ff-by: Kefeng Wang
Reviewed-by: Suren Baghdasaryan
> ---
> arch/arm/mm/fault.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 439dc6a26bb9..5c4b417e24f9 100644
> --- a/arch/arm/mm/fault.c
> ++
On Tue, Apr 2, 2024 at 10:19 PM Suren Baghdasaryan wrote:
>
> On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang
> wrote:
> >
> > The vm_flags of vma already checked under per-VMA lock, if it is a
> > bad access, directly set fault to VM_FAULT_BADACCESS an
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly handle error and return, there is no need to
> lock_mm_and_find_vma() and check vm_flags again.
>
> Signed-off-by: Kefeng Wang
Code-wise looks correct
On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang wrote:
>
> The vm_flags of vma already checked under per-VMA lock, if it is a
> bad access, directly handle error and return, there is no need to
> lock_mm_and_find_vma() and check vm_flags again.
>
> Signed-off-by: Kefeng Wang
301 - 321 of 321 matches
Mail list logo
