On Thu, Nov 19, 2015 at 2:38 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > > > On Thu, Nov 19, 2015, at 23:33, Lorenzo Colitti wrote: >> On Fri, Nov 20, 2015 at 2:38 AM, Tom Herbert <t...@herbertland.com> wrote: >> >> 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. >> >> I'm not wedded to ETIMEDOUT. If it means we can get this code >> upstream, then we can likely do the userspace work that is needed to >> ensure that applications respond correctly. Mot >> >> > 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. >> >> I am perfectly happy for this to be behind a config option. > > Why? If it is an administrator only option it does not make sense to > hide it behind a sysctl. Applications using this interface could also > easily change the sysctl because they probably have the same privileges. > A Kconfig option seems to be not useful to me either. >
A sysctl is obviously useless, but Kconfig option is good. There is no way I want this option enabled in my data center without any demonstrated need for it. History has shown many times, that once we allow options like this to be enabled in the kernel, they will inevitably be used often without our (kernel experts') knowledge or supervision. In too many cases this blows up in our faces (there has been at least one outage @FB caused by someone inadvertently exercising an otherwise obscure kernel feature). Tom -- 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
