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: <20080430102103.GJ14976@parisc-linux.org>
Date:	Wed, 30 Apr 2008 04:21:03 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	David Chinner <dgc@....com>
Cc:	linux-kernel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: Announce: Semaphore-Removal tree

On Tue, Apr 29, 2008 at 01:56:59PM +1000, David Chinner wrote:
> On Mon, Apr 28, 2008 at 08:35:20PM -0600, Matthew Wilcox wrote:
> > Perhaps you can suggest a better one?  Our thought was that you have ...
> > 
> > struct xfs_inode {
> > 	struct kcounter_t i_flock
> > };
> > 
> > struct foo {
> > 	... other stuff you need for the io ...
> > 	kcounter_cookie_t kct;
> > }
> 
> You mean:
> 
> struct kcounter_sem {
> 	struct kcounter		cnt;
> 	kcounter_cookie_t	cookie;
> };
> 
> #define down(s)	kcounter_claim(&s->cnt, &s->cookie);
> #define up(s)	kcounter_release(&s->cnt, &s->cookie);
> 
> I can't see how this fixes the semaphore abuse problem at all
> because you can trivially roll your own. We know where that
> leads (i.e. everyone does it their own unique way)...

That would actually work -- if you use it in a mutex way.  It would then
have slightly sloppier semantics than mutexes -- ie you could unlock from
a different context than the one which locked.  But it would whinge if
you try to use it as a completion.

> > 	int err = kcounter_claim(&ino->i_flock, &foo->kct);
> > ...
> > 	kcounter_release(&ino->i_flock, &foo->kct);
> 
> Is there the possibility of errors when taking a counter reference
> in this api? i.e. can the equivalent of "down()" return an error?

My current thinking was not to support an equivalent to down(), only to
down_killable().  On further thought, that may not be wise.

> > If you're always using trylock semantics on it, then it's not really a
> > semaphore, is it?
> 
> I should have been more precise with my description - we use trylock
> semantics on them when we need to gain them in different orders to
> the normal heirachy (which is quite often) or we are operating in
> non-blocking conditions (again quite often). Otherwise we do normal
> sleeping down() calls.

OK.

> > > > 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?
> > 
> > I don't want to say that.  People (and I'm *not* referring to XFS here)
> > manage to abuse semaphores in the most hideous ways.
> 
> Yes, I've been following the argume^W discussions wating for an outcome.
> 
> > If we tell them to
> > use lower-level constructs, they'll make a mess of using those too.
> 
> See above ;)
> 
> > I
> > think we need to look for patterns in the semaphore users which don't
> > fit the mutex pattern or the completion pattern and figure out how to
> > satisfy those users.
> 
> Ok, so here's a user that says they need a semaphore-like construct that
> behaves the same way the current semaphores do.  What is the solution?

I think it's kcounters.  The trick is creating an API that's
lockdep-friendly and works for the users.

> > I don't think there are any plans to get rid of rwsems, though the RT
> > people probably hate rwsems even more than they hate regular semaphores.
> 
> Fmeh.
> 
> > The mmap rwsem is a compelling argument ;-)
> 
> It's an argument for a different lock type for that particular case, not
> an argument for removing the lock type completely.

Ah, I meant it's a compelling argument for keeping rwsems.

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