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 |
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
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
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
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!