linux-kernel - Re: [PATCH v2 08/11] firewire-sbp-target: Add sbp

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: <20120315174837.GH2381@linux.vnet.ibm.com>
Date:	Thu, 15 Mar 2012 10:48:37 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Chris Boot <bootc@...tc.net>,
	linux1394-devel@...ts.sourceforge.net,
	target-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
	agrover@...hat.com, clemens@...isch.de, nab@...ux-iscsi.org
Subject: Re: [PATCH v2 08/11] firewire-sbp-target: Add sbp_login.{c,h}

On Sat, Mar 03, 2012 at 06:37:22PM +0100, Stefan Richter wrote:
> On Feb 16 Chris Boot wrote:

[ . . . ]

> > I guess I need to protect access to 
> > the entire session really. Possibly even rwlocks due to only the 
> > management processes ever changing anything, but lots of reads during 
> > command handling.
> 
> The use case for rwlocks is not really the case where infrequent write
> access meets frequent read access.  Rather, the use case is when it is
> important to reduce or prevent contention between readers.
> 
> Rwlocks come with their own downsides though.  I guess the somewhat
> costlier lock implementation could counter the benefit of allowing
> concurrent readers.  Or maybe latency spikes around a write access could be
> an issue.
> 
> I believe I have read somewhere that one should rather use a simple
> spinlock unless exhaustive tests prove that an rwlock really performs
> better.  Furthermore, in many if not all use cases of rwlocks, RCU is
> available as another alternative.  RCU comes with its own set of downsides
> though, for example not being as well and widely understood by programmers
> compared to locking, being less easy to debug (may have improved
> recently), and posing some challenges to RT-PREEMPT kernels.

The preemptible RCU implementations (TREE_PREEMPT_RCU and TINY_PREEMPT_RCU)
handle the -rt tree.

> AFAIU the above considerations cannot be applied 100 % to able-to-sleep
> reader-writer locks, i.e. the kernel's rwsem.  Still, the use case of an
> rwsem (in contrast to a mutex) is not particularly where a datum is rarely
> written and often read, but where it is desirable to let multiple readers
> not block each other.
> 
> [Somebody correct me where I'm wrong.]

And you can use SRCU if readers need to block.

That said, even I agree that RCU is not always the right tool for the job.

							;-), Paul

> PS, I cloned your git tree not long ago, but again various distractions
> kept me from having a broader look at your code...
> -- 
> Stefan Richter
> -=====-===-- --== ---==
> http://arcgraph.de/sr/
> --
> 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/
> 

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