netdev - Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8761n07gxy.fsf@sable.mobileactivedefense.com>
Date:	Wed, 26 Mar 2014 22:06:49 +0000
From:	Rainer Weikusat <rweikusat@...ileactivedefense.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, David.Laight@...LAB.COM,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

Eric Dumazet <eric.dumazet@...il.com> writes:
> On Wed, 2014-03-26 at 21:21 +0000, Rainer Weikusat wrote:
>> BTW, here's the program with the O_NONBLOCK read call which blocks until
>> the end of electricity, at least on 3.2.9:
>> 
>> ---------
>> #include <fcntl.h>
>> #include <string.h>
>> #include <sys/socket.h>
>> #include <sys/un.h>
>> 
>> int main(void)
>> {
>>     struct sockaddr_un sun;
>>     int fd;
>> 
>>     fd = socket(AF_UNIX, SOCK_DGRAM, 0);
>>     sun.sun_family = AF_UNIX;
>>     strncpy(sun.sun_path, "/tmp/bla", sizeof(sun.sun_path));
>>     bind(fd, (struct sockaddr *)&sun, sizeof(sun));
>> 
>>     if (fork() == 0) read(fd, &fd, sizeof(fd));
>> 
>>     sleep(1);
>> 
>>     fcntl(fd, F_SETFL, O_NONBLOCK);
>>     read(fd, &fd, sizeof(fd));
>> 
>>     return 0;
>> }
>
> Sure, O_NONBLOCK is translated into MSG_NOWAIT one time per socket
> syscall. 
>
> Once we block, we don't automatically unblock if another thread change
> the file flag.

That would be a seriously bizarre idea. The thread of execution which
does the supposed-to-be-non-blocking call shouldn't become blocked for
an indefinite time. Which means it should not wait indefinitely for a
thread which - in turn - waits indefinitely for an external event (and
hence, the original problem should never have existed to begin with as
there would neither be an opportunity nor a reason to interrupt in the
non-blocking case).

BTW, while these are things which are of some interest to me (even of
some professional interest), I don't exactly get paid for these kind of
discussions, have some real work to do, and the way people interact on
LKML is seriously more aggressive then I can stand for a prolonged time,
so can we please end this discussion here while it - if only for a
change - hasn't yet degraded into an all out mutual extermination fight?

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html