netdev - RE: [E1000-devel] [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS

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] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2013 09:42:28 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Eric Dumazet" <eric.dumazet@...il.com>,
	"Alexander Duyck" <alexander.h.duyck@...el.com>
Cc:	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	<e1000-devel@...ts.sourceforge.net>, <netdev@...r.kernel.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Daniel Santos" <daniel.santos@...ox.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Wu, Fengguang" <fengguang.wu@...el.com>
Subject: RE: [E1000-devel] [next:akpm 16/587] drivers/net/ethernet/intel/igb/igb_main.c:6231:2: error: call to '__compiletime_assert_6235' declared with attribute error: BUILD_BUG_ON failed: SKB_WITH_OVERHEAD(IGB_RX_BUFSZ) < (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HD

> > The problem is the 256 byte alignment for L1_CACHE_BYTES is increasing
> > the size of the data and shared info significantly pushing us past the
> > 2K limit.
> >
> > I'll look into this since it likely affects ixgbe as well.

Doesn't a 256 byte cache line cause issues almost everywhere
anything is marked as 'cache_aligned' ?

Some other structures have members part way down marked that way
so that the 2nd cache line (with smaller lines) contains a
known set of fields (either to get them together, or out of the
cache line containing the first part of the data).

With 256 byte cache lines the entire structure would probably be
a single cache line - except that it gets extended to two lines.

I know that some people have a habit of allocating mutex in their
own cache line (with nothing else), that also doesn't make sense
to me - especially with large cache lines (I don't know if there
any of those in Linux).

	David