netdev - Re: [PATCH net-next 1/2] net: Header length compution function

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20140730.183907.1435538533126954589.davem@davemloft.net>
Date:	Wed, 30 Jul 2014 18:39:07 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	alexander.h.duyck@...el.com
Cc:	eric.dumazet@...il.com, amirv@...lanox.com, netdev@...r.kernel.org,
	ogerlitz@...lanox.com, yevgenyp@...lanox.com, idos@...lanox.com
Subject: Re: [PATCH net-next 1/2] net: Header length compution function

From: Alexander Duyck <alexander.h.duyck@...el.com>
Date: Wed, 30 Jul 2014 07:26:33 -0700

> It wasn't that I don't trust the core function.  We already had some of
> our own code floating around for the out-of-tree LRO and so I simply
> made use of that as it allowed for code reuse in our driver.

It would be nice if this code were converted to use the generic
infrastructure, at some point at least.

> I almost wonder if it wouldn't be worth while to move data_len and len
> closer to the end of the sk_buff and perhaps create a structure within
> the structure so that you could partition off all of the bits that we
> don't need for these kind of simple operations.

That is something we can certainly look into in the long term.

But it's also not all that desirable to try to extricate the
non-linear handling.  It took us a long time to get all the code to
handle non-linear SKBs :-)

And in that case you have the issue of the fragmenting state being
separate in the skb_shared_info.

Anyways, a discussion for a different thread I think.

I don't think my proposed patch is a bad trade off.  Where we have the
__skb_header_pointer() thing that takes preloaded pointers and header
length values.  It adds only one test which frankly should never
trigger and can be moved down into skb_copy_bits() or similar.
--
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