linux-kernel - Re: [PATCH 1/2] Use faster check for modules in backtrace on 64bit

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:	Thu, 2 Oct 2014 12:57:34 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Andi Kleen <ak@...ux.intel.com>, dave@...1.net,
	linux-kernel@...r.kernel.org, mingo@...nel.org, eranian@...gle.com,
	x86@...nel.org
Subject: Re: [PATCH 1/2] Use faster check for modules in backtrace on 64bit

On Tue, Sep 30, 2014 at 10:10:00PM +0200, Andi Kleen wrote:
> > > Also I investigated it now, but we don't have RCU support for rbtrees.
> > > So it would need some kind of locking for the reader, which is a show
> > > stopper.
> > 
> > Nah, we can trivially do that with a seqlock. Not read side locking
> > required in the normal case.
> 
> I'm not convinced. It wouldn't surprise me if it was possible
> to generate endless cycles with rcu freed memory on some rebalancing
> operation.

I don't think so, every (tree) rotation still maintains the tree as a
tree, therefore downward iteration will always get you to the end.

You might temporarily run in circles until you observe the new pointers,
but that is not a problem, and strictly limited to however long it takes
for the new pointers to become visible on the iterating CPU.

Deletion should not be a problem either, if the deleted node retains
pointers, they'll point back into the tree, and by the previous
argument, downward iteration terminates.

> If you think I'm wrong please show working code.

That is unrelated to the above, you're just not willing to work on it.
Which is fine, then this problem will remain for a little while longer.

> Also please explain clearly for the module maintainers and me
> what the problem with my original simple trivially show
> to be correct solution is.

It is not correct, you yourself said there were false positives with it.
But the biggest issue is that its x86_64 only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/