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. > I do think this kernel functionality is useful in general, and as a > linux-on-laptop user I wish it was available to NetworkManager as > well, because I use Linux as well, but I think it will work for > Android if this requires a per-socket opt in setsockopt. For other > reasons we pipe all connected sockets through a userspace daemon > anyway. (But please don't tell me that that daemon should keep state > on *all* connected sockets it ever sees :-)) Exactly! -- 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
