Re: [RFC PATCH] parisc: Define O_NONBLOCK to become 000200000

[Jeroen Roovers <jer@xs4all.nl>]

On Sat, 29 Aug 2020 14:20:17 +0200
Helge Deller <deller@gmx.de> wrote:

> HPUX has separate NDELAY & NONBLOCK values. In the past we wanted to
> be able to run HP-UX binaries natively on parisc Linux which is why
> we defined O_NONBLOCK to 000200004 to distinguish NDELAY & NONBLOCK
> bits.
> But with 2 bits set in this bitmask we often ran into compatibility
> issues with other Linux applications which often only test one bit (or
> even compare the values).
> 
> To avoid such issues in the future, this patch changes O_NONBLOCK to
> become 000200000. That way old programs will still be functional, and
> for new programs we now have only one bit set.

I am seeing a problem with this exact commit in userland, so I think
that last sentence is incorrect:

/usr/src/linux # git bisect good
75ae04206a4d0e4f541c1d692b7febd1c0fdb814 is the first bad commit
commit 75ae04206a4d0e4f541c1d692b7febd1c0fdb814
Author: Helge Deller <deller@gmx.de>
Date:   Sat Aug 29 14:11:35 2020 +0200

    parisc: Define O_NONBLOCK to become 000200000

    HPUX has separate NDELAY & NONBLOCK values. In the past we wanted to
    be able to run HP-UX binaries natively on parisc Linux which is why
    we defined O_NONBLOCK to 000200004 to distinguish NDELAY & NONBLOCK
    bits.
    But with 2 bits set in this bitmask we often ran into compatibility
    issues with other Linux applications which often only test one bit
    (or even compare the values).

    To avoid such issues in the future, this patch changes O_NONBLOCK to
    become 000200000. That way old programs will still be functional,
    and for new programs we now have only one bit set.

    Update the comment about SOCK_NONBLOCK too.

    Signed-off-by: Helge Deller <deller@gmx.de>

 arch/parisc/include/asm/socket.h     | 4 ++--
 arch/parisc/include/uapi/asm/fcntl.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)


The first sign (in the boot process) that something is wrong is that
idmapd fails to start:

 * Starting idmapd ...
 * make sure DNOTIFY support is enabled ...
 [ !! ]
 * ERROR: rpc.idmapd failed to start
 * ERROR: cannot start nfsclient as rpc.idmapd would not start

Then, elogind reports an error when I ssh in as regular user:

[  297.825133][ T4273] elogind-daemon[4273]: Failed to register SIGHUP
handler: Invalid argument
[  297.825133][ T4273] elogind-daemon[4273]: Failed to register SIGHUP
handler: Invalid argument [  298.040379][ T4273] elogind-daemon[4273]:
Failed to fully start up daemon: Invalid argument
[  298.040379][T4273] elogind-daemon[4273]: Failed to fully start up
daemon: Invalid argument

Yet the unprivileged user succeeds in logging in over SSH. Following
that, sudo fails:

jeroen@karsten ~ $ sudo -i
sudo: unable to allocate memory

root can still login on the serial console and over SSH.

Would it make sense to rebuild libc against the newer kernel headers?

Or is this an unexpected result from the above commit and would it be
useful to figure out what is going on while the bad kernel is running?


Regards,
     jer