Make EWOULDBLOCK be equal to EAGAIN on parisc.
diff mbox

Message ID 7b86ec9f26dd9a18e7fae7a39e6a3382@tuxicoman.be
State Accepted, archived
Headers show

Commit Message

Guy Martin Jan. 16, 2014, 4:17 p.m. UTC
On Linux, only parisc uses a different value for EWOULDBLOCK which
causes a lot of troubles for applications not checking for both values.
Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
all other architectures.

Signed-off-by: Guy Martin  <gmsoft@tuxicoman.be>
---
  arch/parisc/include/uapi/asm/errno.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

  #define	ENAMETOOLONG	248	/* File name too long */
  #define	ELOOP		249	/* Too many symbolic links encountered */

Comments

Carlos O'Donell Jan. 16, 2014, 8:02 p.m. UTC | #1
On Thu, Jan 16, 2014 at 11:17 AM, Guy Martin <gmsoft@tuxicoman.be> wrote:
> On Linux, only parisc uses a different value for EWOULDBLOCK which
> causes a lot of troubles for applications not checking for both values.
> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
> all other architectures.
>
> Signed-off-by: Guy Martin  <gmsoft@tuxicoman.be>
> ---
>  arch/parisc/include/uapi/asm/errno.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/parisc/include/uapi/asm/errno.h
> b/arch/parisc/include/uapi/asm/errno.h
> index f3a8aa5..c0ae625 100644
> --- a/arch/parisc/include/uapi/asm/errno.h
> +++ b/arch/parisc/include/uapi/asm/errno.h
> @@ -106,7 +106,7 @@
>
>  #define        EALREADY        244     /* Operation already in progress */
>  #define        EINPROGRESS     245     /* Operation now in progress */
> -#define        EWOULDBLOCK     246     /* Operation would block (Linux
> returns EAGAIN) */
> +#define        EWOULDBLOCK     EAGAIN  /* Operation would block (Not HPUX
> compliant) */
>  #define        ENOTEMPTY       247     /* Directory not empty */
>  #define        ENAMETOOLONG    248     /* File name too long */
>  #define        ELOOP           249     /* Too many symbolic links
> encountered */

This is an ABI break.

You can't do this without rebuilding userspace.

You need debian an gentoo onboard to do this ABI break.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
John David Anglin Jan. 16, 2014, 8:49 p.m. UTC | #2
On 1/16/2014 3:02 PM, Carlos O'Donell wrote:
> On Thu, Jan 16, 2014 at 11:17 AM, Guy Martin <gmsoft@tuxicoman.be> wrote:
>> On Linux, only parisc uses a different value for EWOULDBLOCK which
>> causes a lot of troubles for applications not checking for both values.
>> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
>> all other architectures.
>>
>> Signed-off-by: Guy Martin  <gmsoft@tuxicoman.be>
>> ---
>>   arch/parisc/include/uapi/asm/errno.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/parisc/include/uapi/asm/errno.h
>> b/arch/parisc/include/uapi/asm/errno.h
>> index f3a8aa5..c0ae625 100644
>> --- a/arch/parisc/include/uapi/asm/errno.h
>> +++ b/arch/parisc/include/uapi/asm/errno.h
>> @@ -106,7 +106,7 @@
>>
>>   #define        EALREADY        244     /* Operation already in progress */
>>   #define        EINPROGRESS     245     /* Operation now in progress */
>> -#define        EWOULDBLOCK     246     /* Operation would block (Linux
>> returns EAGAIN) */
>> +#define        EWOULDBLOCK     EAGAIN  /* Operation would block (Not HPUX
>> compliant) */
>>   #define        ENOTEMPTY       247     /* Directory not empty */
>>   #define        ENAMETOOLONG    248     /* File name too long */
>>   #define        ELOOP           249     /* Too many symbolic links
>> encountered */
> This is an ABI break.
>
> You can't do this without rebuilding userspace.
>
> You need debian an gentoo onboard to do this ABI break.
This would take about a month on Debian, so I'm against.  Various bits 
of kernel code traditionally
return EWOULDBLOCK, so any application code that just checks EWOULDBLOCK 
would fail.

