> I actually don't have an issue with killing from user space that much. I > still recommend (and actually have started to look at it today) to add a > new substate for TCP TIMEWAIT and don't have any issue if we block the > socket for 60 seconds and send RSTs to all incoming data. This way we > can solve the problem Florian indicated as well as this problem. Users > can happily kill TCP connections then. > Neither do I have a problem with killing connections from userspace, but we do have to acknowledge that this is a powerful and invasive mechanism. I suggest:
1) We need transparency. If a third party kills a TCP connection then the application should be informed of specifically that. This seems easy enough to just pick an appropriate error number as I suggested. 2) We need constraints. This feature seems to be specific to a very narrow use case. It is not at all clear to me if there are any legitimate uses cases beyond Android, enabling this by default in the stack creates a non-zero amount of risk and liability for abuse. It seems like this should be an opt-in sort of feature, with a kernel CONFIG or maybe opt-in per socket. Tom > Bye, > Hannes > > -- > 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 -- 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
