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: <20070309051512.GB12479@wotan.suse.de>
Date:	Fri, 9 Mar 2007 06:15:12 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ulrich Drepper <drepper@...hat.com>
Subject: Re: [rfc][patch] futex: restartable futex_wait?

On Fri, Mar 09, 2007 at 12:02:31AM +0100, Thomas Gleixner wrote:
> On Thu, 2007-03-08 at 18:29 +0100, Ingo Molnar wrote:
> > * Nick Piggin <npiggin@...e.de> wrote:
> > 
> > > Hi Ingo,
> > > 
> > > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically, 
> > > it tests whether the SA_RESTART flag works for the sem_wait operation.
> 
> Not sure, whether the testcase is correct or not. See below
> 
> > > I see sem_wait is implemented with futex_wait, so I wonder whether we 
> > > can make it restartable? Am I going about it the right way? (Seems to 
> > > fix the testcase here).
> > 
> > i think that's quite right. I'm wondering why this never came up before? 
> > But your fix is not complete i think:
> > 
> > > +             restart->arg2 = time;
> > > +             return -ERESTART_RESTARTBLOCK;
> > > +     }
> > 
> > 'time' here is relative, so the restarted syscall will do a /full/ wait 
> > again.
> > 
> > maybe we should rather convert futex timed-waits to hrtimers? Thomas?
> 
> The problem is that the original API is based on relative time and
> therefor can not be changed. 
> 
> sem_wait returns -EINTR to the application when it is interrupted, while
> pthread_mutex_lock does not.

But this still means sem_wait should restart if SA_RESTART is set, right?

And pthread_mutex_lock could be implemented to not return -EINTR, even if
futex_wait does, couldn't it? (I guess it probably already is, considering
that futex_wait alsready returns -EINTR).

> 
> http://www.opengroup.org/onlinepubs/009695399/functions/sem_wait.html
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
> 
> We need to create a seperate op for the futex - just like the pi_futex
> and use absolute time there too. 
> 
> 	tglx
> 
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