Fw: [Bug 216680] New: suspicious sock leak

Fw: [Bug 216680] New: suspicious sock leak

[Stephen Hemminger]

Begin forwarded message:

Date: Fri, 11 Nov 2022 13:59:04 +0000
From: bugzilla-daemon@kernel.org
To: stephen@networkplumber.org
Subject: [Bug 216680] New: suspicious sock leak


https://bugzilla.kernel.org/show_bug.cgi?id=216680

            Bug ID: 216680
           Summary: suspicious sock leak
           Product: Networking
           Version: 2.5
    Kernel Version: 4.18.0
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@networkplumber.org
          Reporter: bianmingkun@gmail.com
        Regression: No

1. A HTTP Server，I will insert a node to ebpf map(BPF_MAP_TYPE_LRU_HASH) by
BPF_MAP_UPDATE_ELEM when receving a "HTTP GET" packet,
ebpf map
key: cookie(by SO_COOKIE)
value: saddr sport daddr dport

2. I will delete the corresponding ebpf map node by "kprobe __sk_free" in ebpf.

3. Sending pressure "HTTP GET" to HTTP Server for a while，then stop sending and
closing the HTTP Server, then wait a long time, we can not see any tcpinfo by
"netstat -anp", then error occurs：

   We can see some node which is not deleted by "bpftool map dump id **"， it
seems look like "sock leak", but the sockstat's inuse does not increase
quickly.

4. I did some more experiments by ebpf' kprobe, I find that a sock* does not
come int __sock_free, but the same sock* will be reused by another tcp
connection(the most frequent is "127.0.0.1") after a while.
   What I doubt is that why a new tcp connection can resue a old sock while the
old sock does not come in __sk_free

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.