netdev - Re: [PATCH net-next v2 3/3] ipv6: fix checkpatch errors of "foo*" and "foo * bar"

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: <20140328181657.GE11063@order.stressinduktion.org>
Date:	Fri, 28 Mar 2014 19:16:57 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	David Miller <davem@...emloft.net>,
	"joe@...ches.com" <joe@...ches.com>,
	"wangyufen@...wei.com" <wangyufen@...wei.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 3/3] ipv6: fix checkpatch errors of "foo*" and "foo * bar"

On Fri, Mar 28, 2014 at 10:54:13AM +0000, David Laight wrote:
> From: Hannes Frederic Sowa
> > > > Perhaps all the __inline__ uses could be changed to inline too.
> > >
> > > Or rather, deleted completely, this is a *.c file after all.
> 
> Personally I wouldn't do a blanket removal of 'inline' from .c files.
> But I will agree that some large functions have been inappropriately
> marked 'inline'.

Does inline keyword actually make a difference in case the function is
static? I guess not (except for function profiling if a prologue should
get included, thus the change in visibility for tracing).

> The complier doesn't always make the right guess.
> 
> > Smart-arsing:
> > 
> > Removing inline keyword makes the function visible to tracing if
> > it didn't get inlined. I think this is a nice side-effect because debug
> > kernels are often compiled with less aggressive inlining options
> > (readable asm kconfig option).
> 
> I want to debug the same binary that will run in production.
> Dodgy code can be affected by all sorts of compiler options.

I agree. But status quo is that your binaries look very different if
you have DEBUG_SECTION_MISMATCH or READABLE_ASM defined.

The change in tracing visibility is already the case if you (like
me) compile your kernel with DEBUG_SECTION_MISMATCH wich enables
no-inline-functions-called-once, because this option does also not
respect inline keyword.

> The best one was a problem with the shell deleting the last
> character of a $(...) substitution.
> The code ran off the beginning of an on-stack buffer when trimming
> trailing '\n' and 'found' a '\n' byte lurking in the unwritten
> stack (this was well down the stack, and had been written much,
> much earlier).
> The error was only ever likely on big-endian systems (the msb of
> a word is less likely to be '\n'.

Heh. :)

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html