6.2.8 kernel revert needed for zfs-2.1.9 dkms

[comrade-meowski]

The latest stable kernel 6.2.8 causes zfs-2.1.9 & zfs-2.1.10-staging to fail during dkms installation of the zfs modules.

The error given in the dkms make.log is:

ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'bio_start_io_acct'
ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'bio_end_io_acct_remapped'

Building 6.2.8 with commit b477180587d81a4dd756361098bd534dfa6bb53d reverted allows zfs dkms to complete normally again. I have only tested with dkms but presumably this will more generally stop zfs building against 6.2.8 at all.

This is the kernel commit:

commit b477180587d81a4dd756361098bd534dfa6bb53d
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 23 17:12:26 2023 +0800

    block: count 'ios' and 'sectors' when io is done for bio-based device
    
    [ Upstream commit 5f27571382ca42daa3e3d40d1b252bf18c2b61d2 ]
    
    While using iostat for raid, I observed very strange 'await'
    occasionally, and turns out it's due to that 'ios' and 'sectors' is
    counted in bdev_start_io_acct(), while 'nsecs' is counted in
    bdev_end_io_acct(). I'm not sure why they are ccounted like that
    but I think this behaviour is obviously wrong because user will get
    wrong disk stats.
    
    Fix the problem by counting 'ios' and 'sectors' when io is done, like
    what rq-based device does.

[hphilm]

That patch got originally added to 6.3-rc3 kernel and backported to 6.2.8

[rincebrain]

That's probably fixable, I would expect, based on reading the commit - I would guess that the difference is the signature change is making some kernel compat configure check fall back on something that's a GPL-only export now, and a simple update to that would resolve this...

e: something like 3ace9de (untested on 6.2+, I don't have that tree laying around conveniently)

e2: or more like the above plus 2e9c9b7

[simonbcn]

Arch Linux
Linux-xanmod 6.2.8

Same problem compiling from source.

[wtosta]

I confirm the issue on SlackWare Linux 15 x86_64 current compiling ZFS on 6.2.8 kernel. On Linux kernel 6.2.6 I haven't got any compilation issues.

[ptr1337]

Same issue here.
Log is in this action:
https://github.com/CachyOS/linux-cachyos/actions/runs/4492407990

[HougeLangley]

Same issue

https://bugs.gentoo.org/902821

[demmm]

That's probably fixable, I would expect, based on reading the commit - I would guess that the difference is the signature change is making some kernel compat configure check fall back on something that's a GPL-only export now, and a simple update to that would resolve this...

e: something like 3ace9de (untested on 6.2+, I don't have that tree laying around conveniently)

e2: or more like the above plus 2e9c9b7

Both patches apply cleanly on 6.2.8, but no change in the build error, seems versions not used when applied to 6.2?
See messages:

checking whether blk_cleanup_disk() exists... no
checking whether generic bdev_*_io_acct() are available... no
checking whether generic disk_*_io_acct() are available... no
checking whether generic bio_*_io_acct() are available... yes

according to the patch, second line should be whether 6.2+ bdev_*_io_acct() are available

[rincebrain]

Did you regenerate with autogen.sh after applying before rerunning configure? Because at least for me, on the checkout of 2e9c9b7, on a 5.15 system: configure:110409: checking whether 6.2+ bdev_*_io_acct() are available configure:110424: result: no configure:110426: checking whether pre-6.3 bdev_*_io_acct() are available configure:110441: result: no configure:110443: checking whether generic disk_*_io_acct() are available configure:110450: result: yes

…

On Thu, Mar 23, 2023 at 11:14 AM demmm ***@***.***> wrote: That's probably fixable, I would expect, based on reading the commit - I would *guess* that the difference is the signature change is making some kernel compat configure check fall back on something that's a GPL-only export now, and a simple update to that would resolve this... e: something like 3ace9de <3ace9de> (untested on 6.2+, I don't have that tree laying around conveniently) e2: or more like the above plus 2e9c9b7 <2e9c9b7> Both patches apply cleanly on 6.2.8, but no change in the build error, seems versions not used when applied to 6.2? See messages: checking whether blk_cleanup_disk() exists... no checking whether generic bdev_*_io_acct() are available... no checking whether generic disk_*_io_acct() are available... no checking whether generic bio_*_io_acct() are available... yes according to the patch, second line should be whether 6.2+ bdev_*_io_acct() are available — Reply to this email directly, view it on GitHub <#14658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUI7ME5NXK7VDY2XWLGETW5RSD7ANCNFSM6AAAAAAWETO4DM> . You are receiving this because you commented.Message ID: ***@***.***>

[demmm]

@rincebrain That was it (I thought it was enabled, but ended up being commented out), builds fine now.