Re: [dpdk-stable] [PATCH] kni: fix compilation on SLES15-SP3

[Christian Ehrhardt <christian.ehrhardt@canonical.com>]

On Thu, Jun 10, 2021 at 12:30 PM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> On Thu, Jun 10, 2021 at 10:39 AM Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
> >
> > On Tue, Jun 8, 2021 at 1:17 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > >
> > > On 6/2/2021 3:33 PM, Christian Ehrhardt wrote:
> > > > Like what was done for mainline kernel in commit 38ad54f3bc76 ("kni: fix
> > > > build with Linux 5.6"), a new parameter 'txqueue' has to be added to
> > > > 'ndo_tx_timeout' ndo on SLES 15-SP3 kernel.
> > > >
> > > > Caused by:
> > > >   commit c3bf155c40e9db722feb8a08c19efd44c12d5294
> > > >   Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> > > >   Date:   Fri Sep 11 16:08:31 2020 +0200
> > > >       - netdev: pass the stuck queue to the timeout handler
> > > >         (jsc#SLE-13536).
> > > >       - Refresh patches.suse/sfc-move-various-functions.patch.
> > > >
> > > > That is part of the SLES 5.3.18 kernel and therefore the
> > > > version we check for.
> > > >
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> > >
> > > Hi Christian,
> > >
> > > There is a build error reported in CI [1] with 'SUSE15-64'.
> > > Can't the check 'linux version >= 5.3.18" may hit multiple SUSE versions, with
> > > some has the patch mentioned above backported and some did not?
> > > Can 'SLE_VERSION_CODE' be used to differentiate the SUSE versions?
> >
> > I don't have a perfect insight in the SUSE distro variants and their
> > kernel versions.
> > > 5.3.18 in SLES15-SP3 was what broke it and I have hoped that this would apply in general.
> > But the error above seems we have others that are > 5.3.18 but at the
> > same time not have the backport.
> >
> > I'll try to create a v3, but do we have anyone from Suse to usually
> > directly ping for feedback on this?
>
> With the new version (not submitted since it fails me) you can have a
> look at my personal WIP branch:
> => https://github.com/cpaelzer/dpdk-stable-queue/commit/43b908fe83e9cd68b08e259c0ace26ec692bb737

Hello everyone,
Ferruh and I reached out to the Suse people working on DPDK in the
past as well as those doing the kernel backport that breaks it now.
(I'll add them to CC here as well)
Unfortunately there was no feedback in a week, but OTOH I also don't
want to stall releases for too long due to this.

I'll try to summarize the current understanding of this case again

[1] breaks our KNI build.

SLE_VERSION isn't provided by their Kernel; it is in DPDKs
kernel/linux/kni/compat.h and not further maintained for a while.
So we can't differentiate SLE15SP2 vs SLE15SP3 via that.

The offending change was introduced in their kernel by [1]
$ git tag --contains c3bf155c40e9 | sort | head
rpm-5.3.18-24
...

But checking just the kernel version 5.3.18 (as my initial patch had)
won't work either.
The problem is that this only checks the three levels of kernel
version, but not the packaging level.
And to make things even more fun, while I don't know if opensuse leap
has the patch applied or not atm, but the kernel version there might
make this even more complex as it is 5.3.18-lp152 at the moment.

We have now:
SLE15 SP2 5.3.18-22
SLE15 SP3 5.3.18-57 (>=24)
opensuse_leap 5.3.18-lp152

Without a change SLE15SP3 is broken due to that backport.
By checking on >=5.3.18 we could fix SP3, but break SP2 and maybe opensuse_leap.

Maybe there is something on LOCALVERSION/EXTRAVERSION we can use, but
"guessing" how the Suse kernel behaves isn't a good approach.
Once Suse lets us know how to better differentiate their packaging
version we can reconsider a proper fix for this.

But without further input from Suse I'd (for now) ask to keep things
as is (= not applying my patch).
Due to that it will build in the same places it has built in the past.
If we find a solution it can be in the next release in ~3 months, but
I'll not further stall e.g. 19.11.9 that I'm working on right now.

[1]: https://github.com/SUSE/kernel/commit/c3bf155c40e9



> Now "my SLE15" fails
>
> [  232s] /home/abuild/rpmbuild/BUILD/dpdk-1623314498.43b908fe8/x86_64-default-linux-gcc/build/kernel/linux/kni/kni_net.c:791:20:
> error: initialization from incompatible pointer type
> [-Werror=incompatible-pointer-types]
> [  232s]   .ndo_tx_timeout = kni_net_tx_timeout,
> [  232s]                     ^~~~~~~~~~~~~~~~~~
>
> The full log is at
> https://build.opensuse.org/package/live_build_log/home:cpaelzer:branches:home:bluca:dpdk/dpdk-19.11/SLE_15/x86_64
>
> That means now the check is now no more catching this SLE15 with their
> linux-5.3.18-57.
>
> I need to find what SLE_VERSION_CODE really is in that environment :-/
> Sadly I don't have that system locally.
>
> So the V3 will be delayed, but any additional input is welcome.
>
> P.S. or I can't make an >= check on SLE_VERSION_CODE ...?
>
>
> > > [1]
> > > http://mails.dpdk.org/archives/test-report/2021-June/197571.html
> > >
> > > > ---
> > > >  kernel/linux/kni/compat.h | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/linux/kni/compat.h b/kernel/linux/kni/compat.h
> > > > index 5f65640d5ed..70e014fd1da 100644
> > > > --- a/kernel/linux/kni/compat.h
> > > > +++ b/kernel/linux/kni/compat.h
> > > > @@ -133,7 +133,9 @@
> > > >
> > > >  #if KERNEL_VERSION(5, 6, 0) <= LINUX_VERSION_CODE || \
> > > >       (defined(RHEL_RELEASE_CODE) && \
> > > > -      RHEL_RELEASE_VERSION(8, 3) <= RHEL_RELEASE_CODE)
> > > > +      RHEL_RELEASE_VERSION(8, 3) <= RHEL_RELEASE_CODE) || \
> > > > +     (defined(CONFIG_SUSE_KERNEL) && \
> > > > +      KERNEL_VERSION(5, 3, 18) <= LINUX_VERSION_CODE)
> > >
> > > Can you please add comment here to clarify for which SUSE version this check is
> > > added?
> >
> > I outlined that in the commit message already, and since the RH8.3
> > check above was added without inline comment I kept the same style.
> > With the updated v3 it will be readable from the code as I'll try
> >   (SLE_VERSION_CODE >= SLE_VERSION(15, 3, 0)
> >
> > I'll submit the v3 after it has passed my test builds which include
> > - SLE_12_SP4
> > - SLE_15
> > - openSUSE_Factory_ARM
> > - openSUSE_Leap_15.2
> > - openSUSE_Leap_42.3
> > - openSUSE_Tumbleweed
> >
> > And of those SLE_15 was the one affected without this fix due to their
> > new new kernel.
> >
> > > >  #define HAVE_TX_TIMEOUT_TXQUEUE
> > > >  #endif
> > > >
> > > >
> > >
> >
> >
> > --
> > Christian Ehrhardt
> > Staff Engineer, Ubuntu Server
> > Canonical Ltd
>
>
>
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd



--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd