netdev - Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment

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:	Sat, 28 Apr 2012 08:30:45 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	Neal Cardwell <ncardwell@...gle.com>,
	Tom Herbert <therbert@...gle.com>,
	Maciej Żenczykowski <maze@...gle.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	Matt Carlson <mcarlson@...adcom.com>,
	Michael Chan <mchan@...adcom.com>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment

On Fri, 2012-04-27 at 17:27 -0700, Alexander Duyck wrote:

> This doesn't seem right to me.  You are only counting the piece of the
> page that got filled with data and the piece that will get overwritten
> with the shared info.  What about the rest of the page?  It looks like
> in the tg3 patch you have the driver using a half page.  Based on this
> function I suspect the resultant truesize would be something like 64 +
> 256 + 320 for an ack.  Shouldn't your truesize in that case be 2048 + 256?

Hi Alex

Not sure what you mean, since there is no such change in this patch.

driver must pass the truesize of the fragment, not the used one to
build_skb(). This is what I did in tg3 patch.

Therefore, all packets will have truesize = 2048 + 256.

The tg3 patch could be generalized to take care of special MTU, and be
able to use 1024 or 4096 as well for the frag size.

Lets discuss of the existing truesize problem.

There is one problem with fragments : We track the used length of them,
not their truesize.

So for example, GRO is not able to track resulting truesize.

We could split the "__u32 size;" to :

__u32 size:24;
__u32 truesizelog:8;

this_frag_truesize = max(1U << frag->truesizelog, frag->size);


  


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