Dave
Carlos O'Donell Jan. 16, 2014, 9:05 p.m. UTC | #3
On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin <dave.anglin@bell.net> wrote:
>> This is an ABI break.
>>
>> You can't do this without rebuilding userspace.
>>
>> You need debian an gentoo onboard to do this ABI break.
>
> This would take about a month on Debian, so I'm against.  Various bits of kernel code traditionally
> return EWOULDBLOCK, so any application code that just checks EWOULDBLOCK would fail.

That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's
only true on hppa, and that's the problem.

The kernel is completely inconsistent about returning EWOULDBLOCK or
EAGAIN, and the standards do dictate one or the other so the kernel
and glibc are correct to use one or the other to match the standard.

However, user applications are equally sloppy about checking the right value.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Jan. 16, 2014, 9:15 p.m. UTC | #4
On 01/16/2014 10:05 PM, Carlos O'Donell wrote:
> On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin <dave.anglin@bell.net> wrote:
>>> This is an ABI break.
>>>
>>> You can't do this without rebuilding userspace.
>>>
>>> You need debian an gentoo onboard to do this ABI break.
>>
>> This would take about a month on Debian, so I'm against.  Various bits of kernel code traditionally
>> return EWOULDBLOCK, so any application code that just checks EWOULDBLOCK would fail.
> 
> That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's
> only true on hppa, and that's the problem.
> 
> The kernel is completely inconsistent about returning EWOULDBLOCK or
> EAGAIN, and the standards do dictate one or the other so the kernel
> and glibc are correct to use one or the other to match the standard.
> 
> However, user applications are equally sloppy about checking the right value.

Guy, do you have actual programs which are currently broken and which don't check for both?
My feeling is, that most programs were fixed, but I might be wrong...

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mike Frysinger Jan. 16, 2014, 10:43 p.m. UTC | #5
On Thursday 16 January 2014 16:15:33 Helge Deller wrote:
> On 01/16/2014 10:05 PM, Carlos O'Donell wrote:
> > On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin wrote:
> >>> This is an ABI break.
> >>> 
> >>> You can't do this without rebuilding userspace.
> >>> 
> >>> You need debian an gentoo onboard to do this ABI break.
> >> 
> >> This would take about a month on Debian, so I'm against.  Various bits
> >> of kernel code traditionally return EWOULDBLOCK, so any application
> >> code that just checks EWOULDBLOCK would fail.
> > 
> > That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's
> > only true on hppa, and that's the problem.
> > 
> > The kernel is completely inconsistent about returning EWOULDBLOCK or
> > EAGAIN, and the standards do dictate one or the other so the kernel
> > and glibc are correct to use one or the other to match the standard.
> > 
> > However, user applications are equally sloppy about checking the right
> > value.
> 
> Guy, do you have actual programs which are currently broken and which don't
> check for both? My feeling is, that most programs were fixed, but I might
> be wrong...

my guess is memcached:
https://bugs.gentoo.org/show_bug.cgi?id=498262
-mike
Guy Martin Jan. 17, 2014, 8:55 a.m. UTC | #6
On 2014-01-16 22:15, Helge Deller wrote:
> On 01/16/2014 10:05 PM, Carlos O'Donell wrote:
>> On Thu, Jan 16, 2014 at 3:49 PM, John David Anglin 
>> <dave.anglin@bell.net> wrote:
>>>> This is an ABI break.
>>>> 
>>>> You can't do this without rebuilding userspace.
>>>> 
>>>> You need debian an gentoo onboard to do this ABI break.
>>> 
>>> This would take about a month on Debian, so I'm against.  Various 
>>> bits of kernel code traditionally
>>> return EWOULDBLOCK, so any application code that just checks 
>>> EWOULDBLOCK would fail.
>> 
>> That's not true if, like all other targets, EWOULDBLOCK == AGAIN. It's
>> only true on hppa, and that's the problem.
>> 
>> The kernel is completely inconsistent about returning EWOULDBLOCK or
>> EAGAIN, and the standards do dictate one or the other so the kernel
>> and glibc are correct to use one or the other to match the standard.
>> 
>> However, user applications are equally sloppy about checking the right 
>> value.
> 
> Guy, do you have actual programs which are currently broken and which
> don't check for both?
> My feeling is, that most programs were fixed, but I might be wrong...

