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>] [day] [month] [year] [list]
Message-ID: <34241.129.240.228.53.1201623428.squirrel@webmail.uio.no>
Date:	Tue, 29 Jan 2008 17:17:08 +0100 (CET)
From:	kristrev@...dent.matnat.uio.no
To:	netdev@...r.kernel.org
Subject: SKBs with shared fragments

Hello,

I am working on a patch to the TCP-code that, among others, share
fragments between skbs, and have encountered a problem that I'm not sure
if I have solved correctly.

To share a fragment, I copy the skb_frag-struct to the correct place in
the other skbs frags-array, increase the page-counter, skb->data_len,
skb->len, skb->end_seq and gso_segs/gso_size, and calculate a new
checksum.

The problem is the skb->truesize-variable. Currently I do not increase it,
leading to a SKB BUG because truesize is less than (skb->len +
sizeof(struct skb)). When I increase/decrease truesize, both the
wmem_queue and sk_forward_alloc is something else than zero and the socket
leaks memory.

The kernel does not halt and all the data is received correctly in both
cases.

The reason that I currently don't increase/decrease truesize is that, at
least if I have understod the code correctly, truesize says something
about how much memory an skb actually consumes. And since I only copy
existing fragments into it, I don't use any more memory.

Is this correct, or should I increase/decrease truesize as well? Also, is
there a better way to share fragments between skbs?

Thanks in advance for any replies,
Kristian

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