[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMK7jwpI4uD6tKrF@casper.infradead.org>
Date: Thu, 27 Jul 2023 19:46:39 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Jann Horn <jannh@...gle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, syzkaller-bugs@...glegroups.com,
syzbot <syzbot+8645fe63c4d22c8d27b8@...kaller.appspotmail.com>
Subject: Re: [syzbot] [mm?] WARNING: suspicious RCU usage in mas_walk (2)
On Thu, Jul 27, 2023 at 11:31:01AM -0700, Suren Baghdasaryan wrote:
> A comment for __anon_vma_prepare() says "This must be called with the
> mmap_lock held for reading."
> I think adding an explicit mmap_assert_locked() in this function would
> help catch such issues.
Would it catch them faster than syzbot?
> > +++ b/mm/memory.c
> > @@ -3197,6 +3197,12 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
> > struct mmu_notifier_range range;
> > int ret;
> >
> > + if (!vma->anon_vma) {
> > + // check if there are other things to undo here
> > + vma_end_read(vmf->vma);
> > + return VM_FAULT_RETRY;
> > + }
> > +
>
> This one bails out later but if the path is not taken too often I
> think it's cleaner.
OK, then I think the right place to put this check is slightly before
this function is called, to avoid bouncing the folio refcount:
+++ b/mm/memory.c
@@ -3567,6 +3567,12 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf)
return 0;
}
copy:
+ if ((vmf->flags & FAULT_FLAG_VMA_LOCK) && !vma->anon_vma) {
+ pte_unmap_unlock(vmf->pte, vmf->ptl);
+ vma_end_read(vmf->vma);
+ return VM_FAULT_RETRY;
+ }
+
/*
* Ok, we need to copy. Oh, well..
*/
... it compiles. Guess I should figure out the syntax to ask syzbot to
test it.
Powered by blists - more mailing lists