linux-kernel - Re: [patch 2/6 -rt] powerpc 2.6.20-rt8: to convert spinlocks to raw ones.

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, 7 Mar 2007 20:00:38 -0800
From:	Bill Huey (hui) <billh@...ppy.monkey.org>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Sergei Shtylyov <sshtylyov@...mvista.com>,
	Tsutomu OWA <tsutomu.owa@...hiba.co.jp>,
	linuxppc-dev@...abs.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org,
	"Bill Huey (hui)" <billh@...ppy.monkey.org>
Subject: Re: [patch 2/6 -rt] powerpc 2.6.20-rt8: to convert spinlocks to raw ones.

On Thu, Mar 08, 2007 at 02:26:47PM +1100, Paul Mackerras wrote:
> Bill Huey (hui) writes:
> 
> > The places that need to be reverted to raw spinlocks are generally either
> > acquired by function calls that allocate the spinlock at a terminal of the
> > kernel's lock graph or isolated from other callers completely (parts of the
> > timer for logic for instance). It's all about the collision of various lock
> > (preemptive and non-preemptive) subtrees and how to avoid scheduling within
> > atomic violations that lead to deadlocks. The -rt patch gets arbitrary
> > preemption abilities by shrinking the non-preemptive sub-tree bit to the bare
> > essentials of what will let a system to run yet still preserve all of
> > the expected locking semantics of a critical section.
> 
> Thanks; that's an interesting explanation.
> 
> It misses the point of what I was saying to Sergei, though, which was
> *not* "I don't understand your patch", it was "if this patch goes into
> a git tree, someone coming along in 3 years time won't understand the
> patch."  In other words I was ranting about the need for a decent
> description to accompany the patch itself, so it would go into the
> permanent record.

Yeah, I think it's a a fear and uncertainly about the technical details about
the patch. That is why folks CC Ingo and company to get either a kind of
confirmation that this is ok along with comments. There are very few folks
that really understand the basic principals of the patch in this community
and that's not going to change any time soon. The mystery, paranoia (FUD)
and criticism surrounding it can make folks a bit shy.

I'll talk to you and Ben about it if we all get to OLS again. :)

bill

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