linux-kernel - Re: [PATCH] mutex: make mutex_lock

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]

Date:	Thu, 22 Oct 2015 17:09:59 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Liam Girdwood <lgirdwood@...il.com>,
	linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	akpm@...ux-foundation.org, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function

On Thu, Oct 22, 2015 at 05:02:45PM +0200, Arnd Bergmann wrote:
> On Tuesday 13 October 2015 23:46:35 Arnd Bergmann wrote:
> > On Tuesday 13 October 2015 22:38:12 Peter Zijlstra wrote:
> > > A quick grep shows a large amount of trivial code that optimizers will
> > > still happily throw away, but it should be verified that this does not
> > > result in pointless code generation.
> > 
> > Indeed, I'm seeing a tiny code growth with ARM multi_v7_defconfig when
> > my patch is applied, as the image (according to size -A) grows from
> > 13740187 bytes to 13740283, all of it in .text of two drivers (i2c-core
> > and three files of bluetooth.ko).
> 
> 
> Did we actually reach any conclusion here? We still get the warnings
> in the regulator code in linux-next, and I'd like to see either this
> patch ("mutex: make mutex_lock_nested an inline function") or
> "regulator: core: avoid unused variable warning" get merged.
> 
> We could also remove the two functions again, as they are still
> unused and we are getting closer to the merge window.

Hmm, I was sure I send a reply, but I cannot even find it in my own sent
folder so who knows.

My current preference is to keep the thing a macro and work around it in
the usage site because while these warns are annoying, they're at least
visible. Whereas, with an inline, code bloat is entirely silent. Even if
the sites you found are harmless, there's no saying what the future will
bring etc..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/