Zfs: Linux 4.18: zfs.ko uses GPL-only symbol '__put_devmap_managed_page'

[tonyhutter]

Describe the problem you're observing

I get this build error using the Ubuntu 18.04 nightly 4.18.0-041800rc1-generic kernel:

FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol '__put_devmap_managed_page'

This is because put_page() now calls the GPL'd __put_devmap_managed_page(), effectively making put_page() GPL as well. This may have just been an oversight, as __put_page() is still exported non-GPL. Here's how the two functions look between kernel versions:

### 4.18 ###
put_page
static inline void put_page(struct page *page)
{
        page = compound_head(page);

        /*
         * For devmap managed pages we need to catch refcount transition from
         * 2 to 1, when refcount reach one it means the page is free and we
         * need to inform the device driver through callback. See
         * include/linux/memremap.h and HMM for details.
         */
        if (put_devmap_managed_page(page))
                return;

        if (put_page_testzero(page))
                __put_page(page);
}

### 4.15 ###
static inline void put_page(struct page *page)
{
        page = compound_head(page);

        /*
         * For private device pages we need to catch refcount transition from
         * 2 to 1, when refcount reach one it means the private device page is
         * free and we need to inform the device driver through callback. See
         * include/linux/memremap.h and HMM for details.
         */
        if (IS_HMM_ENABLED && unlikely(is_device_private_page(page) ||
            unlikely(is_device_public_page(page)))) {
                put_zone_device_private_or_public_page(page);
                return;
        }

        if (put_page_testzero(page))
                __put_page(page);
}

System information

Type | Version/Name
--- | ---
Distribution Name | Ubuntu
Distribution Version | 18.04
Linux Kernel | 4.18.0-041800rc1-generic
Architecture | x86_64
ZFS Version | behlendorf:linux-4.18
SPL Version |

Describe how to reproduce the problem

Using nightly kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc1/

$ make
make[3]: Entering directory '/home/hutter/behlendorf/module/icp'
mkdir -p api core spi io os algs algs/aes algs/edonr algs/modes algs/sha1 algs/sha2 algs/skein asm-x86_64 asm-x86_64/aes asm-x86_64/modes asm-x86_64/sha1 asm-x86_64/sha2 asm-i386 asm-generic
make[3]: Leaving directory '/home/hutter/behlendorf/module/icp'
make[3]: Entering directory '/home/hutter/behlendorf/module/lua'
mkdir -p setjmp
make[3]: Leaving directory '/home/hutter/behlendorf/module/lua'
make -C /usr/src/linux-headers-4.18.0-041800rc1-generic SUBDIRS=`pwd`  CONFIG_ZFS=m modules
make[3]: Entering directory '/usr/src/linux-headers-4.18.0-041800rc1-generic'
  Building modules, stage 2.
  MODPOST 8 modules
FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol '__put_devmap_managed_page'
scripts/Makefile.modpost:92: recipe for target '__modpost' failed
make[4]: *** [__modpost] Error 1
Makefile:1508: recipe for target 'modules' failed
make[3]: *** [modules] Error 2
make[3]: Leaving directory '/usr/src/linux-headers-4.18.0-041800rc1-generic'
Makefile:29: recipe for target 'modules' failed
make[2]: *** [modules] Error 2
make[2]: Leaving directory '/home/hutter/behlendorf/module'
Makefile:783: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/hutter/behlendorf'
Makefile:652: recipe for target 'all' failed
make: *** [all] Error 2

Include any warning/errors/backtraces from the system logs

[al3xtjames]

Seems to be an upstream bug, this patch should fix it.

[OrdinaryMagician]

On 4.18-rc2 here, I can confirm that patch fixes it.

[tonyhutter]

@OrdinaryMagician thanks for testing it. Closing issue.

[ColinIanKing]

Hrm, I'm building against v4.18-rc4 and I'm still seeing the issue and I don't see the fix https://patchwork.kernel.org/patch/10473337/ in v4.18-rc4.

[ColinIanKing]

nor is it in linux-next either :-(

[ColinIanKing]

Do we know if the kernel fix will land for 4.18?

[behlendorf]

@ColinIanKing my expectation was that it would be been merged for 4.18, I'm a bit surprised it hasn't already happened. We should check with the original author to see where things stand, it would be best if we could get this fix in.

[behlendorf]

The fix for this is in the pipeline for the kernel and is expected to be part of 4.18.