lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 4 Jul 2023 14:04:32 -0400
From:   "Liam R. Howlett" <Liam.Howlett@...cle.com>
To:     Oliver Sang <oliver.sang@...el.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        lkp@...el.com
Subject: Re: [mm] 408579cd62: WARNING:suspicious_RCU_usage

* Liam R. Howlett <Liam.Howlett@...cle.com> [230704 11:25]:
> * Oliver Sang <oliver.sang@...el.com> [230704 09:51]:

...
> > > Ok, that is indeed a very different stack trace.
> > > 
> > > So maybe the fix is a real fix, but the first complaint shut up
> > > lockdep, so this is the *second* and unrelated complaint.
> > > 
> > > And indeed: it turns out that do_vma_munmap() does this:
> > > 
> > >         ret = do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock);
> > >         validate_mm(mm);
> > > 
> > > and so we have *another* validate_mm() that is now done outside the lock.
> > > 
> > > That one is actually pretty pointless. We've *just* validated the mm
> > > already inside do_vmi_align_munmap(), except we only did it in one of
> > > the two return cases.
> > > 
> > > So I think the fix is to just move that validate_mm() into the other
> > > return case of do_vmi_align_munmap(), and remove it from the caller.
> > > 
> > > IOW, something like the attached (NOTE! This is in *addition* to the
> > > previous patch, which is the same as the one you quoted, just with
> > > slightly different whitespace as commit ae80b4041984: "mm: validate
> > > the mm before dropping the mmap lock").
> > 
> > Thanks a lot for guidance!
> > I applied below patch directly upon ae80b4041984, and confirmed the
> > WARNING gone. Thanks
> > 
> 
> Thanks for testing this.
> 
> I can clean more of this up now that the mmap locking has been changed.
> For instance, we can drop a number of checks before a write (and all
> read cases, if any remain) since there is no alteration without the
> write lock.

Thanks Linus for fixing the two issues causing rcu warnings - my testing
had lockdep & maple tree debug, so I'm still working on why my testing
failed on the initial patch.

For the time being, I've used the config from the bot to test a larger
cleanup of this code.  I'll send it through the mm development as to get
better test coverage.

Regards,
Liam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