[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bugs in Hurd's recvmsg (msg_name AF_LOCAL, MSG_DONTWAIT)

From: Christian Seiler
Subject: Bugs in Hurd's recvmsg (msg_name AF_LOCAL, MSG_DONTWAIT)
Date: Mon, 1 Aug 2016 12:08:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0


I've now isolated the problems and have a reproducer (attached)
and it has _nothing_ to do with SCM_CREDS, but with much more
basic functionality.

Problem 1 (causing SIGLOST):

When msg_name and msg_namelen are filled for a SOCK_STREAM AF_LOCAL
socket (maybe also other AF_LOCAL, didn't check) upon calling
recvmsg, SIGLOST is generated. After reading up on this a bit, it
appears to be that Hurd doesn't have peer names for anoymous
AF_LOCAL sockets (in contrast to Linux and kFreeBSD) - but even in
that case, I would've expected errno = EINVAL and not SIGLOST, so
this is definitely a bug.

Problem 2:

MSG_DONTWAIT is ignored for recvmsg, it always blocks (at least
when using AF_LOCK sockets). I've even tried to pre-fill the
msg_flags member with it (which you shouldn't need to do
according to POSIX, the flags argument should be enough), but
that also doesn't help.

I've attached a simple reproducer:

 gcc -Wall -o hurd_recvmsg hurd_recvmsg.c
 [shell 1] ./hurd_recvmsg server
 [shell 2] ./hurd_recvmsg
    => works on Hurd

 gcc -Wall -o hurd_recvmsg hurd_recvmsg.c -DMSG_NAME
 [shell 1] ./hurd_recvmsg server
 [shell 2] ./hurd_recvmsg
    => SIGLOST on server
       (even if you don't want to support peer names in
       AF_LOCAL, I'd expect recvmsg to either ignore msg_name
       or at the very least return -EINVAL - but not cause
       the program to crash with a signal that's Hurd-specific
       and hence most programs don't catch

 gcc -Wall -o hurd_recvmsg hurd_recvmsg.c -DSECOND_RECV
 [shell 1] ./hurd_recvmsg server
 [shell 2] ./hurd_recvmsg
    => hangs on recv in server (even though MSG_DONTWAIT
       is passed to the second call)

All three variants (+ the combined variant with both defines) work
on kFreeBSD, so this is a Hurd issue.

Tricky thing is: I can easily work around Problem 1, but I don't
see any way of working around problem 2 in the code, because having
working non-blocking I/O is absolutely essential. (I also wonder
why nobody ever found this bug before? This appears to be really
easy to trigger...)

Anyway, would be great if someone could look at Bug #2 here, because
I don't see any way to work around it.

Thank you!


Attachment: hurd_recvmsg.c
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]