On Sat, Jul 8, 2023 at 4:10 PM Suren Baghdasaryan wrote:
>
> On Sat, Jul 8, 2023 at 4:04 PM Hugh Dickins wrote:
> >
> > Lockdep is certainly right to complain about
> > (&vma->vm_lock->lock){}-{3:3}, at: vma_start_write+0x2d/0x3f
> >but task is already holding lock:
> > (&mapp
On Sat, Jul 8, 2023 at 4:04 PM Hugh Dickins wrote:
>
> Lockdep is certainly right to complain about
> (&vma->vm_lock->lock){}-{3:3}, at: vma_start_write+0x2d/0x3f
>but task is already holding lock:
> (&mapping->i_mmap_rwsem){+.+.}-{3:3}, at: mmap_region+0x4dc/0x6db
> Invert tho
Lockdep is certainly right to complain about
(&vma->vm_lock->lock){}-{3:3}, at: vma_start_write+0x2d/0x3f
but task is already holding lock:
(&mapping->i_mmap_rwsem){+.+.}-{3:3}, at: mmap_region+0x4dc/0x6db
Invert those to the usual ordering.
Fixes: 33313a747e81 ("mm: lock newly
On Sat, Jul 8, 2023 at 3:54 PM Linus Torvalds
wrote:
>
> On Sat, 8 Jul 2023 at 15:36, Suren Baghdasaryan wrote:
> >
> > On Sat, Jul 8, 2023 at 2:18 PM Linus Torvalds
> > >
> > > Again - maybe I messed up, but it really feels like the missing
> > > vma_start_write() was more fundamental, and not s
On Sat, 8 Jul 2023 at 15:36, Suren Baghdasaryan wrote:
>
> On Sat, Jul 8, 2023 at 2:18 PM Linus Torvalds
> >
> > Again - maybe I messed up, but it really feels like the missing
> > vma_start_write() was more fundamental, and not some "TLB coherency"
> > issue.
>
> Sounds plausible. I'll try to use
On Sat, Jul 8, 2023 at 2:18 PM Linus Torvalds
wrote:
>
> On Sat, 8 Jul 2023 at 12:12, Suren Baghdasaryan wrote:
> >
> > kernel/fork.c | 1 +
> > 1 file changed, 1 insertion(+)
>
> I ended up editing your explanation a lot.
>
> I'm not convinced that the bug has much to do with the delayed tlb fl
On Sat, 8 Jul 2023 at 12:12, Suren Baghdasaryan wrote:
>
> kernel/fork.c | 1 +
> 1 file changed, 1 insertion(+)
I ended up editing your explanation a lot.
I'm not convinced that the bug has much to do with the delayed tlb flushing.
I think it's more fundamental than some tlb coherence issue:
On Sat, Jul 8, 2023 at 12:23 PM Linus Torvalds
wrote:
>
> On Sat, 8 Jul 2023 at 12:17, Suren Baghdasaryan wrote:
> >
> > Do you want me to disable per-VMA locks by default as well?
>
> No. I seriously believe that if the per-vma locking is so broken that
> it needs to be disabled in a development
On Sat, 8 Jul 2023 at 12:17, Suren Baghdasaryan wrote:
>
> Do you want me to disable per-VMA locks by default as well?
No. I seriously believe that if the per-vma locking is so broken that
it needs to be disabled in a development kernel, we should just admit
failure, and revert it all.
And not i
On Sat, Jul 8, 2023 at 12:12 PM Suren Baghdasaryan wrote:
>
> When forking a child process, parent write-protects an anonymous page
> and COW-shares it with the child being forked using copy_present_pte().
> Parent's TLB is flushed right before we drop the parent's mmap_lock in
> dup_mmap(). If we
When forking a child process, parent write-protects an anonymous page
and COW-shares it with the child being forked using copy_present_pte().
Parent's TLB is flushed right before we drop the parent's mmap_lock in
dup_mmap(). If we get a write-fault before that TLB flush in the parent,
and we end up
mmap_region adds a newly created VMA into VMA tree and might modify it
afterwards before dropping the mmap_lock. This poses a problem for page
faults handled under per-VMA locks because they don't take the mmap_lock
and can stumble on this VMA while it's still being modified. Currently
this does no
With recent changes necessitating mmap_lock to be held for write while
expanding a stack, per-VMA locks should follow the same rules and be
write-locked to prevent page faults into the VMA being expanded. Add
the necessary locking.
Cc: sta...@vger.kernel.org
Signed-off-by: Suren Baghdasaryan
---
On Sat, 8 Jul 2023 at 11:40, Suren Baghdasaryan wrote:
>
> My understanding was that flush_cache_dup_mm() is there to ensure
> nothing is in the cache, so locking VMAs before doing that would
> ensure that no page faults would pollute the caches after we flushed
> them. Is that reasoning incorrect
On Sat, Jul 8, 2023 at 11:05 AM Linus Torvalds
wrote:
>
> On Sat, 8 Jul 2023 at 10:39, Andrew Morton wrote:
> >
> > That was the v1 fix, but after some discussion
> > (https://lkml.kernel.org/r/20230705063711.2670599-1-sur...@google.com)
> > it was decided to take the "excessive" approach.
>
> Th
On Sat, 8 Jul 2023 at 10:39, Andrew Morton wrote:
>
> That was the v1 fix, but after some discussion
> (https://lkml.kernel.org/r/20230705063711.2670599-1-sur...@google.com)
> it was decided to take the "excessive" approach.
That makes absolutely _zero_ sense.
It seems to be complete voodoo prog
On Sat, 8 Jul 2023 10:29:42 -0700 Linus Torvalds
wrote:
> On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
> wrote:
> >
> > The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> > latest patch that does this is this one afaics:
>
> Bah.
>
> Both marking it as broken and the
On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
wrote:
>
> The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> latest patch that does this is this one afaics:
Bah.
Both marking it as broken and the pending fix seems excessive.
Why isn't the trivial fix just to say "yes, fo
On Fri, Jul 07, 2023 at 11:52:24AM +0200, Arnd Bergmann wrote:
> diff --git a/arch/mips/jazz/setup.c b/arch/mips/jazz/setup.c
> index ee044261eb223..3c14548353e47 100644
> --- a/arch/mips/jazz/setup.c
> +++ b/arch/mips/jazz/setup.c
> @@ -76,7 +76,7 @@ void __init plat_mem_setup(void)
>
> _m
[adding Linus to the list of recipients to ensure the fix makes it into
-rc1 (and can finally be backported to -stable).
Linus, here is the backstory, as I assume you haven't seen this yet:
CONFIG_PER_VMA_LOCK (which defaults to Y; merged for v6.4-rc1 in
0bff0aaea03 ("x86/mm: try VMA lock-based p
20 matches
Mail list logo
