linux-kernel - Re: Announce: Semaphore-Removal tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080428122004.GT14990@parisc-linux.org>
Date:	Mon, 28 Apr 2008 06:20:04 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	David Chinner <dgc@....com>
Cc:	linux-kernel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: Announce: Semaphore-Removal tree

On Mon, Apr 28, 2008 at 03:10:40PM +1000, David Chinner wrote:
> On Fri, Apr 25, 2008 at 11:00:21AM -0600, Matthew Wilcox wrote:
> > 
> > It's been a Good Idea for a while to use mutexes instead of
> > semaphores where possible.  Additional debuggability, better optimised,
> > better-enforced semantics, etc.
> > 
> > Obviously, there are some places that can't be converted to mutexes.
> > I'm not proposing blind changes. 
> 
> Matthew, what's the plan for code using semaphores that cannot be
> easily converted to something else? e.g. XFS?

I'm glad you asked!

Arjan, Ingo and I have been batting around something called a kcounter.
I appear to have misplaced the patch right now, but the basic idea is
that it returns you a cookie when you down(), which you then have to
pass to the up()-equivalent.  This gives you at least some of the
assurances you get from mutexes.

Though ... looking at XFS, you have 5 counting semaphores currently:

1. i_flock

This one seems to be a mutex.  I'd need to immerse myself in XFS for a
couple of days to verify that though -- there's a lot of places that use
it, and it doesn't have obvious lock/unlock pairing.  Is it sometimes
unlocked from a different thread than the one which locked it?  If so,
kcounters might be the right thing to use here.

2. l_flushsema

This seems to be a completion.  ie you're using it to wait for the log
to be flushed.

3. q_flock

Ow.  ow.  My brain hurts.  What are these semantics?

4. b_iodonesema

This should be a completion.  It's used to wait for the io to be
complete.

5. b_sema

This looks like a mutex, but I think it's released in a different
context from the one which acquires it.

-----

Possibly XFS should be using constructs like wait_on_bit instead of
semaphores.  See the implementation of wait_on_buffer for an example.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/