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]

Message-ID: <20140930200959.GB8196@two.firstfloor.org>
Date:	Tue, 30 Sep 2014 22:10:00 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>, 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

> > 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. If you think I'm wrong please show working code.

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

Thanks,

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself 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/