linux-kernel - Re: [PATCH] maple_tree: Fix sparse reported issues

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Jul 2022 08:55:53 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Liam Howlett <liam.howlett@...cle.com>
cc:     David Hildenbrand <david@...hat.com>,
        "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] maple_tree: Fix sparse reported issues

On Wed, 13 Jul 2022, Liam Howlett wrote:
> * David Hildenbrand <david@...hat.com> [220713 04:34]:
> > On 12.07.22 16:24, Liam Howlett wrote:
> > > When building with C=1, the maple tree had some rcu type mismatch &
> > > locking mismatches in the destroy functions.  There were cosmetic only
> > > since this happens after the nodes are removed from the tree.
> > > 
> > > Fixes: f8acc5e9581e (Maple Tree: add new data structure)
> > > Reported-by: kernel test robot <lkp@...el.com>
> > > Signed-off-by: Liam R. Howlett <Liam.Howlett@...cle.com>
> > 
> > Sorry to say, but the fixes become hard to follow (what/where/why). :)
> > 
> > I guess it's time for a new series soon. Eventually it makes sense to
> > send the fixes as reply to the individual problematic patches. (instead
> > of fixes to commit ids that are not upstream)
> > 
> > [yes, I'll do more review soon :) ]
> 
> I appreciate the feedback, it's much better than yelling into the void.
> I have one more fix in the works - for __vma_adjust() of all functions
> so that'll be impossible to follow anyways :)  I'll work on a v11 to
> include that last one.

Please do also post the incremental for that "one more fix" once it's
ready: I have been keeping up with what you've been posting so far,
folding them into my debugging here, and believe we have made some but
still not enough progress on the bugs I hit.  Folding in one more fix
will be easy for me, advancing to v11 of a 69-part patchset will be...
dispiriting.

Thanks,
Hugh