[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iJMirOe=TqMZ=J8mFLNQLDV=wzL4jOf9==Zkv7L2U5jcQ@mail.gmail.com>
Date: Wed, 10 Apr 2024 19:33:54 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Vladimir Oltean <olteanv@...il.com>, Jakub Kicinski <kuba@...nel.org>,
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 Wed, Apr 10, 2024 at 7:28 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>
>
>
> 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.
i386 build was just fine for me.
Powered by blists - more mailing lists