linux-kernel - Re: [GIT PULL] UBI and UBIFS updates for v6.11-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2116767413.129257.1722150789677.JavaMail.zimbra@nod.at>
Date: Sun, 28 Jul 2024 09:13:09 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: torvalds <torvalds@...ux-foundation.org>
Cc: linux-mtd <linux-mtd@...ts.infradead.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] UBI and UBIFS updates for v6.11-rc1

Linus,

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