> No, I mean something that kills connections where previously this did > not happen. The fact that this is done at the process level does not > justify that it is a right to at do connections. Besides, if you > really intend to do this then provide a privileged process a means to > close *any* open file descriptor in the system (why stop at TCP > sockets)!
There is little reason to be able to kill random processes arbitrary file descriptors, while there is ample reason to be able to kill network connections. Network connections can already (and often are) be killed by the network, but that's far less true for files (although IO errors and emergency fs remount r/o can cause similar behaviour). Userspace doesn't expect file descriptors to local files to suddenly break, while it already has to handle network connections timing out and the like. Perhaps we shouldn't be using the word 'kill'. We're not really killing these sockets, nor closing them, we just need an out-of-band mechanism for flagging them with some sort of error (ie. force timing them out, or force resetting them). That said, one can certainly come up with cases where killing arbitrary file descriptors would make sense (or more likely switching them from r/w to r/o mode or replacing them with some sort of /dev/null like file descriptor instead). Example use cases would be umounting a removable usb key which is in the process of being pulled out of the machine (or was already pulled out), or remounting a file system readonly (which still has r/w open files). -- 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
