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: Tue, 9 Apr 2024 07:08:42 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev, 
	netdev@...r.kernel.org
Subject: Re: [net-next:main 26/50] net/ipv4/tcp.c:4673:2: error: call to
 '__compiletime_assert_1030' declared with 'error' attribute: BUILD_BUG_ON
 failed: offsetof(struct tcp_sock, __cacheline_group_end__tcp_sock_write_txrx)
 - offsetofend(struct tcp_sock, __cacheline_group_begin__tcp_sock_...

On Tue, Apr 9, 2024 at 1:06 AM Vladimir Oltean <olteanv@...il.com> wrote:
>
> Hi Eric,
>
> On Mon, Apr 08, 2024 at 10:49:35PM +0800, kernel test robot wrote:
> > >> net/ipv4/tcp.c:4673:2: error: call to '__compiletime_assert_1030' declared with 'error' attribute: BUILD_BUG_ON failed: offsetof(struct tcp_sock, __cacheline_group_end__tcp_sock_write_txrx) - offsetofend(struct tcp_sock, __cacheline_group_begin__tcp_sock_write_txrx) > 92
> > > 4673                CACHELINE_ASSERT_GROUP_SIZE(struct tcp_sock, tcp_sock_write_txrx, 92);
>
> I can confirm the same compile time assertion with an armv7 gcc 7.3.1 compiler.
> If I revert commit 86dad9aebd0d ("Revert "tcp: more struct tcp_sock adjustments")
> it goes away.
>
> Before the change (actually with it reverted), I can see that the
> tcp_sock_write_txrx cacheline group begins at offset 1821 with a 3 byte
> hole, and ends at offset 1897 (it has 76 bytes).


...

> It gained 20 bytes in the change. Most notably, it gained a 4 byte hole
> between pred_flags and tcp_clock_cache.
>
> I haven't followed the development of these optimizations, and I tried a
> few trivial things, some of which didn't work, and some of which did.
> Of those that worked, the most notable one was letting the 2 u64 fields,
> tcp_clock_cache and tcp_mstamp, be the first members of the group, and
> moving the __be32 pred_flags right below them.
>
> Obviously my level of confidence in the fix is quite low, so it would be
> great if you could cast an expert eye onto this.

I am on it, do not worry, thanks !

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