mbox series

[GIT,PULL] UBI and UBIFS updates for v6.11-rc1

Message ID 896050924.123729.1722027514568.JavaMail.zimbra@nod.at
State New
Headers show
Series [GIT,PULL] UBI and UBIFS updates for v6.11-rc1 | expand

Pull-request

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

Message

Richard Weinberger July 26, 2024, 8:58 p.m. UTC
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(-)

Comments

Linus Torvalds July 28, 2024, 3:06 a.m. UTC | #1
On Fri, 26 Jul 2024 at 13:58, Richard Weinberger <richard@nod.at> wrote:
>
> This pull request contains updates (actually, just fixes) for UBI and UBIFS:

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
Richard Weinberger July 28, 2024, 7:13 a.m. UTC | #2
Linus,

----- Ursprüngliche Mail -----
> Von: "torvalds" <torvalds@linux-foundation.org>
> 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.

The issue was detected and fixed two weeks ago:
https://lore.kernel.org/linux-mtd/20240713073519.25325-1-richard@nod.at/

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
Linus Torvalds July 28, 2024, 6:04 p.m. UTC | #3
On Sun, 28 Jul 2024 at 00:13, Richard Weinberger <richard@nod.at> wrote:
>
> The issue was detected and fixed two weeks ago:
> https://lore.kernel.org/linux-mtd/20240713073519.25325-1-richard@nod.at/
>
> 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?

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

               Linus
pr-tracker-bot@kernel.org July 28, 2024, 9:02 p.m. UTC | #4
The pull request you sent on Fri, 26 Jul 2024 22:58:34 +0200 (CEST):

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/92a286e90203ce3e6c3a6d945fa36da419c3671f

Thank you!