As Mike pointed out, memcached had a test which failed only on hppa.
Fixing the test is easy but that lead me to check the code of 
libmemcache,
client counterpart of memcached. The same problem was there too. Only
EAGAIN was being checked.

I agree that this change will break the ABI. However it will only affect
applications checking solely for EWOULDBLOCK and not EAGAIN. I believe 
that
on linux, most if not all applications check for EAGAIN and few check 
for
EWOULDBLOCK as well.

The problem currently is that finding out which applications are not 
checking
for EWOULDBLOCK requires analyzing the code. Most of the time, failure 
to
correctly check for EWOULDBLOCK will be quite stealth depending on how 
the
application handles it.

So despite the fact that this will break the ABI, the breakage should be 
minimal
if non existent while it will fix a lot of hard to find and identify 
issues.

   Guy


--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
John David Anglin Jan. 17, 2014, 2:01 p.m. UTC | #7
On 17-Jan-14, at 3:55 AM, Guy Martin wrote:

> So despite the fact that this will break the ABI, the breakage  
> should be minimal
> if non existent while it will fix a lot of hard to find and identify  
> issues.

Have you tested the change?

Dave
--
John David Anglin	dave.anglin@bell.net



--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Carlos O'Donell Jan. 17, 2014, 2:08 p.m. UTC | #8
On Fri, Jan 17, 2014 at 9:01 AM, John David Anglin <dave.anglin@bell.net> wrote:
>
> On 17-Jan-14, at 3:55 AM, Guy Martin wrote:
>
>> So despite the fact that this will break the ABI, the breakage should be minimal
>> if non existent while it will fix a lot of hard to find and identify issues.
>
>
> Have you tested the change?

This is a good point.

If you can make this change and still boot your system with a rebuilt
kernel, then there is hope that your claims are true.

The basic argument would be:
* Change kernel header to make EWOULDBLOCK == AGAIN.
* Rebuild kernel.
* Boot system.
* Verify system is semifunctional, networking, IO, disk, XVnc, etc.

That would go a long way to showing that most of the system works.

Then if you emerge the world against those changed headers and it goes
well, then we might be talking about it being a low-impact change.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Guy Martin Jan. 17, 2014, 3:11 p.m. UTC | #9
On 2014-01-17 15:08, Carlos O'Donell wrote:
> On Fri, Jan 17, 2014 at 9:01 AM, John David Anglin 
> <dave.anglin@bell.net> wrote:
>> 
>> On 17-Jan-14, at 3:55 AM, Guy Martin wrote:
>> 
>>> So despite the fact that this will break the ABI, the breakage should 
>>> be minimal
>>> if non existent while it will fix a lot of hard to find and identify 
>>> issues.
>> 
>> 
>> Have you tested the change?
> 
> This is a good point.
> 
> If you can make this change and still boot your system with a rebuilt
> kernel, then there is hope that your claims are true.
> 
> The basic argument would be:
> * Change kernel header to make EWOULDBLOCK == AGAIN.
> * Rebuild kernel.
> * Boot system.
> * Verify system is semifunctional, networking, IO, disk, XVnc, etc.
> 
> That would go a long way to showing that most of the system works.
> 
> Then if you emerge the world against those changed headers and it goes
> well, then we might be talking about it being a low-impact change.
> 

