[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <db4d4a48-b581-4060-b611-996543336cd2@gmail.com>
Date: Wed, 10 Apr 2024 10:28:31 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Eric Dumazet <edumazet@...gle.com>, Vladimir Oltean <olteanv@...il.com>,
Jakub Kicinski <kuba@...nel.org>
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 4/8/2024 10:08 PM, Eric Dumazet wrote:
> 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 !
Also just got hit by this on an ARMv7 build configuration as well.
Jakub, I do not see a 32-bit build in the various checks being run for a
patch, could you add one, if nothing else a i386 build and a
multi_v7_defconfig build would get us a good build coverage.
Thanks!
--
Florian
Powered by blists - more mailing lists