UBI and UBIFS updates for v6.11-rc1

Linus,

The following changes since commit 22a40d14b572deb80c0648557f4bd502d7e83826:

Linux 6.10-rc6 (2024-06-30 14:40:44 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git tags/ubifs-for-linus-6.11-rc1

for you to fetch changes up to 054fd15984454f031611d6c63675fc578aad0cb1:

ubifs: add check for crypto_shash_tfm_digest (2024-07-12 22:01:09 +0200)

----------------------------------------------------------------
This pull request contains updates (actually, just fixes) for UBI and UBIFS:

- Many fixes for power-cut issues by Zhihao Cheng
- Another ubiblock error path fix
- Misc fixes all over the place

----------------------------------------------------------------
Arnd Bergmann (1):
mtd: ubi: avoid expensive do_div() on 32-bit machines

Ben Hutchings (1):
mtd: ubi: Restore missing cleanup on ubi_init() failure path

Chen Ni (1):
ubifs: add check for crypto_shash_tfm_digest

Fedor Pchelkin (1):
ubi: eba: properly rollback inside self_check_eba

Jeff Johnson (1):
ubifs: fix kernel-doc warnings

Li Nan (1):
ubi: block: fix null-pointer-dereference in ubiblock_create()

Ricardo B. Marliere (1):
mtd: ubi: make ubi_class constant

ZhaoLong Wang (1):
ubifs: correct UBIFS_DFS_DIR_LEN macro definition and improve code clarity

Zhihao Cheng (10):
ubifs: Fix unattached xattr inode if powercut happens after deleting
ubifs: Don't add xattr inode into orphan area
Revert "ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path"
ubifs: Remove insert_dead_orphan from replaying orphan process
ubifs: Fix adding orphan entry twice for the same inode
ubifs: Move ui->data initialization after initializing security
ubifs: Fix space leak when powercut happens in linking tmpfile
ubifs: Fix unattached inode when powercut happens in creating
ubifs: dbg_orphan_check: Fix missed key type checking
ubifs: Fix inconsistent inode size when powercut happens during appendant writing

 drivers/mtd/ubi/block.c |   7 ++-
 drivers/mtd/ubi/build.c |   7 ++-
 drivers/mtd/ubi/debug.c |   4 +-
 drivers/mtd/ubi/eba.c   |   3 +-
 drivers/mtd/ubi/nvmem.c |   6 +-
 drivers/mtd/ubi/ubi.h   |   4 +-
 fs/ubifs/compress.c     |   2 +
 fs/ubifs/debug.c        |   4 +-
 fs/ubifs/debug.h        |   7 ++-
 fs/ubifs/dir.c          |  91 ++++++++++++++++------------
 fs/ubifs/file.c         |   2 +-
 fs/ubifs/find.c         |   8 +--
 fs/ubifs/journal.c      |  16 +++--
 fs/ubifs/lprops.c       |   2 +-
 fs/ubifs/lpt.c          |   1 +
 fs/ubifs/master.c       |   5 +-
 fs/ubifs/orphan.c       | 155 ++++++++----------------------------------------
 fs/ubifs/replay.c       |   1 +
 fs/ubifs/sysfs.c        |   6 +-
 fs/ubifs/ubifs.h        |  14 +----
 fs/ubifs/xattr.c        |   2 +-
 21 files changed, 134 insertions(+), 213 deletions(-)

Does nobody actually check the build output?

WARNING: modpost: drivers/mtd/ubi/ubi: section mismatch in
reference: ubi_init+0x170 (section: .init.text) -> ubiblock_exit (section: .exit.text)

and yes, this may be harmless on x86 (and several other architectures), because the exit.text is dropped at runtime because dropping it at link time will cause problems for altinstructions.

BUT.

The warning is very real, because on *other* architectures, the EXIT_TEXT sections may never be linked in at all, because something that is built-in never gets unloaded, so it never has a module exit.

So __exit literally exists so that the code can be thrown away when not used.

And now you're calling it from a non-exit place.

End result: the warning exists for a reason, and it looks like commit 72f3d3daddd7 ("mtd: ubi: Restore missing cleanup on ubi_init() failure path") is just broken.

I could try to fix this up in the merge, but honestly, the fact that apparently nobody bothered to even look at the new warning means that I just consider this whole pull completely buggered.

I refuse to pull garbage that our build system very clearly warns about.

Linus

Linus,

----- Ursprüngliche Mail -----

The issue was detected and fixed two weeks ago:
https://lore.kernel.org/linux-mtd/[email protected]/

But I forgot to include my very own patch.
So, the failure is totally on my side, I'm sorry for that.

Do you allow me sending an updated pull requested?

Thanks,
//richard

If you do it quickly. The rc1 goes out in a couple of hours.

Linus