linux-kernel - Re: RCU tests for Maple Tree

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]

Message-ID: <20210517165004.GI4441@paulmck-ThinkPad-P17-Gen-1>
Date:   Mon, 17 May 2021 09:50:04 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Liam Howlett <liam.howlett@...cle.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: RCU tests for Maple Tree

On Mon, May 17, 2021 at 04:30:53PM +0000, Liam Howlett wrote:
> * Paul E. McKenney <paulmck@...nel.org> [210517 11:40]:
> > Hello, Liam!
> > 
> > Apologies for my being so slow here, but just wanted to double-check my
> > understanding of this code.
> > 
> > There appear to be two tests that execute from run_check_rcu():
> > 
> > o	rcu_loop().  This appears to have RCU readers scanning the tree
> > 	while an updater is adding a single range.  (Or replacing it,
> > 	as the case might be.)
> > 
> > o	rcu_val().  This appears to have RCU readers repeatedly reading a
> > 	given value while an updater is adding/replacing a single range.
> > 	The test complains if no one sees the new value.
> > 
> > These tests appear to be the only use of threads, though perhaps the
> > test harness has some way of creating threads that I missed.
> > 
> > Are there other tests that I should be looking for?
> 
> No, those are the only ones I'm running with threads right now.  I think
> all RCU tests are run from check_rcu() iirc.  This did yield results of
> failures that had to be addressed so I'm somewhat confident that it's
> actually working.

OK, I guess I can feel relieved that I can still read code.  ;-)

> >From your wording I'm gathering I need to increase this by a lot more
> test cases?

I would feel better with the addition of something that looked more
like a stress test.  For but one example, is there some combination
of several successive update operations that can mess up slow readers
(that is, readers that are interrupted or preempted, and thus have
multiple updates happen while they are traversing the tree)?  If so,
the current tests will not find it.

							Thanx, Paul