I've rebuilt the kernel with the change and I can't see any impact.
NFS/SSH works fine and upgrading a few packages doesn't show any issue.
I don't have X on that box.


   Guy

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Jan. 17, 2014, 10:27 p.m. UTC | #10
On 01/17/2014 04:11 PM, Guy Martin wrote:
> On 2014-01-17 15:08, Carlos O'Donell wrote:
>> On Fri, Jan 17, 2014 at 9:01 AM, John David Anglin
>> <dave.anglin@bell.net> wrote:
>>> 
>>> On 17-Jan-14, at 3:55 AM, Guy Martin wrote:
>>> 
>>>> So despite the fact that this will break the ABI, the breakage
>>>> should be minimal if non existent while it will fix a lot of
>>>> hard to find and identify issues.
>>> 
>>> 
>>> Have you tested the change?
>> 
>> This is a good point.
>> 
>> If you can make this change and still boot your system with a
>> rebuilt kernel, then there is hope that your claims are true.
>> 
>> The basic argument would be: * Change kernel header to make
>> EWOULDBLOCK == AGAIN. * Rebuild kernel. * Boot system. * Verify
>> system is semifunctional, networking, IO, disk, XVnc, etc.
>> 
>> That would go a long way to showing that most of the system works.
>> 
>> Then if you emerge the world against those changed headers and it
>> goes well, then we might be talking about it being a low-impact
>> change.
>> 
> 
> I've rebuilt the kernel with the change and I can't see any impact. 
> NFS/SSH works fine and upgrading a few packages doesn't show any
> issue. I don't have X on that box.


Just a comment:
If we do an ABI break, we maybe should take other topics into account at the same time as well, e.g.
- increasing number of signals for systemd
- dropping some HP-UX signals
- maybe something needed to better support 64bit userspace ?
- ...

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Jan. 31, 2014, 4:53 p.m. UTC | #11
On 01/16/2014 05:17 PM, Guy Martin wrote:
> On Linux, only parisc uses a different value for EWOULDBLOCK which
> causes a lot of troubles for applications not checking for both values.
> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
> all other architectures.
> 
> Signed-off-by: Guy Martin  <gmsoft@tuxicoman.be>

What's our final decision regarding this patch now?
Shall we target it for inclusion into 3.14 ?
If yes, I can include it with my next push request...

Please speak up now...!

Helge

> ---
>  arch/parisc/include/uapi/asm/errno.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/parisc/include/uapi/asm/errno.h b/arch/parisc/include/uapi/asm/errno.h
> index f3a8aa5..c0ae625 100644
> --- a/arch/parisc/include/uapi/asm/errno.h
> +++ b/arch/parisc/include/uapi/asm/errno.h
> @@ -106,7 +106,7 @@
> 
>  #define    EALREADY    244    /* Operation already in progress */
>  #define    EINPROGRESS    245    /* Operation now in progress */
> -#define    EWOULDBLOCK    246    /* Operation would block (Linux returns EAGAIN) */
> +#define    EWOULDBLOCK    EAGAIN    /* Operation would block (Not HPUX compliant) */
>  #define    ENOTEMPTY    247    /* Directory not empty */
>  #define    ENAMETOOLONG    248    /* File name too long */
>  #define    ELOOP        249    /* Too many symbolic links encountered */

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Carlos O'Donell Jan. 31, 2014, 5:24 p.m. UTC | #12
On Fri, Jan 31, 2014 at 11:53 AM, Helge Deller <deller@gmx.de> wrote:
> On 01/16/2014 05:17 PM, Guy Martin wrote:
>> On Linux, only parisc uses a different value for EWOULDBLOCK which
>> causes a lot of troubles for applications not checking for both values.
>> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
>> all other architectures.
>>
>> Signed-off-by: Guy Martin  <gmsoft@tuxicoman.be>
>
> What's our final decision regarding this patch now?
> Shall we target it for inclusion into 3.14 ?
> If yes, I can include it with my next push request...
>
> Please speak up now...!
>
> Helge
>
>> ---
>>  arch/parisc/include/uapi/asm/errno.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/parisc/include/uapi/asm/errno.h b/arch/parisc/include/uapi/asm/errno.h
>> index f3a8aa5..c0ae625 100644
>> --- a/arch/parisc/include/uapi/asm/errno.h
>> +++ b/arch/parisc/include/uapi/asm/errno.h
>> @@ -106,7 +106,7 @@
>>
>>  #define    EALREADY    244    /* Operation already in progress */
>>  #define    EINPROGRESS    245    /* Operation now in progress */
>> -#define    EWOULDBLOCK    246    /* Operation would block (Linux returns EAGAIN) */
>> +#define    EWOULDBLOCK    EAGAIN    /* Operation would block (Not HPUX compliant) */
>>  #define    ENOTEMPTY    247    /* Directory not empty */
>>  #define    ENAMETOOLONG    248    /* File name too long */
>>  #define    ELOOP        249    /* Too many symbolic links encountered */

