search

koverstreet / bcachefs

Other
670 stars 69 forks source link

Commits b2827b1 "mm: vmalloc: Enable memory allocation profiling" and 400b3ab "memory allocation profiling: more hooking" break compiling #567

Closed hardfalcon closed 1 year ago

hardfalcon commented 1 year ago

Some change(s) between commit 6059c459e8b13d6ae25efc4d0169edc4e0bcb867 and commit 1320de26ee1fb9ebdd7c1b1752af53852512e823 break compiling the kernel on Archlinux Testing with GCC 131.1 for me in several places. My primary suspect is commit b2827b1f6d4bb1a067c022f77db49be932591b5c.

I'm using kernel 6.4.3 with the following changes added on top:

I know this sounds like "probably an issue with one of all those other patches". However, I've successfully built a functioning kernel with the very same changes/patches just a few hours before (the only differences being the kernel 6.4.3 changes taken from the stable queue instead of the kernel tarball, because 6.4.3 was not released yet when I started the first/successfull compile run, and the rebased bcachefs patch being derived from the bcachefs-testing branch @ commit 1320de26ee1fb9ebdd7c1b1752af53852512e823 instead of the bcachefs-testing branch @ commit 6059c459e8b13d6ae25efc4d0169edc4e0bcb867

Thereforce, I'm reaonably confident that these issues are caused by some change(s) between commit 6059c459e8b13d6ae25efc4d0169edc4e0bcb867 and commit 1320de26ee1fb9ebdd7c1b1752af53852512e823 break compiling the kernel for me in several places, most likely commit b2827b1f6d4bb1a067c022f77db49be932591b5c.

I've attached a combined stdout/stderr log, and a tarball containing the PKGBUILD and all patches I've used. stdouterrcombined.log linux-hardened-6.4.3.hardened0-0.src.tar.gz

hardfalcon commented 1 year ago

Update: Dropping commit b2827b1f6d4bb1a067c022f77db49be932591b5c was part of the solution but not enough to get the kernel to compile. I also had to drop commit 400b3ab05c646cc14a8953f72c7ae2218d92da87 for the compiling to actually succeed.

When I only drop commit b2827b1f6d4bb1a067c022f77db49be932591b5c but keep commit 400b3ab05c646cc14a8953f72c7ae2218d92da87, modpost complains about kmemdup being undefined in various filesystem modules:

  LD [M]  drivers/infiniband/hw/hfi1/hfi1.o
  AR      built-in.a
  AR      vmlinux.a
  LD      vmlinux.o
  OBJCOPY modules.builtin.modinfo
  GEN     modules.builtin
  GEN     .vmlinux.objs
  MODPOST Module.symvers
ERROR: modpost: "kmemdup" [fs/fscache/fscache.ko] undefined!
ERROR: modpost: "kmemdup" [fs/reiserfs/reiserfs.ko] undefined!
ERROR: modpost: "kmemdup" [fs/ext4/ext4.ko] undefined!
ERROR: modpost: "kmemdup" [fs/nfs/nfs.ko] undefined!
ERROR: modpost: "kmemdup" [fs/nfs/blocklayout/blocklayoutdriver.ko] undefined!
ERROR: modpost: "kmemdup" [fs/nfsd/nfsd.ko] undefined!
ERROR: modpost: "kmemdup" [fs/smb/client/cifs.ko] undefined!
ERROR: modpost: "kmemdup" [fs/smb/server/ksmbd.ko] undefined!
ERROR: modpost: "kmemdup" [fs/ntfs3/ntfs3.ko] undefined!
ERROR: modpost: "kmemdup" [fs/jffs2/jffs2.ko] undefined!
WARNING: modpost: suppressed 269 unresolved symbol warnings because there were too many)
WARNING: modpost: modpost: Found 55299 writable function pointers.
To see full details build your kernel with:
'make CONFIG_DEBUG_WRITABLE_FUNCTION_POINTERS_VERBOSE=y'
make[1]: *** [scripts/Makefile.modpost:137: Module.symvers] Error 1
make: *** [Makefile:1978: modpost] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

//EDIT: Due to a copy-paste mistake, I had written that I had dropped commit c4f23a088fa3f23700a177307e388365394e9e26. This is not true, I had instead dropped commit 400b3ab05c646cc14a8953f72c7ae2218d92da87.

hardfalcon commented 1 year ago

See also https://github.com/koverstreet/bcachefs/issues/566

koverstreet commented 1 year ago

Did you try a make clean?

hardfalcon commented 1 year ago

I always build in a clean chroot using the procedure described here: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot#Convenience_way

I do use this with an additional custom repo, but I'm reasonably confident that that repo isn't relevant for this bug because, as described above, essentially the same kernel/codebase built cleanly last night when I used a bcachefs patch created from running git diff on a rebase of your bcachefs-testing branch @ 6059c459e8b13d6ae25efc4d0169edc4e0bcb867 vs. a vanilla kernel 6.4.2, and I had not added any updates to that repo in the meantime, aside from the new kernel.

//EDIT: To avoid any misunderstandings: "I always build in a clean chroot" also involves that whole chroot being deleted and completely rebuilt every for every compile run I do. I do these compile runs in order to package the resulting kernel for my custom repo, and I don't ever want to have any package in that repo that was not built inside a clean chroot.

Mjasnik commented 1 year ago

I have the same compilation error and I always cleanbuild the package.

