mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hubertus Franke <frankeh@watson.ibm.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Robert Love <rml@tech9.net>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Fast Userspace Mutexes III.
Date: Mon, 4 Mar 2002 15:48:48 -0500	[thread overview]
Message-ID: <20020304154848.A1055@elinux01.watson.ibm.com> (raw)
In-Reply-To: <1015271393.15277.112.camel@phantasy> <Pine.LNX.4.44.0203041208310.1561-100000@blue1.dev.mcafeelabs.com>
In-Reply-To: <Pine.LNX.4.44.0203041208310.1561-100000@blue1.dev.mcafeelabs.com>; from davidel@xmailserver.org on Mon, Mar 04, 2002 at 12:13:50PM -0800

On Mon, Mar 04, 2002 at 12:13:50PM -0800, Davide Libenzi wrote:
> On 4 Mar 2002, Robert Love wrote:
> 
> > On Sun, 2002-03-03 at 22:55, Rusty Russell wrote:
> > > 1) Use mmap/mprotect bits, not new syscall (thanks RTH, Erik Biederman)
> > > 2) Fix wakeup race in kernel (thanks Martin Wirth, Paul Mackerras)
> > > 3) Simplify locking to a single atomic (no more arch specifics!)
> > > 4) Use wake-one by handcoding queues.
> > > 5) Comments added.
> > >
> > > Thanks to all for feedback and review: I'd appreciate a comment from
> > > those arch's which need to do something with the PROT_SEM bit.
> > >
> > > Once again, tested on 2.4.18 UP PPC, compiles on 2.5.6-pre1.
> > >
> > > Bad news is that we're up to 206 lines again.
> > > Rusty.
> >
> > Good work.  I likee.
> 
> Ok, i reply to this because my 'd' Pine's key is heavily used in these days :-)
> I took a look at the code yesterday night and i've a stupid question
> Rusty. I do not know what is the code used in the upper part of the
> iceberg ( userspace ) but are you doing a dec_and_test() on userspace
> before entering the kernel ? Or, is the kernel code the slow path or you
> enter it by default ?
> 
> 
> 
> - Davide
> 

Yes, that section is missing. It should be just as you said.

int futex_down(atomic_t *count)
{
	if (!atomic_dec_and_test(count)) 
		return sys_futex(count,FUTEX_DOWN);
	return 0;
}	

One needs to ensure that the atomic nature is compiled in (i.e. SMP) 
even if SMP is not enabled in the machine.

Rusty, could you post that code that you are using.


Also, the check on PROT_SEM is missing. I tried this before and glibc filtered
these flags out when set. But effectively, one still needs to check
whether semaphores are allowed during the sys_futex call.
This is expensive, because the protections are associated with the VMA.
find_vma() is not an option here, that's why I did the hashing and more persistent
objects rather than hashed wait queues.

I'd suggest to drop the requirements for this flag PROT_SEM.
I don't see tremendous value for it anyway, and it creates quite some 
headache if its to be enforced, which it is not in Rusty's code.
My code could do it, but as it comes with the complexity discussed earlier.

-- Hubertus

  parent reply	other threads:[~2002-03-04 20:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-04  3:55 Rusty Russell
2002-03-04 19:49 ` Robert Love
2002-03-04 20:13   ` Davide Libenzi
2002-03-04 20:20     ` Matthew Kirkwood
2002-03-04 20:48     ` Hubertus Franke [this message]
2002-03-04 22:15       ` Davide Libenzi
2002-03-05  1:50         ` Robert Love
2002-03-05  2:53           ` Davide Libenzi
2002-03-05  3:45           ` Rusty Russell
2002-03-05  3:55             ` Davide Libenzi
2002-03-05  6:11               ` Rusty Russell
2002-03-05 17:23                 ` Davide Libenzi
2002-03-05 15:09             ` Hubertus Franke
2002-03-05  4:30           ` Edgar Toernig
2002-03-07  1:58         ` Richard Henderson
2002-03-07  2:10           ` Davide Libenzi
2002-03-05  4:48     ` Rusty Russell
2002-03-05 15:15       ` Hubertus Franke
2002-03-06  1:31         ` Rusty Russell
2002-03-05  1:34   ` Rusty Russell
2002-03-07  1:52 ` Richard Henderson
2002-03-07  3:39 ` Rusty Russell
2002-03-07  8:48   ` Richard Henderson
2002-03-07  9:17     ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020304154848.A1055@elinux01.watson.ibm.com \
    --to=frankeh@watson.ibm.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@tech9.net \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®