[PATCH v2] Fix linux-starfive build under sid

[Uladzimir Bely]

The patch is taken from the linux kernel upstream >= 6.8.

Signed-off-by: Uladzimir Bely <ub...@ilbers.de>
---
...oc-arguments-order-in-btrfs_ioctl_se.patch | 43 +++++++++++++++++++
.../linux/linux-starfive_6.6-visionfive2.bb | 1 +
2 files changed, 44 insertions(+)
create mode 100644 meta-isar/recipes-kernel/linux/files/0001-btrfs-fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch

Changes since v1 (Fix linux build under sid and trixie):

- Since we don't build linux-mainline/linux-phy kernels for trixie/sid
apply kernel patch only for linux-starfive_6.6-visionfive2 target.

I additionally checked [1] for existing branches and can conclude:
- recent 6.6-based branch "JH7110_VisionFive2_upstream" is still
affected and requires the patch
- recent "starfive-tech/visionfive" is 6.10-based already includes
the fix, but using it leads to different build errors. Also, I'm not
sure if it properly supports "VisionFive2" board.

So, for now, the simplest way to fix build error we have in CI is to
just apply upstream patch.

[1] https://github.com/starfive-tech/linux

diff --git a/meta-isar/recipes-kernel/linux/files/0001-btrfs-fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch b/meta-isar/recipes-kernel/linux/files/0001-btrfs-fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch
new file mode 100644
index 00000000..afe09eab
--- /dev/null
+++ b/meta-isar/recipes-kernel/linux/files/0001-btrfs-fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch
@@ -0,0 +1,43 @@
+From 6ff09b6b8c2fb6b3edda4ffaa173153a40653067 Mon Sep 17 00:00:00 2001
+From: Dmitry Antipov <dman...@yandex.ru>
+Date: Thu, 21 Dec 2023 11:47:45 +0300
+Subject: [PATCH] btrfs: fix kvcalloc() arguments order in btrfs_ioctl_send()
+
+When compiling with gcc version 14.0.0 20231220 (experimental)
+and W=1, I've noticed the following warning:
+
+fs/btrfs/send.c: In function 'btrfs_ioctl_send':
+fs/btrfs/send.c:8208:44: warning: 'kvcalloc' sizes specified with 'sizeof'
+in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
+ 8208 | sctx->clone_roots = kvcalloc(sizeof(*sctx->clone_roots),
+ | ^
+
+Since 'n' and 'size' arguments of 'kvcalloc()' are multiplied to
+calculate the final size, their actual order doesn't affect the result
+and so this is not a bug. But it's still worth to fix it.
+
+Signed-off-by: Dmitry Antipov <dman...@yandex.ru>
+Reviewed-by: David Sterba <dst...@suse.com>
+Signed-off-by: David Sterba <dst...@suse.com>
+---
+ fs/btrfs/send.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
+index 4e36550618e5..2d7519a6ce72 100644
+--- a/fs/btrfs/send.c
++++ b/fs/btrfs/send.c
+@@ -8205,8 +8205,8 @@ long btrfs_ioctl_send(struct inode *inode, struct btrfs_ioctl_send_args *arg)
+ goto out;
+ }
+
+- sctx->clone_roots = kvcalloc(sizeof(*sctx->clone_roots),
+- arg->clone_sources_count + 1,
++ sctx->clone_roots = kvcalloc(arg->clone_sources_count + 1,
++ sizeof(*sctx->clone_roots),
+ GFP_KERNEL);
+ if (!sctx->clone_roots) {
+ ret = -ENOMEM;
+--
+2.45.2
+
diff --git a/meta-isar/recipes-kernel/linux/linux-starfive_6.6-visionfive2.bb b/meta-isar/recipes-kernel/linux/linux-starfive_6.6-visionfive2.bb
index f4dd5c9a..a267241f 100644
--- a/meta-isar/recipes-kernel/linux/linux-starfive_6.6-visionfive2.bb
+++ b/meta-isar/recipes-kernel/linux/linux-starfive_6.6-visionfive2.bb
@@ -8,6 +8,7 @@ require recipes-kernel/linux/linux-custom.inc
SRC_URI += " \
https://github.com/starfive-tech/linux/archive/${SRCREV}.tar.gz;downloadfilename=linux-starfive-${SRCREV}.tar.gz \
file://0001-riscv-efistub-Ensure-GP-relative-addressing-is-not-u.patch \
+ file://0001-btrfs-fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch \
file://starfive2_extra.cfg"
SRCREV = "9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4"
SRC_URI[sha256sum] = "9eaf7659aa57e2c5b399b7b33076f1376ec43ef343680e0a57e0a2a9bef6c0ae"
--
2.45.2

[Uladzimir Bely]

On Fri, 2024-10-04 at 11:17 +0300, Uladzimir Bely wrote:
> The patch is taken from the linux kernel upstream >= 6.8.
>
> Signed-off-by: Uladzimir Bely <ub...@ilbers.de>
> ---
>  ...oc-arguments-order-in-btrfs_ioctl_se.patch | 43
> +++++++++++++++++++
>  .../linux/linux-starfive_6.6-visionfive2.bb   |  1 +
>  2 files changed, 44 insertions(+)
>  create mode 100644 meta-isar/recipes-kernel/linux/files/0001-btrfs-
> fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch
>
> Changes since v1 (Fix linux build under sid and trixie):
>
> - Since we don't build linux-mainline/linux-phy kernels for
> trixie/sid
> apply kernel patch only for linux-starfive_6.6-visionfive2 target.
>
> I additionally checked [1] for existing branches and can conclude:
>  - recent 6.6-based branch "JH7110_VisionFive2_upstream" is still
> affected and requires the patch
>  - recent "starfive-tech/visionfive" is 6.10-based already includes
> the fix, but using it leads to different build errors. Also, I'm not
> sure if it properly supports "VisionFive2" board.
>
> So, for now, the simplest way to fix build error we have in CI is to
> just apply upstream patch.

BTW, in case of using kas-isar images, this build error is currently
masked by debootstrap one. Even recent kas-4.5 currently uses
debootstrap version 1.0.28 that can't create trixie/sid rootfs.

Since some of kas developers are also reading this, I could propose to
update kas images to debootstrap/bookworm-backports version (1.0.134)
that works fine.

--
Best regards,
Uladzimir.

[Jan Kiszka]

NACK, update the kernel. I think I already told you. May even obsolete
the other patch.

Jan

--
Siemens AG, Technology
Linux Expert Center

[Uladzimir Bely]

> > diff --git a/meta-isar/recipes-kernel/linux/files/0001-btrfs-fix-
> > kvcalloc-arguments-order-in-btrfs_ioctl_se.patch b/meta-
> > isar/recipes-kernel/linux/files/0001-btrfs-fix-kvcalloc-arguments-

> > diff --git a/meta-isar/recipes-kernel/linux/linux-starfive_6.6-
> > visionfive2.bb b/meta-isar/recipes-kernel/linux/linux-starfive_6.6-
> > visionfive2.bb
> > index f4dd5c9a..a267241f 100644
> > --- a/meta-isar/recipes-kernel/linux/linux-starfive_6.6-
> > visionfive2.bb
> > +++ b/meta-isar/recipes-kernel/linux/linux-starfive_6.6-
> > visionfive2.bb

> > @@ -8,6 +8,7 @@ require recipes-kernel/linux/linux-custom.inc
> >  SRC_URI += " \
> >     
> > https://github.com/starfive-tech/linux/archive/${SRCREV}.tar.gz;downloadfilename=linux-starfive-${SRCREV}.tar.gz
> >  \
> >     
> > file://0001-riscv-efistub-Ensure-GP-relative-addressing-is-not-u.patch
> >  \
> > +   
> > file://0001-btrfs-fix-kvcalloc-arguments-order-in-btrfs_ioctl_se.patch
> >  \
> >      file://starfive2_extra.cfg"
> >  SRCREV = "9fe004eaf1aa5b23bd5d03b4cfe9c3858bd884c4"
> >  SRC_URI[sha256sum] =
> > "9eaf7659aa57e2c5b399b7b33076f1376ec43ef343680e0a57e0a2a9bef6c0ae"
>
> NACK, update the kernel. I think I already told you. May even
> obsolete
> the other patch.

Yes, I tried this (see the text above the diff starts). Updated 6.6-
based branch still requires both patches.

>
> Jan
>

--
Best regards,
Uladzimir.

[Jan Kiszka]

https://github.com/starfive-tech/linux/commits/starfive-6.6.31-dubhe

As I told you.

I'm sending the proper patch in a minute.

[Jan Kiszka]

Sorry, seems that's the wrong tree, and JH7110_VisionFive2_6.6.y_devel
was not updated properly.

But there is no way to build against sid except for using an older
snapshot. How did you test this?

[Uladzimir Bely]

I tested few branches:
- JH7110_VisionFive2_upstream - this seems to be a proper tree (at
least, it includes starfive_visionfive2_defconfig, and appropriate
devicetree files look complete). But this still has now a fix and
requires both patches
- starfive-tech/visionfive - this is based on linux-6.10, includes
both patches. But there are different build errors here and no
starfive_visionfive2_defconfig present. Also, board devicetree files
has less stuff.
- starfive-6.6.31-dubhe - this includes the patch (but not the other
one). But there is also no proper defconfig and board deficetrees are
not looking full enough.

Some tests were done in one of our CI instances where we already have
an updated version of debootstrap installed. Manual check of the build
can be also done under kas-container shell, but some additional steps
(e.g., adding bookworm-backports to source list and installing
"debootstrap/bookworm-backports") are required before running bitbake.

--
Best regards,
Uladzimir.

[Jan Kiszka]

Yes, it is. I've created
https://github.com/starfive-tech/linux/issues/140 to resolve the problem
"upstream" eventually.

> - starfive-tech/visionfive - this is based on linux-6.10, includes
> both patches. But there are different build errors here and no
> starfive_visionfive2_defconfig present. Also, board devicetree files
> has less stuff.

That's version 1 of the VisionFive, a different board.

> - starfive-6.6.31-dubhe - this includes the patch (but not the other
> one). But there is also no proper defconfig and board deficetrees are
> not looking full enough.

Even a different SoC that may lack patches we need. I was misled.

>
> Some tests were done in one of our CI instances where we already have
> an updated version of debootstrap installed. Manual check of the build
> can be also done under kas-container shell, but some additional steps
> (e.g., adding bookworm-backports to source list and installing
> "debootstrap/bookworm-backports") are required before running bitbake.
>

You must be natively building - I don't have that much time. Crossbuild
is borken once again, but the snapshot we also use in isar-cip-core is
fine (but not affected by the compiler update), see my kas menu patch.

Anyway, ACK for this patch until upstream updated their branch.

[Uladzimir Bely]

Yes, I was building it natively for tests (as well as CI does).

Trixie/sid cross builds are currently broken (not only on riscv64).
That's another issue to solve (or, maybe, wait for upstream?).

> Anyway, ACK for this patch until upstream updated their branch.
>
> Jan
>

--

Best regards,
Uladzimir.

[Jan Kiszka]

Use snapshots for crossbuilding. As I wrote, native building takes way
too much time to be used in practice.

BTW, we can bump to the latest revision of
JH7110_VisionFive2_6.6.y_devel and drop the other patch at this chance.
Just noticed that 6.6.20, their current head, actually contains it.

[Uladzimir Bely]

Let's postpone bumping the development revision until both patches are
merged. Or, at least, it could be done with a separate patchset.

v2 is applied to the next.

--
Best regards,
Uladzimir.