netdev - Re: /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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Nov 2014 09:27:34 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Denys Fedoryshchenko <nuclearcat@...learcat.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>
Cc:	netdev@...r.kernel.org
Subject: Re: /proc/net/sockstat invalid memory accounting or memory leak in
 latest kernels? (trying to debug)

On Wed, 2014-11-12 at 19:07 +0200, Denys Fedoryshchenko wrote:
> 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 :)
> 

Thanks a lot for the report, I am CCing other experts ;)

AFAIK, a negative forward alloc should not be a problem, a long as the
incursion is bound.



--
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