Kernel 6.7 - aufs-6.6 patch fails

[peabee]

patch -N -p1 < aufs6-mmap.patch patching file fs/proc/base.c Hunk 1 FAILED at 2218. 1 out of 1 hunk FAILED -- saving rejects to file fs/proc/base.c.rej

--- fs/proc/base.c
+++ fs/proc/base.c
@@ -2218,7 +2218,7 @@ static int map_files_get_link(struct dentry *dentry, struct path *path)
    rc = -ENOENT;
    vma = find_exact_vma(mm, vm_start, vm_end);
    if (vma && vma->vm_file) {
-       *path = vma->vm_file->f_path;
+       *path = vma_pr_or_file(vma)->f_path;
        path_get(path);
        rc = 0;
    }

fails because line 2217 of base.c is now:

        *path = *file_user_path(vma->vm_file);
        path_get(path);

Is there an easy fix to try? I guess the 'obvious'??? is:

*path = *file_user_path(vma_pr_or_file(vma));

[peabee]

Even after fixing the patch - there is an unrelated? compile error.....

In file included from ./include/linux/linkage.h:7,
                 from ./include/linux/fs.h:5,
                 from ./include/uapi/linux/aio_abi.h:31,
                 from ./include/linux/syscalls.h:79,
                 from fs/namespace.c:11:
fs/namespace.c:492:19: error: ‘__mnt_drop_write’ undeclared here (not in a function); did you mean ‘mnt_drop_write’?
  492 | EXPORT_SYMBOL_GPL(__mnt_drop_write);
      |                   ^~~~~~~~~~~~~~~~
./include/linux/export.h:74:23: note: in definition of macro ‘__EXPORT_SYMBOL’
   74 |         extern typeof(sym) sym;                                 \
      |                       ^~~
./include/linux/export.h:87:41: note: in expansion of macro ‘_EXPORT_SYMBOL’
   87 | #define EXPORT_SYMBOL_GPL(sym)          _EXPORT_SYMBOL(sym, "GPL")
      |                                         ^~~~~~~~~~~~~~
fs/namespace.c:492:1: note: in expansion of macro ‘EXPORT_SYMBOL_GPL’
  492 | EXPORT_SYMBOL_GPL(__mnt_drop_write);
      | ^~~~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:243: fs/namespace.o] Error 1

[sfjro]

PB:

Even after fixing the patch - there is an unrelated? compile error..... :::

Thanx for the report. Obviously aufs should follow the changes in mainline kernel. Hopefully I'll return to aufs in a few months.

In this case, kernel function __mnt_drop_write() seems to be removed. And I some replacement should be there. Aufs has to find the replacement and modify to call it.

J. R. Okajima

[tombriden]

__mnt_drop_write was renamed to mnt_put_write_access (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e15dcf77b23b8e9b9b7f3c0d4def8fe9c12c534)

There are a couple of other changes required too, after applying the patches, this is what I've done to get it working with 6.7.y (though I can't say whether this is the "right" way to fix it :) )

https://github.com/tombriden/linux/commit/14277ff6f4438ae8ae1760415fed3afb76edf2eb

[roadie2]

@tombriden Thanks very much, kernel-6.7.0 now compiles and boots without errors

[sfjro]

Tom Briden:

There are a couple of other changes required too, after applying the patches, this is what I've done to get it working with 6.7.y (though I can't say whether this is the "right" way to fix it :) )

https://github.com/tombriden/linux/commit/14277ff6f4438ae8ae1760415fed3afb76edf2eb

Thanx for the info. It must be a good help to every user.

J. R. Okajima

[peabee]

Thank you @tombriden I have also been able to compile 6.7 with your changes. The system does boot but sadly not to a workable desktop - the desktop is huge and is offset. This is with nvidia graphics and using the nouveau driver. This may of course be a 6.7 issue rather than an aufs problem....

[peabee]

Later - tried on a laptop with intel graphics and there all was fine - so does look like a Nouveau problem in 6.7

[TurboBlaze]

I am confirm I am able to boot up Porteus. More info is here https://forum.porteus.org/viewtopic.php?p=98187#p98187 Thanks for the [patch](aufs: fixes for linux-6.7.y) by Tom Briden.

[fulalas]

Thanks for the effort, guys.

I'm not sure if there's something wrong in the patches provided by @tombriden or if it's just kernel 6.7 being weird, but the memory consumption (after boot) skyrocketed for me: from 900 MB (v6.6.14) to 1.4 GB (v6.7.2).

I can easily replicate this issue by just swapping the kernel modules and keeping the whole system intact. So it's definitely something related to the kernel.

[fulalas]

Also, while compiling I noticed this:

fs/namespace.c:895:5: error: redefinition of ‘is_current_mnt_ns’
  895 | int is_current_mnt_ns(struct vfsmount *mnt)
      |     ^~~~~~~~~~~~~~~~~
fs/namespace.c:877:5: note: previous definition of ‘is_current_mnt_ns’ with type ‘int(struct vfsmount *)’
  877 | int is_current_mnt_ns(struct vfsmount *mnt)

[sfjro]

fulalas:

fs/namespace.c:895:5: error: redefinition of =E2=80=98is_current_mnt_ns=E2= =80=99 895 | int is_current_mnt_ns(struct vfsmount mnt) | ^~~~~ fs/namespace.c:877:5: note: previous definition of =E2=80=98is_current_mn= t_ns=E2=80=99 with type =E2=80=98int(struct vfsmount )=E2=80=99 877 | int is_current_mnt_ns(struct vfsmount *mnt)

Maybe the mainline kernel added a new function which has a same name of a function aufs6-base.path adds. But I couldn't find is_current_mnt_ns() in vanilla v6.7.2. What is your kernel version?

J. R. Okajima

[fulalas]

@sfjro, that was my mistake. I got confused with so many patches, hahaha! I'm sorry about that.

We hope you'll get back to the project soon.

Thanks!