Thread (1 message) 1 message, 1 author, 2015-11-18

Re: Add a SOCK_DESTROY operation to close sockets from userspace

From: Erik Kline <hidden>
Date: 2015-11-18 03:36:54

On 18 November 2015 at 12:34, Erik Kline [off-list ref] wrote:

On 18 November 2015 at 12:27, Stephen Hemminger [off-list ref]
wrote:
quoted
On Wed, 18 Nov 2015 10:43:40 +0900
Lorenzo Colitti [off-list ref] wrote:
quoted
This patch series adds the ability for a privileged process to
destroy sockets belonging to other userspace processes via the
sock_diag interface, and implements that for TCP sockets.

This functionality is needed on laptops and mobile hosts to
ensure that network switches / disconnects do not result in
applications being blocked for long periods of time (minutes) in
read or connect calls on TCP sockets that will never succeed
because the IP address they are bound to is gone. Closing the
sockets in the protocol layer causes these calls to fail fast and
allows applications to reconnect on another network.

For many years Android kernels have done this via an out-of-tree
SIOCKILLADDR ioctl that is called when networks disconnect, but
this solution is cleaner, more robust and more flexible. The
system can iterate over all connections on the deleted IP address
and close all of them. But it can also close all sockets opened
by a given process on a given network, for example if the user
has restricted that process from using that network, or if a
secure network such as a VPN is now being applied to the
application and thus previously-established connections are
blackholed.

The patch series only implements SOCK_DESTROY for TCP sockets,
but the mechanism can be extended to any protocol family that
supports the sock_diag interface.
I understand why you might want this, but it smells like the same
kind of problems that the "forced unmount" patch had which eventually
led to it not being accepted in mainline.  Lots of corner
cases and race conditions waiting to blow up.

Look at the issues that the multi-thread socket close has.
This looks worse.

I'm unsure of the specific issue to which you refer with "multi-thread
socket close".  This is basically just a user-space forced tcp_close(),
leaving the file descriptor still valid in the user context for the
application to manage (alternatively: it aims to be the same as if a
correctly crafted TCP RST had arrived).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help