netdev - Expected behavior of shutdown() in multi-threaded socket programming

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-next>] [day] [month] [year] [list]

Message-ID: <35c90d960905191429x1c3b6104qca2a672d50f0364c@mail.gmail.com>
Date:	Tue, 19 May 2009 14:29:57 -0700
From:	Nick Pelly <npelly@...gle.com>
To:	linux-bluetooth@...r.kernel.org, netdev@...r.kernel.org,
	davem@...hat.com
Subject: Expected behavior of shutdown() in multi-threaded socket programming

Hi,

I am interested in the expected behavior of shutdown() on a socket
that is also blocked on connect(), accept(), read(), write(), poll()
or select() in another thread.

For example:

THREAD 1
fd = socket()
listen(fd)
bind(fd)
accept(fd)  <--- blocks

THREAD 2
shutdown(fd)  <--- what is meant to happen to accept() in thread 1?

If thread 2 is run after thread 1, what should happen to the blocked
accept() call when shutdown() is called in thread 2?

My observations are that
TCP sockets: accept() immediately returns with errno EINVAL
unix domain sockets: accept() immediately returns with return errno EINVAL
RFCOMM sockets: accept() continues to block
L2CAP sockets: accept() continues to block

I tested on 2.6.18, 2.6.28 and 2.6.29 and results were the same.

Included is a sample program sock_shutdown_test.c that can easily
exhibit this behavior. For example
sock_shutdown_test unix accept_shutdown  # accept() returns
sock_shutdown_test tcp accept_shutdown   # accept() returns
sock_shutdown_test rfcomm accept_shutdown   # accept() blocks forever
sock_shutdown_test l2cap accept_shutdown   # accept() blocks forever

I also have similar results for other blocking syscalls such as
connect(), read(), write(), poll() etc, but the test program is not as
simple.

So my question is: What is the correct behavior for sockets here?

It is desirable for Android that shutdown() to force other threads
blocked on that socket to return. In fact, if they don't it makes
multi-threaded socket programming very hard since there is no other
simple way to abort a blocked I/O operation. We have to resort to
using poll() in combination with a selfpipe that we can write a byte
to in order to abort the poll(). But this is quite inefficient as it
triples the number of fd's needed for every socket not to mention the
4k buffer space needed in the kernel for the selfpipe. A global
selfpipe per process is an improvement but it is quite messy getting
this correct without race conditions.

Input as to the correct behavior is appreciated,
Nick

View attachment "sock_shutdown_test.c" of type "text/x-csrc" (6870 bytes)