On 2022/04/10 1:46, Eric Dumazet wrote: > Try removing NFS from your kernel .config ? If your repro still works, > then another user of kernel TCP socket needs some care. Since my .config is CONFIG_NETWORK_FILESYSTEMS=n, NFS is irrelevant. On 2022/04/10 2:47, Eric Dumazet wrote: > So please add to your tree the NFS fix: > > commit f00432063db1a0db484e85193eccc6845435b80e > Author: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > Date: Sun Apr 3 15:58:11 2022 -0400 > > SUNRPC: Ensure we flush any closed sockets before xs_xprt_free() Since CONFIG_SUNRPC depends on CONFIG_NETWORK_FILESYSTEMS=y, this NFS fix will be also irrelevant. On 2022/04/10 2:55, Eric Dumazet wrote: > Side note: We will probably be able to revert this patch, that perhaps > was working around the real issue. > > commit 4ee806d51176ba7b8ff1efd81f271d7252e03a1d > Author: Dan Streetman <ddstreet@xxxxxxxx> > Date: Thu Jan 18 16:14:26 2018 -0500 > > net: tcp: close sock if net namespace is exiting I uploaded my .config at https://I-love.SAKURA.ne.jp/tmp/config-5.17 so that you can try this reproducer using my .config file. I haven't identified where the socket [ 260.295512][ C0] BUG: Trying to access destroyed net=ffff888036278000 sk=ffff88800e2d8000 [ 260.301941][ C0] sk->sk_family=10 sk->sk_prot_creator->name=TCPv6 sk->sk_state=11 sk->sk_flags=0x30b net->ns.count=0 came from. Can you identify the location?
