netdev - /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <2adbf5346b4dd2bebe1915096c1c567c@visp.net.lb>
Date:	Wed, 12 Nov 2014 19:07:48 +0200
From:	Denys Fedoryshchenko <nuclearcat@...learcat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: /proc/net/sockstat invalid memory accounting or memory leak in
 latest kernels? (trying to debug)

Hi


I've been able to trace invalid memory shown for sk_forward_alloc. Not 
sure if it is related to bug when all tcp stack are wrecked on highload 
servers (i had even such crash on server with plain torrents, not that 
much of them).
First they were appearing in ss output as f4294966016, but in tc it 
shows as unsigned integer, while in kernel it is signed integer. Should 
i provide patch for iproute2?
After changing value to correct one, here is what is got:
          skmem:(r0,rb359040,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
          skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)

So as it is signed integer, it is actually appears a lot as -1280 bytes.
After placing several WARN_ON_ONCE on fall functions involving 
sk_forward_alloc, where negative value may
appear i traced down at least to tcp_connect_queue_skb().
[   13.094561] WARNING: CPU: 4 PID: 2855 at include/net/sock.h:1476 
tcp_connect_queue_skb+0x9f/0xd0()
After adding some debug values, it was confirmed:


skb_header_release(skb);
__tcp_add_write_queue_tail(sk, skb);
sk->sk_wmem_queued += skb->truesize;
sk_mem_charge(sk, skb->truesize); <<<< sk->sk_forward_alloc often is 0, 
and skb->truesize is 1280, so -1280 is result
tp->write_seq = tcb->end_seq;
tp->packets_out += tcp_skb_pcount(skb);

Maybe it should not be subtracted here? Or maybe logic are inverted all 
over the code?
Please help :)


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html