linux-kernel - Re: problems with e1000 and jumboframes

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]

Message-ID: <20060803161046.GA703@2ka.mipt.ru>
Date:	Thu, 3 Aug 2006 20:10:47 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Chris Leech <chris.leech@...il.com>
Cc:	Krzysztof Oledzki <olel@....pl>, Arnd Hannemann <arnd@...dnet.de>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: problems with e1000 and jumboframes

On Thu, Aug 03, 2006 at 08:57:36AM -0700, Chris Leech (chris.leech@...il.com) wrote:
> On 8/3/06, Evgeniy Polyakov <johnpol@....mipt.ru> wrote:
> 
> >> Strange, why this skb_shared_info cannon be added before first alignment?
> >> And what about smaller frames like 1500, does this driver behave similar
> >> (first align then add)?
> >
> >It can be.
> >Could attached  (completely untested) patch help?
> 
> Note that e1000 uses power of two buffers because that's what the
> hardware supports.  Also, there's no program able MTU - only a single
> bit for "long packet enable" that disables frame length checks when
> using jumbo frames.  That means that if you tell the e1000 it has a
> 16k buffer, and a 16k frame shows up on the wire, it's going to write
> to the entire 16k regardless of your 9k MTU setting.  If a 32k frame
> shows up, two full 16k buffers get written to (OK, assuming the frame
> can fit into the receive FIFO)

Maximum e1000 frame is 16128 bytes, which is enough before being rounded
to 16k to have a space for shared info.
My patch just tricks refilling logic to request to allocate slightly less
than was setup when mtu was changed.

> That's why I've always been against trying to optimize the allocation
> sizes in the driver, even with your small change the skb_shinfo area
> can get corrupted.  It may be unlikely, because the frame still has to
> be valid, but some switches aren't real picky about what sized frame
> they'll forward on if you enable jumbo support either.  So any box on
> the LAN could send you larger than MTU frames in an attempt to corrupt
> memory.

It is trivial patch and it can be incorrect (especially for small sized
packets), but it is a hint, that 9k jumbo frame should not require 32k
allocation.

> I believe that if you tell a hardware device it has a buffer of a
> certain size, you need to be prepared for that entire buffer to get
> written to.  Unfortunately that means wasteful allocations for e1000
> if a single buffer per frame is going to be used.

Hardware is not affected, second patch just checks if there is enough
space (e1000 stores real mtu). I can not believe that such modern NIC
like e1000 can not know in receive interrupt size of the received
packet, if it is true, than in generel you are right and some more 
clever mechanisms shoud be used (at least turn hack off for small
packets and only enable it for less than 16 jumbo frames wheere place 
always is), if size of the received packet is known, then it is enough
to compare aligned size and size of the packet to make a decision for
allocation.

> - Chris

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/