Re: flock, FAGAIN, and FWOULDBLOCK

Re: flock, FAGAIN, and FWOULDBLOCK

[Kyle McMartin]

On Sun, Feb 22, 2009 at 05:49:24PM -0500, Kyle McMartin wrote:
> > according to the flock(2) man page, flock should return EWOULDBLOCK 
> > when a file is locked and the LOCK_NB flag was selected. But on hppa, 
> > it seems to return EAGAIN which is not the same. Where is the bug 
> > here? In the kernel, glibc, or manpages-dev?
> > 
> > This causes problems in apr since it only checks for EWOULDBLOCK.
> > 
> 
> Ugh. Fail.
> 
> EWOULDBLOCK is defined to be EAGAIN on every architecture but parisc,
> since HPUX has different errno values for EAGAIN and EWOULDBLOCK.
> 
> Definitely a kernel bug, if posix says it should return EWOULDBLOCK...
> 

This is really going to suck, it looks like a lot of the locking
primitives used EAGAIN and EWOULDBLOCK interchangeably... The fcntl
manpage says 'EAGAIN or EWOULDBLOCK' so is flock(2) the only problem
here? From a quick glance at posix, fcntl(2) returning EAGAIN is
correct.

My guess is, I'll be able to sort this out with a simple

diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index 71b3195..18e8542 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -156,6 +156,17 @@ asmlinkage unsigned long sys_mmap(unsigned long addr, unsigned long len,
 
 /* Fucking broken ABI */
 
+asmlinkage long parisc_flock(unsigned int fd, unsigned int cmd)
+{
+	long ret;
+
+	ret = sys_flock(fd, cmd);
+	if (ret == -EAGAIN)
+		ret = -EWOULDBLOCK;	/* fuck you HPUX */
+
+	return ret;
+}
+
 #ifdef CONFIG_64BIT
 asmlinkage long parisc_truncate64(const char __user * path,
 					unsigned int high, unsigned int low)
diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S
index 303d2b6..8c62951 100644
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
@@ -226,7 +226,7 @@
 	/* it is POSSIBLE that select will be OK because even though fd_set
 	 * contains longs, the macros and sizes are clever. */
 	ENTRY_COMP(select)
-	ENTRY_SAME(flock)
+	ENTRY_OURS(flock)
 	ENTRY_SAME(msync)
 	/* struct iovec contains pointers */
 	ENTRY_COMP(readv)		/* 145 */

but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
is going to reveal latent problems in this part of the kernel I would
rather not delve into...

cheers, Kyle

Re: flock, FAGAIN, and FWOULDBLOCK

[Carlos O'Donell]

On Sun, Feb 22, 2009 at 8:42 PM, Kyle McMartin <kyle@infradead.org> wrote:
>> Definitely a kernel bug, if posix says it should return EWOULDBLOCK...

flock is not POSIX, it's an interface invented by 4.2BSD, and was
previously emulated by glibc. The glibc wrapper implemented flock with
fcntl and made sure to return EWOULDBLOCK.

> This is really going to suck, it looks like a lot of the locking
> primitives used EAGAIN and EWOULDBLOCK interchangeably... The fcntl
> manpage says 'EAGAIN or EWOULDBLOCK' so is flock(2) the only problem
> here? From a quick glance at posix, fcntl(2) returning EAGAIN is
> correct.

I would warn you that the linux man pages are often incorrect.

I use http://www.opengroup.org/onlinepubs/009695399/ for check POSIX
requirements.

> diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
> index 71b3195..18e8542 100644
> --- a/arch/parisc/kernel/sys_parisc.c
> +++ b/arch/parisc/kernel/sys_parisc.c
> @@ -156,6 +156,17 @@ asmlinkage unsigned long sys_mmap(unsigned long addr, unsigned long len,
>
>  /* Fucking broken ABI */
>
> +asmlinkage long parisc_flock(unsigned int fd, unsigned int cmd)
> +{
> +       long ret;
> +
> +       ret = sys_flock(fd, cmd);
> +       if (ret == -EAGAIN)
> +               ret = -EWOULDBLOCK;     /* fuck you HPUX */

A more robust solution would be?

if ((ret == -EAGAIN) || (ret == -EWOULDBLOK))
        ret = -EWOULDBLOCK

This covers our ass since POSIX says that EAGAIN and EWOULDBLOCK *may*
be the same.

> but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
> is going to reveal latent problems in this part of the kernel I would
> rather not delve into...

The ABI is fixed, so all we can do is cleanup the uses in the kernel,
and make sure we adhere to the documented APIs.

Don't get too upset ;-)

Cheers,
Carlos.

Re: flock, FAGAIN, and FWOULDBLOCK

[Kyle McMartin]

On Sun, Feb 22, 2009 at 09:43:36PM -0500, Carlos O'Donell wrote:
> flock is not POSIX, it's an interface invented by 4.2BSD, and was
> previously emulated by glibc. The glibc wrapper implemented flock with
> fcntl and made sure to return EWOULDBLOCK.
> 

Right, I had confused flock and flockfile in the index.

> > This is really going to suck, it looks like a lot of the locking
> > primitives used EAGAIN and EWOULDBLOCK interchangeably... The fcntl
> > manpage says 'EAGAIN or EWOULDBLOCK' so is flock(2) the only problem
> > here? From a quick glance at posix, fcntl(2) returning EAGAIN is
> > correct.
> 
> I would warn you that the linux man pages are often incorrect.
> 
> I use http://www.opengroup.org/onlinepubs/009695399/ for check POSIX
> requirements.
> 

I wouldn't be nearly so negative.

> A more robust solution would be?
> 
> if ((ret == -EAGAIN) || (ret == -EWOULDBLOK))
>         ret = -EWOULDBLOCK
> 
> This covers our ass since POSIX says that EAGAIN and EWOULDBLOCK *may*
> be the same.
> 

I have no idea what you're on about here, this is a parisc specific
file, where we know they aren't. I don't want to pollute generic linux
code with workarounds for moronic HPUX "let's be different for
difference sake" crap.

> > but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
> > is going to reveal latent problems in this part of the kernel I would
> > rather not delve into...
> 
> The ABI is fixed, so all we can do is cleanup the uses in the kernel,
> and make sure we adhere to the documented APIs.
> 

I ain't volunteering...

> Don't get too upset ;-)

Re: flock, FAGAIN, and FWOULDBLOCK

[Carlos O'Donell]

On Sun, Feb 22, 2009 at 9:54 PM, Kyle McMartin <kyle@infradead.org> wrote:
>> A more robust solution would be?
>>
>> if ((ret == -EAGAIN) || (ret == -EWOULDBLOK))
>>         ret = -EWOULDBLOCK
>>
>> This covers our ass since POSIX says that EAGAIN and EWOULDBLOCK *may*
>> be the same.
>>
>
> I have no idea what you're on about here, this is a parisc specific
> file, where we know they aren't. I don't want to pollute generic linux
> code with workarounds for moronic HPUX "let's be different for
> difference sake" crap.

If sys_flock can return one of -EAGAIN or -WOULDBLOCK, perhaps because
the generic code uses them interchangeably, then a more robust
solution is to check for both, and *then* return the expected value to
userspace.

Would this be a possible solution:
1) Make EAGAIN and EWOULDBLOCK the same for the kernel.
2) Leave the values the same for userspace.
3) Add wrappers in the parisc specific kernel code when a syscall need
to return one of EAGAIN or EWOULDBLOCK to userspace?

Cheers,
Carlos.

Re: flock, FAGAIN, and FWOULDBLOCK

[Matthew Wilcox]

On Sun, Feb 22, 2009 at 09:43:36PM -0500, Carlos O'Donell wrote:
> flock is not POSIX, it's an interface invented by 4.2BSD, and was
> previously emulated by glibc. The glibc wrapper implemented flock with
> fcntl and made sure to return EWOULDBLOCK.

glibc's emulation of flock() using fcntl() really belongs to the Dark
Ages of Linux.  According to the comments in the kernel, flock(2) was
added in June 1995.  That's four years before parisc-linux really got
going.

The semantics of flock-locks and fcntl-locks are really, really
different.  Emulating one with the other was a really bad idea.

> > +       ret = sys_flock(fd, cmd);
> > +       if (ret == -EAGAIN)
> > +               ret = -EWOULDBLOCK;     /* fuck you HPUX */
> 
> A more robust solution would be?
> 
> if ((ret == -EAGAIN) || (ret == -EWOULDBLOK))
>         ret = -EWOULDBLOCK

How would that differ from what Kyle wrote?  Why would you want to
assign -EWOULDBLOCK to ret if ret is already -EWOULDBLOCK?

> This covers our ass since POSIX says that EAGAIN and EWOULDBLOCK *may*
> be the same.

That's irrelevant.  The only thing that matters is what the kernel does.

> > but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
> > is going to reveal latent problems in this part of the kernel I would
> > rather not delve into...
> 
> The ABI is fixed, so all we can do is cleanup the uses in the kernel,
> and make sure we adhere to the documented APIs.

We actually can do better than this ...

#ifdef __KERNEL__
#define EWOULDBLOCK	EAGAIN
#else
#define EWOULDBLOCK	/* whatever the fuck HPUX uses */
#endif

Now our kernel never returns -EWOULDBLOCK, only -EAGAIN.  Correct
applications must check for both.  Incorrect applications tend to only
check for AGAIN, not WOULDBLOCK.  Problem solved.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"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."

Re: flock, FAGAIN, and FWOULDBLOCK

[Michael Kerrisk]

Matthew,

On 2/23/09, Matthew Wilcox <matthew@wil.cx> wrote:
> On Sun, Feb 22, 2009 at 09:43:36PM -0500, Carlos O'Donell wrote:
>> flock is not POSIX, it's an interface invented by 4.2BSD, and was
>> previously emulated by glibc. The glibc wrapper implemented flock with
>> fcntl and made sure to return EWOULDBLOCK.
>
> glibc's emulation of flock() using fcntl() really belongs to the Dark
> Ages of Linux.  According to the comments in the kernel, flock(2) was
> added in June 1995.  That's four years before parisc-linux really got
> going.
>
> The semantics of flock-locks and fcntl-locks are really, really
> different.  Emulating one with the other was a really bad idea.

Quite.

>> > +       ret = sys_flock(fd, cmd);
>> > +       if (ret == -EAGAIN)
>> > +               ret = -EWOULDBLOCK;     /* fuck you HPUX */
>>
>> A more robust solution would be?
>>
>> if ((ret == -EAGAIN) || (ret == -EWOULDBLOK))
>>         ret = -EWOULDBLOCK
>
> How would that differ from what Kyle wrote?  Why would you want to
> assign -EWOULDBLOCK to ret if ret is already -EWOULDBLOCK?
>
>> This covers our ass since POSIX says that EAGAIN and EWOULDBLOCK *may*
>> be the same.
>
> That's irrelevant.  The only thing that matters is what the kernel does.
>
>> > but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
>> > is going to reveal latent problems in this part of the kernel I would
>> > rather not delve into...
>>
>> The ABI is fixed, so all we can do is cleanup the uses in the kernel,
>> and make sure we adhere to the documented APIs.
>
> We actually can do better than this ...
>
> #ifdef __KERNEL__
> #define EWOULDBLOCK	EAGAIN
> #else
> #define EWOULDBLOCK	/* whatever the fuck HPUX uses */
> #endif
>
> Now our kernel never returns -EWOULDBLOCK, only -EAGAIN.  Correct
> applications must check for both.  Incorrect applications tend to only
> check for AGAIN, not WOULDBLOCK.  Problem solved.

I'm not sure how you define "correct" here.  An application that
follows the BSD implementation standard need only check for
EWOULDBLOCK from flock(), I believe.  (I can find no system that
documents otherwise for flock().)

If you are talking more generally, POSIX.1-2001, which doesn't specify
flock(), only refers to the use of EWOULDBLOCK in the context of
socket-related calls, where it says that a non-blocking call can fail
with either EAGAIN or EWOULDBLOCK, so I suppose that a portable
sockets application must check for both.  (In all other cases of
non-blocking calls (e.g., read()/write() from files other than
sockets, sigtimedwait(), lockf(), mq_send(), mq_receive()) that fail
in circumstances where they would otherwise block, the error is always
EAGAIN, with the exception noted earlier for fcntl(F_SETLK) (EACCES or
EWOULDBLOCK).)

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: flock, FAGAIN, and FWOULDBLOCK

[Helge Deller]

Matthew Wilcox wrote:
> On Sun, Feb 22, 2009 at 09:43:36PM -0500, Carlos O'Donell wrote:
>>> ...
>>> but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
>>> is going to reveal latent problems in this part of the kernel I would
>>> rather not delve into...
>> The ABI is fixed, so all we can do is cleanup the uses in the kernel,
>> and make sure we adhere to the documented APIs.
> 
> We actually can do better than this ...
> 
> #ifdef __KERNEL__
> #define EWOULDBLOCK	EAGAIN
> #else
> #define EWOULDBLOCK	/* whatever the fuck HPUX uses */
> #endif

Wouldn't this hurt us if we at some point in time want to finish 
the HPUX/Linux compat code in the parisc kernel?

Helge

> Now our kernel never returns -EWOULDBLOCK, only -EAGAIN.  Correct
> applications must check for both.  Incorrect applications tend to only
> check for AGAIN, not WOULDBLOCK.  Problem solved.

Re: flock, EAGAIN, and EWOULDBLOCK

[Stefan Fritsch]

On Monday 23 February 2009, Matthew Wilcox wrote:
> On Sun, Feb 22, 2009 at 09:43:36PM -0500, Carlos O'Donell wrote:
> > flock is not POSIX, it's an interface invented by 4.2BSD, and was
> > previously emulated by glibc. The glibc wrapper implemented flock
> > with fcntl and made sure to return EWOULDBLOCK.

As an additional data point, openbsd's flock man page also says it 
should return EWOULDBLOCK.

> We actually can do better than this ...
>
> #ifdef __KERNEL__
> #define EWOULDBLOCK	EAGAIN
> #else
> #define EWOULDBLOCK	/* whatever the fuck HPUX uses */
> #endif
>
> Now our kernel never returns -EWOULDBLOCK, only -EAGAIN.  Correct
> applications must check for both.  Incorrect applications tend to
> only check for AGAIN, not WOULDBLOCK.  Problem solved.

This seems to be the current behaviour WRT flock(). But this is 
broken. An application (like apr in this case) that checks for the 
documented and well established return code is _not_ incorrect.

For apr in Debian, I will simply add the check for EAGAIN. But this is 
cannot be the general solution.


Cheers,
Stefan

Re: flock, FAGAIN, and FWOULDBLOCK

[Michael Kerrisk]

On 2/23/09, Carlos O'Donell <carlos@systemhalted.org> wrote:
> On Sun, Feb 22, 2009 at 8:42 PM, Kyle McMartin <kyle@infradead.org> wrote:
>>> Definitely a kernel bug, if posix says it should return EWOULDBLOCK...
>
> flock is not POSIX, it's an interface invented by 4.2BSD, and was
> previously emulated by glibc. The glibc wrapper implemented flock with
> fcntl and made sure to return EWOULDBLOCK.
>
>> This is really going to suck, it looks like a lot of the locking
>> primitives used EAGAIN and EWOULDBLOCK interchangeably... The fcntl
>> manpage says 'EAGAIN or EWOULDBLOCK' so is flock(2) the only problem
>> here? From a quick glance at posix, fcntl(2) returning EAGAIN is
>> correct.
>
> I would warn you that the linux man pages are often incorrect.

Hmmm -- "often" is rather strong.  I will certainly allow
"occasionally" (or perhaps a little more), and I note in passing that
for someone making the claim of "often", I never saw a patch from you
so far to correct an error...

Cheers,

Michael

Re: flock, FAGAIN, and FWOULDBLOCK

[Michael Kerrisk]

Hi Kyle,

On 2/23/09, Kyle McMartin <kyle@infradead.org> wrote:
> On Sun, Feb 22, 2009 at 05:49:24PM -0500, Kyle McMartin wrote:
>> > according to the flock(2) man page, flock should return EWOULDBLOCK
>> > when a file is locked and the LOCK_NB flag was selected. But on hppa,
>> > it seems to return EAGAIN which is not the same. Where is the bug
>> > here? In the kernel, glibc, or manpages-dev?
>> >
>> > This causes problems in apr since it only checks for EWOULDBLOCK.
>> >
>>
>> Ugh. Fail.
>>
>> EWOULDBLOCK is defined to be EAGAIN on every architecture but parisc,
>> since HPUX has different errno values for EAGAIN and EWOULDBLOCK.
>>
>> Definitely a kernel bug, if posix says it should return EWOULDBLOCK...

Note the following:

* POSIX has no specification of flock() (only fcntl() locking is
specified by POSIX.1).

* My understanding is that EAGAIN originated on System V, and was the
error returned instead of blocking for system calls performing I/O,
semaphore operations, message queue operations, and (fcntl()) file
locking.  EWOULDBLOCK originated on BSD, and was returned by (flock())
file locking and socket-related system calls.

* flock() is a BSDism, and the associated error was EWOULDBLOCK.

* Generally POSIX requires that each error name must have  distinct
associated value.  EAGAIN and EWOULDBLOCK are one of the few
exceptions: POSIX permits, but does not require, that these error
constants have the same value.  On most systems they of course do have
the same value.  HP-UX is the most notable exception.

> This is really going to suck, it looks like a lot of the locking
> primitives used EAGAIN and EWOULDBLOCK interchangeably...  The fcntl
> manpage says 'EAGAIN or EWOULDBLOCK'

Whoa -- that text in fcntl(2) relates to non-blocking I/O -- not file locking.
(There is a different mess for fcntl() file locking: if a non-blocking
log request is made (F_SETLK), then the call fails with the error
EACCES of EAGAIN -- POSIX explicitly allows this since there was
historical variation across systems.)

> so is flock(2) the only problem
> here? From a quick glance at posix, fcntl(2) returning EAGAIN is
> correct.

Returning EAGIN is correct, but returning EACCES is also permitted, as
noted above.

> My guess is, I'll be able to sort this out with a simple

Maybe.  I suppose that it depends on what (broken) userland apps expect.

Cheers,

Michael

> diff --git a/arch/parisc/kernel/sys_parisc.c
> b/arch/parisc/kernel/sys_parisc.c
> index 71b3195..18e8542 100644
> --- a/arch/parisc/kernel/sys_parisc.c
> +++ b/arch/parisc/kernel/sys_parisc.c
> @@ -156,6 +156,17 @@ asmlinkage unsigned long sys_mmap(unsigned long addr,
> unsigned long len,
>
>  /* Fucking broken ABI */
>
> +asmlinkage long parisc_flock(unsigned int fd, unsigned int cmd)
> +{
> +	long ret;
> +
> +	ret = sys_flock(fd, cmd);
> +	if (ret == -EAGAIN)
> +		ret = -EWOULDBLOCK;	/* fuck you HPUX */
> +
> +	return ret;
> +}
> +
>  #ifdef CONFIG_64BIT
>  asmlinkage long parisc_truncate64(const char __user * path,
>  					unsigned int high, unsigned int low)
> diff --git a/arch/parisc/kernel/syscall_table.S
> b/arch/parisc/kernel/syscall_table.S
> index 303d2b6..8c62951 100644
> --- a/arch/parisc/kernel/syscall_table.S
> +++ b/arch/parisc/kernel/syscall_table.S
> @@ -226,7 +226,7 @@
>  	/* it is POSSIBLE that select will be OK because even though fd_set
>  	 * contains longs, the macros and sizes are clever. */
>  	ENTRY_COMP(select)
> -	ENTRY_SAME(flock)
> +	ENTRY_OURS(flock)
>  	ENTRY_SAME(msync)
>  	/* struct iovec contains pointers */
>  	ENTRY_COMP(readv)		/* 145 */
>
> but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
> is going to reveal latent problems in this part of the kernel I would
> rather not delve into...
>
> cheers, Kyle
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: flock, FAGAIN, and FWOULDBLOCK

[Kyle McMartin]

On Mon, Feb 23, 2009 at 04:20:53PM +1300, Michael Kerrisk wrote:
> * POSIX has no specification of flock() (only fcntl() locking is
> specified by POSIX.1).
> 

*nod* My mistake.

> * My understanding is that EAGAIN originated on System V, and was the
> error returned instead of blocking for system calls performing I/O,
> semaphore operations, message queue operations, and (fcntl()) file
> locking.  EWOULDBLOCK originated on BSD, and was returned by (flock())
> file locking and socket-related system calls.
> 
> * flock() is a BSDism, and the associated error was EWOULDBLOCK.
> 
> * Generally POSIX requires that each error name must have  distinct
> associated value.  EAGAIN and EWOULDBLOCK are one of the few
> exceptions: POSIX permits, but does not require, that these error
> constants have the same value.  On most systems they of course do have
> the same value.  HP-UX is the most notable exception.
> 

You appear to be be quite correct, I would imagine this is 'hysterical
raisins.' Helpfully FreeBSD seems to have ancient BSD manpages on
their cgi search page, which seems to confirm this ancestry.

> > This is really going to suck, it looks like a lot of the locking
> > primitives used EAGAIN and EWOULDBLOCK interchangeably...  The fcntl
> > manpage says 'EAGAIN or EWOULDBLOCK'
> 
> Whoa -- that text in fcntl(2) relates to non-blocking I/O -- not file locking.
> (There is a different mess for fcntl() file locking: if a non-blocking
> log request is made (F_SETLK), then the call fails with the error
> EACCES of EAGAIN -- POSIX explicitly allows this since there was
> historical variation across systems.)
> 

*nod* the perils of relying solely on grep without context. :/

> > so is flock(2) the only problem
> > here? From a quick glance at posix, fcntl(2) returning EAGAIN is
> > correct.
> 
> Returning EAGIN is correct, but returning EACCES is also permitted, as
> noted above.
> 
> > My guess is, I'll be able to sort this out with a simple
> 
> Maybe.  I suppose that it depends on what (broken) userland apps expect.
> 

Yeah, hopefully I can just paper over flock and pretend the issue
doesn't exist. :/

Thanks for clarifying, Michael. I really appreciate you taking the time.

regards, Kyle

> Cheers,
> 
> Michael
> 
> > diff --git a/arch/parisc/kernel/sys_parisc.c
> > b/arch/parisc/kernel/sys_parisc.c
> > index 71b3195..18e8542 100644
> > --- a/arch/parisc/kernel/sys_parisc.c
> > +++ b/arch/parisc/kernel/sys_parisc.c
> > @@ -156,6 +156,17 @@ asmlinkage unsigned long sys_mmap(unsigned long addr,
> > unsigned long len,
> >
> >  /* Fucking broken ABI */
> >
> > +asmlinkage long parisc_flock(unsigned int fd, unsigned int cmd)
> > +{
> > +	long ret;
> > +
> > +	ret = sys_flock(fd, cmd);
> > +	if (ret == -EAGAIN)
> > +		ret = -EWOULDBLOCK;	/* fuck you HPUX */
> > +
> > +	return ret;
> > +}
> > +
> >  #ifdef CONFIG_64BIT
> >  asmlinkage long parisc_truncate64(const char __user * path,
> >  					unsigned int high, unsigned int low)
> > diff --git a/arch/parisc/kernel/syscall_table.S
> > b/arch/parisc/kernel/syscall_table.S
> > index 303d2b6..8c62951 100644
> > --- a/arch/parisc/kernel/syscall_table.S
> > +++ b/arch/parisc/kernel/syscall_table.S
> > @@ -226,7 +226,7 @@
> >  	/* it is POSSIBLE that select will be OK because even though fd_set
> >  	 * contains longs, the macros and sizes are clever. */
> >  	ENTRY_COMP(select)
> > -	ENTRY_SAME(flock)
> > +	ENTRY_OURS(flock)
> >  	ENTRY_SAME(msync)
> >  	/* struct iovec contains pointers */
> >  	ENTRY_COMP(readv)		/* 145 */
> >
> > but somehow I suspect this interchangeable use of EAGAIN and EWOULDBLOCK
> > is going to reveal latent problems in this part of the kernel I would
> > rather not delve into...
> >
> > cheers, Kyle
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> -- 
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
> man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
> Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: flock, FAGAIN, and FWOULDBLOCK

[Michael Kerrisk]

On 2/23/09, Kyle McMartin <kyle@infradead.org> wrote:
> On Mon, Feb 23, 2009 at 04:20:53PM +1300, Michael Kerrisk wrote:
>> * POSIX has no specification of flock() (only fcntl() locking is
>> specified by POSIX.1).
>>
>
> *nod* My mistake.
>
>> * My understanding is that EAGAIN originated on System V, and was the
>> error returned instead of blocking for system calls performing I/O,
>> semaphore operations, message queue operations, and (fcntl()) file
>> locking.  EWOULDBLOCK originated on BSD, and was returned by (flock())
>> file locking and socket-related system calls.
>>
>> * flock() is a BSDism, and the associated error was EWOULDBLOCK.
>>
>> * Generally POSIX requires that each error name must have  distinct
>> associated value.  EAGAIN and EWOULDBLOCK are one of the few
>> exceptions: POSIX permits, but does not require, that these error
>> constants have the same value.  On most systems they of course do have
>> the same value.  HP-UX is the most notable exception.
>>
>
> You appear to be be quite correct, I would imagine this is 'hysterical
> raisins.'

I suspect it comes from HP-UX's history of trying to ride two horses
(BSD and System V) in the days before standards had something to say
about it all, but that's just a guess on my part.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: flock, FAGAIN, and FWOULDBLOCK

[Geert Uytterhoeven]

On Mon, Feb 23, 2009 at 04:20, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> * Generally POSIX requires that each error name must have  distinct
> associated value.  EAGAIN and EWOULDBLOCK are one of the few
> exceptions: POSIX permits, but does not require, that these error
> constants have the same value.  On most systems they of course do have
> the same value.  HP-UX is the most notable exception.

And VxWorks (which is probably used more than HP-UX).

Causes interesting compiler problems when porting code from VxWorks to
Linux that has

     case -EGAIN:
     case -EWOULDBLOCK:

Oops, duplicate case value...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds