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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080429000929.GF108924158@sgi.com>
Date:	Tue, 29 Apr 2008 10:09:30 +1000
From:	David Chinner <dgc@....com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: Announce: Semaphore-Removal tree

On Mon, Apr 28, 2008 at 06:20:04AM -0600, Matthew Wilcox wrote:
> 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.

<sigh>

back to the days of cookies being required for locks. We only just
removed all the remaining lock cruft left over from Irix that used
cookies like this. i.e.:

	DECL_LOCK_COOKIE(cookie);

	cookie = spin_lock(&lock);
	.....
	spin_unlock(&lock, cookie);

it's an ugly, ugly API....

> Though ... looking at XFS, you have 5 counting semaphores currently:
> 
> 1. i_flock
> 
> This one seems to be a mutex. 

No, it's a semaphore. It is the inode flush lock and is held over
I/O on the inode. It is released in a different context to the
process that holds it. We use trylock semantics on it all the time
to determine if we can write the inode to disk.

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

Yes, that could probably be a completion. I'm assuming that a completion
can handle several thousand waiting processes, right?

> 3. q_flock
> 
> Ow.  ow.  My brain hurts.  What are these semantics?

Same semantics as the i_flock - it's held while flushing the dquot
to disk and is released by a different thread. Trylocks are used on
this as well...

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

Yup, that could be done.

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

Yup. held across I/O and typically released by a different thread.
Trylock semantics used as well.

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

That sounds to me like you are saying is "semaphores are going away so
implement your own semaphore-like thingy using some other construct".
Right?

If that's the case, then AFAICT changing to completions and then
s/semaphore/rw_semaphore/ and using only {down,up}_write() for
the rest should work, right? Or are rwsem's going to go away, too?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
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/