In file included from fs/cramfs/uncompress.c:23:
fs/cramfs/uncompress.c: In function ‘cramfs_uncompress_init’:
./include/linux/vmalloc.h:141:33: error: implicit declaration of function ‘alloc_hooks’ [;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-function-declaration
-Werror=implicit-function-declaration;
]
  141 | #define vmalloc(...)            alloc_hooks(vmalloc_noprof(__VA_ARGS__))
      |                                 ^~~~~~~~~~~
fs/cramfs/uncompress.c:62:36: note: in expansion of macro ‘vmalloc’
   62 |                 stream.workspace = vmalloc(zlib_inflate_workspacesize());
      |                                    ^~~~~~~
fs/cramfs/uncompress.c:62:34: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wint-conversion
-Wint-conversion;
]
   62 |                 stream.workspace = vmalloc(zlib_inflate_workspacesize());
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:252: fs/cramfs/uncompress.o] Error 1
make[2]: *** [scripts/Makefile.build:494: fs/cramfs] Error 2
make[2]: *** Waiting for unfinished jobs....

In ArchLinux that's easy, makepkg -sfc

My build routine is as follows:

  1. delete build dir, all of it
  2. pull latest changes from linux-stable
  3. export git to build dir
  4. apply PDS (CPU scheduler patches) in build dir
  5. pull latest changes from bcachefs
  6. get bcachefs patch and apply it to build dir
  7. compile in build dir

This way git always stays untouched and everything regarding compilation resides only in build dir.

hardfalcon commented 1 year ago

@koverstreet: FYI, this is still broken as of 443149436a2a44303efe323b76678f5dd5d6f9bd (rebased onto kernel 6.4.4):

  CC [M]  drivers/staging/media/ipu3/ipu3-v4l2.o
In file included from ./include/linux/printk.h:564,
                 from ./include/linux/kernel.h:30,
                 from drivers/staging/media/atomisp/pci/hmm/hmm.c:23:
drivers/staging/media/atomisp/pci/hmm/hmm.c: In function ‘__hmm_alloc’:
drivers/staging/media/atomisp/pci/hmm/hmm.c:208:41: error: ‘vmalloc’ undeclared (first use in this function); did you mean ‘mm_alloc’?
  208 |                 bo->start, bytes, type, vmalloc);
      |                                         ^~~~~~~
./include/linux/dynamic_debug.h:222:29: note: in definition of macro ‘__dynamic_func_call_cls’
  222 |                 func(&id, ##__VA_ARGS__);                       \
      |                             ^~~~~~~~~~~
./include/linux/dynamic_debug.h:248:9: note: in expansion of macro ‘_dynamic_func_call_cls’
  248 |         _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
      |         ^~~~~~~~~~~~~~~~~~~~~~
./include/linux/dynamic_debug.h:271:9: note: in expansion of macro ‘_dynamic_func_call’
  271 |         _dynamic_func_call(fmt, __dynamic_dev_dbg,              \
      |         ^~~~~~~~~~~~~~~~~~
./include/linux/dev_printk.h:155:9: note: in expansion of macro ‘dynamic_dev_dbg’
  155 |         dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
      |         ^~~~~~~~~~~~~~~
drivers/staging/media/atomisp/pci/hmm/hmm.c:207:9: note: in expansion of macro ‘dev_dbg’
  207 |         dev_dbg(atomisp_dev, "pages: 0x%08x (%zu bytes), type: %d, vmalloc %p\n",
      |         ^~~~~~~
drivers/staging/media/atomisp/pci/hmm/hmm.c:208:41: note: each undeclared identifier is reported only once for each function it appears in
  208 |                 bo->start, bytes, type, vmalloc);
      |                                         ^~~~~~~
./include/linux/dynamic_debug.h:222:29: note: in definition of macro ‘__dynamic_func_call_cls’
  222 |                 func(&id, ##__VA_ARGS__);                       \
      |                             ^~~~~~~~~~~
./include/linux/dynamic_debug.h:248:9: note: in expansion of macro ‘_dynamic_func_call_cls’
  248 |         _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
      |         ^~~~~~~~~~~~~~~~~~~~~~
./include/linux/dynamic_debug.h:271:9: note: in expansion of macro ‘_dynamic_func_call’
  271 |         _dynamic_func_call(fmt, __dynamic_dev_dbg,              \
      |         ^~~~~~~~~~~~~~~~~~
./include/linux/dev_printk.h:155:9: note: in expansion of macro ‘dynamic_dev_dbg’
  155 |         dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
      |         ^~~~~~~~~~~~~~~
drivers/staging/media/atomisp/pci/hmm/hmm.c:207:9: note: in expansion of macro ‘dev_dbg’
  207 |         dev_dbg(atomisp_dev, "pages: 0x%08x (%zu bytes), type: %d, vmalloc %p\n",
      |         ^~~~~~~
  CC [M]  drivers/platform/chrome/cros_ec_lpc.o
make[5]: *** [scripts/Makefile.build:252: drivers/staging/media/atomisp/pci/hmm/hmm.o] Error 1
make[4]: *** [scripts/Makefile.build:494: drivers/staging/media/atomisp] Error 2
make[4]: *** Waiting for unfinished jobs....

In case it's relevant or it helps you tracking down when/where this issue is originating from: I have tried building a kernel with bcachefs support like a dozen times this week alone, each time using the latest state of your bcachefs-testing branch, rebased onto the latest state of Greg-KH's linux-6.4.y branch, and it consistently failed each and every time with error messages realting to the changed/hooked alloc functions being used by "non-bcachefs" modules.

hardfalcon commented 1 year ago

I was on holiday for a few weeks, so I haven't been able to follow the changes here as closely, but it seems that at least as of commit 07bb798f7d25d28978a3defc89863aab3409dc1a, this issue has been solved.