From: Sergei Trofimovich <slyfox@gentoo.org>
To: sparclinux@vger.kernel.org
Subject: sparc vs sparc64: O_NDELAY and O_NONBLOCK mismatch in kernel and in glibc
Date: Fri, 29 May 2020 09:40:19 +0000 [thread overview]
Message-ID: <20200529104019.72983ef9@sf> (raw)
On most targets glibc defines O_NDELAY as O_NONBLOCK.
glibc's manual/llio.texi manual says they are supposed to be equal:
"""
@deftypevr Macro int O_NDELAY
@standards{BSD, fcntl.h}
This is an obsolete name for @code{O_NONBLOCK}, provided for
compatibility with BSD. It is not defined by the POSIX.1 standard.
@end deftypevr
"""
A bunch of packages rely on it and find out that this assumption
breaks on sparc in unusual ways. Recently it popped up as:
https://github.com/eventlet/eventlet/pull/615
Older workarounds:
https://github.com/libuv/libuv/issues/1830
What is more confusing for me:
linux kernel's uapi definition of O_NDELAY is ABI-dependent:
arch/sparc/include/uapi/asm/fcntl.h
"""
#if defined(__sparc__) && defined(__arch64__)
#define O_NDELAY 0x0004
#else
#define O_NDELAY (0x0004 | O_NONBLOCK)
#endif
"""
while glibc's is not:
sysdeps/unix/sysv/linux/sparc/bits/fcntl.h
"""
#define O_NONBLOCK 0x4000
#define O_NDELAY (0x0004 | O_NONBLOCK)
"""
Spot-checking preprocessor's output that seems to corroborate:
"""
$ printf "#include <sys/fcntl.h>'\n int o_ndelay = O_NDELAY; int o_nonblock = O_NONBLOCK;" | sparc-unknown-linux-gnu-gcc -E -x c - | fgrep -A3 o_
int o_ndelay (0x0004 | 0x4000)
; int o_nonblock 0x4000
$ printf "#include <sys/fcntl.h>'\n int o_ndelay = O_NDELAY; int o_nonblock = O_NONBLOCK;" | sparc64-unknown-linux-gnu-gcc -E -x c - | fgrep -A3 o_
int o_ndelay (0x0004 | 0x4000)
; int o_nonblock 0x4000
"""
I think this skew causes strange effects when you run sparc32
binary on sparc64 kernel (compared to sparc32 binary on sparc32
kernel) as kernel disagrees with userspace on O_NDELAY definition.
https://github.com/libuv/libuv/issues/1830 has more details.
I tried to trace the O_NDELAY definition and stopped at linux-2.1.29:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/include/asm-sparc/fcntl.h?id·b4d2d2c1809575374269e14d86ee1953bd168c
which brought O_NDELAY to O_NONBLOCK but did not make them
match exactly.
Question time:
1. Why is sparc32 special? Does it have something to do with
compatibility to other OSes of that time? (Solaris? BSD?)
fs/fcntl.c has kernel handling:
/* required for strict SunOS emulation */
if (O_NONBLOCK != O_NDELAY)
if (arg & O_NDELAY)
arg |= O_NONBLOCK;
but why does it leak to to userspace header definition?
I think it should not.
2. Should sparc64-glibc change it's definition? Say, from
#define O_NDELAY (0x0004 | O_NONBLOCK)
to
#define O_NDELAY O_NONBLOCK
I think it should.
3. Should sparc32-linux (and glibc) change it's definition? Say, from
#if defined(__sparc__) && defined(__arch64__)
#define O_NDELAY 0x0004
#else
#define O_NDELAY (0x0004 | O_NONBLOCK)
#endif
to
#define O_NDELAY (0x0004 | O_NONBLOCK)
or even to
#define O_NDELAY O_NONBLOCK
and make sure kernel maps old O_NDELAY to O_NONBLOCK?
I think '#define O_NDELAY O_NONBLOCK' would be most
consistent.
What do you think?
Thanks!
--
Sergei
next reply other threads:[~2020-05-29 9:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 9:40 Sergei Trofimovich [this message]
2020-05-29 10:48 ` sparc vs sparc64: O_NDELAY and O_NONBLOCK mismatch in kernel and in glibc John Paul Adrian Glaubitz
2020-06-22 19:08 ` Adhemerval Zanella
-- strict thread matches above, loose matches on Subject: below --
2020-08-11 23:42 David Miller
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=20200529104019.72983ef9@sf \
--to=slyfox@gentoo.org \
--cc=sparclinux@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.