linux-kernel - Re: [PATCH RFC tip/core/rcu 7/7] rcu: Quiet RCU-lockdep warnings involving interrupt disabling

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: <1323174405.30977.86.camel@frodo>
Date:	Tue, 06 Dec 2011 07:26:45 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Yong Zhang <yong.zhang0@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...ymtl.ca, josh@...htriplett.org,
	niv@...ibm.com, tglx@...utronix.de, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, eric.dumazet@...il.com, darren@...art.com,
	patches@...aro.org
Subject: Re: [PATCH RFC tip/core/rcu 7/7] rcu: Quiet RCU-lockdep warnings
 involving interrupt disabling

On Tue, 2011-12-06 at 11:32 +0100, Peter Zijlstra wrote:

> > > 
> > > > Maybe we could teach might_sleep() about this special case?
> > > 
> > > Sounds horrid.
> > 
> > Maybe, any alternative?
> 
> Maybe someone explain this mess first?

Me too, because this looks like a hack that's just like a lie. The first
lie to be said gets you out of a bit of trouble, but then something else
happens based on that lie, in which you need to make another bigger lie.
This new lie affects more people and requires new more ingenious lies to
control the chaos. But eventually the lies required to keep everything
going become so overwhelming that it all blows up in your face and you
end up looking like a jackass.

Why is rcu using rt_mutex_lock() in strange ways? It's lying about its
use. And now this patch is the bigger lie to get around the issues of
the first lie. Eventually this code will continue to expand largely
based on these lies and will explode in our faces, and I feel sorry for
the poor jackass that needs to fix it.

Perhaps the real answer is that we need to create an API for priority
inheritance, that things like RCU could use. Attach a task that another
task requires to finish something and boost the priority of that task.
Maybe even completions could use such a thing?

-- Steve

--
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/