I think we should do it and fix the userspace fallout by rebuilding.

This is just like non-zero locks were in linuxthreads, a pain and
constant source of bugs.

I'll fixup glibc.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mike Frysinger Jan. 31, 2014, 11:16 p.m. UTC | #13
On Friday, January 31, 2014 12:24:10 Carlos O'Donell wrote:
> On Fri, Jan 31, 2014 at 11:53 AM, Helge Deller <deller@gmx.de> wrote:
> > On 01/16/2014 05:17 PM, Guy Martin wrote:
> >> On Linux, only parisc uses a different value for EWOULDBLOCK which
> >> causes a lot of troubles for applications not checking for both values.
> >> Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
> >> all other architectures.
> >> 
> >> Signed-off-by: Guy Martin  <gmsoft@tuxicoman.be>
> > 
> > What's our final decision regarding this patch now?
> > Shall we target it for inclusion into 3.14 ?
> > If yes, I can include it with my next push request...
> > 
> > Please speak up now...!
> > 
> > Helge
> > 
> >> ---
> >> 
> >>  arch/parisc/include/uapi/asm/errno.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/arch/parisc/include/uapi/asm/errno.h
> >> b/arch/parisc/include/uapi/asm/errno.h index f3a8aa5..c0ae625 100644
> >> --- a/arch/parisc/include/uapi/asm/errno.h
> >> +++ b/arch/parisc/include/uapi/asm/errno.h
> >> @@ -106,7 +106,7 @@
> >> 
> >>  #define    EALREADY    244    /* Operation already in progress */
> >>  #define    EINPROGRESS    245    /* Operation now in progress */
> >> 
> >> -#define    EWOULDBLOCK    246    /* Operation would block (Linux returns
> >> EAGAIN) */ +#define    EWOULDBLOCK    EAGAIN    /* Operation would block
> >> (Not HPUX compliant) */>> 
> >>  #define    ENOTEMPTY    247    /* Directory not empty */
> >>  #define    ENAMETOOLONG    248    /* File name too long */
> >>  #define    ELOOP        249    /* Too many symbolic links encountered */
> 
> I think we should do it and fix the userspace fallout by rebuilding.

i'm not sure userspace will break ?  we've got two classes of code:
 - stuff that checks both EAGAIN & EWOULDBLOCK and treats them the same
 - stuff that checks EAGAIN only (and probably should check both, but doesn't)
both of those will continue to work after we change EWOULDBLOCK

i don't think there's really any code out there that only looks at EWOULDBLOCK 
(or does so differently from EAGAIN).  if there is, then they'd break.  but if 
they never sh*t in the woods in the first place, then who cares if they would 
have made noise ? :)
-mike

Patch
diff mbox

diff --git a/arch/parisc/include/uapi/asm/errno.h 
b/arch/parisc/include/uapi/asm/errno.h
index f3a8aa5..c0ae625 100644
--- a/arch/parisc/include/uapi/asm/errno.h
+++ b/arch/parisc/include/uapi/asm/errno.h
@@ -106,7 +106,7 @@ 

  #define	EALREADY	244	/* Operation already in progress */
  #define	EINPROGRESS	245	/* Operation now in progress */
-#define	EWOULDBLOCK	246	/* Operation would block (Linux returns EAGAIN) 
*/
+#define	EWOULDBLOCK	EAGAIN	/* Operation would block (Not HPUX 
compliant) */
  #define	ENOTEMPTY	247	/* Directory not empty */