linux-kernel - Re: [PATCH v2] Documentation: rw

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: <alpine.LFD.2.01.0911120726430.31845@localhost.localdomain>
Date:	Thu, 12 Nov 2009 07:40:30 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	William Allen Simpson <william.allen.simpson@...il.com>
cc:	Stephen Hemminger <shemminger@...tta.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Developers <linux-kernel@...r.kernel.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH v2] Documentation: rw_lock lessons learned

On Thu, 12 Nov 2009, William Allen Simpson wrote:
>
> In recent weeks, two different network projects erroneously
> strayed down the rw_lock path.  Update the Documentation
> based upon comments by Eric Dumazet and Paul E. McKenney in
> those threads.

This still retains some pretty old and bogus language. For example, that 
file still talks about spinlocks being "faster than a global interrupt 
lock", which is kind of amusing - because we've not done that global 
interrupt lock thing for the last ten years or so. 

So I certainly agree with discouraging rwlocks - I don't think we've ever 
really found a situation where they are useful except for some really 
special cases - but I suspect the thing needs a bigger overhaul.

I also suspect somebody should actually take a look at our _users_ of 
rwlocks. We have a few fairly central ones like 'tasklist_lock', and it 
may be an example of a _good_ case of rwlocks, but for a very non-obvious 
reason.

In the case of 'tasklist_lock', the magic subtle reason that makes it a 
good idea is that that lock is commonly taken for reading in _interrupts_. 
And the way rwlocks are defined, that means that you can take it for 
reading without doing the *_irq() or *_irqsave() versions, because rwlocks 
are not fair, so an active reader will never block a new reader even if 
there is a blocked writer pending.

So for tasklist_lock, raw rwlocks are still slower than raw spinlocks, but 
because of the rwlock semantics the common case doesn't need to disable 
and enable interrupts, so for the common case the comparison is not "raw 
rwlock vs raw spinlock", but "raw rwlock vs interrupt-disabling spinlock", 
and then it turns out rwlocks tend to win again.

(Of course, lock_write() needs to disable interrupts for tasklist_lock, 
but that tends to be the uncommon case).

Ho humm..

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