On Sun, Sep 4, 2022 at 10:41 AM Aditi Ghag <aditivghag@xxxxxxxxx> wrote: > > On Wed, Aug 31, 2022 at 3:02 PM <sdf@xxxxxxxxxx> wrote: > > > > On 08/31, Aditi Ghag wrote: > > [...] > > > > > - The sock_destroy API added for similar Android use cases is > > > effective in tearing down sockets. The API is behind the > > > CONFIG_INET_DIAG_DESTROY config that's disabled by default, and > > > currently exposed via SOCK_DIAG netlink infrastructure in userspace. > > > The sock destroy handlers for TCP and UDP protocols send ECONNABORTED > > > error code to sockets related to the abort state as mentioned in RFC > > > 793. > > > > > - Add unreachable routes for deleted backends. I experimented with > > > this approach with my colleague, Nikolay Aleksandrov. We found that > > > TCP and connected UDP sockets in the established state simply ignore > > > the ICMP error messages, and continue to send data in the presence of > > > such routes. My read is that applications are ignoring the ICMP errors > > > reported on sockets [2]. > > > > [..] > > > > > - Use BPF (sockets) iterator to identify sockets connected to a > > > deleted backend. The BPF (sockets) iterator is network namespace aware > > > so we'll either need to enter every possible container network > > > namespace to identify the affected connections, or adapt the iterator > > > to be without netns checks [3]. This was discussed with my colleague > > > Daniel Borkmann based on the feedback he shared from the LSFMMBPF > > > conference discussions. > > > > Maybe something worth fixing as well even if you end up using netlink? > > Having to manually go over all networking namespaces (if I want > > to iterate over all sockets on the host) doesn't seem feasible? > > SOCK_DIAG netlink infrastructure also has similar netns checks. The > iterator approach > would allow us to invoke sock destroy handlers from BPF though. Sorry, I think I wasn't clear enough. I meant that having a mode to iterate over all sockets on the host regardless of the namespace might be useful. Martin suggests the same in [1], I'll follow that thread :-) [1] https://lore.kernel.org/bpf/20220831230157.7lchomcdxmvq3qqw@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
