> What I object to is userspace making reachability decisions, not > whether SOCK_DESTROY closes the socket in one way or the other.
Privileged userspace can already make these decisions today, whether it is by killing processes with open sockets, or by turning interfaces up and down or by reconfiguring the firewall and/or the routing rules/tables, or by injecting spoofed TCP reset packets (via tap). It's just *very* inconvenient to do and error prone. Another example: privileged userspace could ptrace the userspace apps and via code injection call close() on the app's behalf and reopen the file descriptor to some null routed destination so it behaves like if it was timed out / unreachable. In general the statement that (appropriately privileged) 'userspace should not be able to do something' is wrong - about the only exception I can think of being crashing the machine or burning the hardware. The kernel's purpose in life should be to enable userspace to do things. You make things too hard for people to do stuff via the kernel and you end up with the kernel being out of a job. People either implement things entirely in userspace (userspace tcp stacks on raw sockets or tap or udp) or switch to a different kernel or create a local fork... I'm not saying the proposed solution is ideal (although honestly it doesn't seem bad), but this problem does deserve a clean *kernel* solution instead of insane userspace hacks or non vanilla Linux patches which then propagate to a billion devices... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
