linux-kernel - Re: [PATCH -next] lib/vsprintf: Make function pointer

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] [day] [month] [year] [list]

Date:   Tue, 30 Apr 2019 10:42:31 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Yue Haibing <yuehaibing@...wei.com>,
        sergey.senozhatsky@...il.com, andriy.shevchenko@...ux.intel.com,
        geert+renesas@...der.be, me@...in.cc, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH -next] lib/vsprintf: Make function pointer_string static

On Mon 2019-04-29 09:42:30, Joe Perches wrote:
> On Mon, 2019-04-29 at 10:39 -0400, Steven Rostedt wrote:
> > [ added Joe ]
> > > Good question. I have just double checked it. And pointer_string() with
> > > "noinline_for_stack" does not make any difference in the stack
> > > usage here.
> > > 
> > > I actually played with this before:
> > > 
> > > "noinline_for_stack" is a black magic added by
> > > the commit cf3b429b03e827c7180 ("vsprintf.c: use noinline_for_stack").
> > 
> > From what I understand, "noinline_for_stack" is just noinline and the
> > "for_stack" part is just to document that the noinline is used for
> > stack purposes. If the compiler doesn't inline the function without the
> > noinline, then it wont make any difference.
> > 
> > The point was to not inline the function because it can be used in
> > stack critical areas, and that it's better to do the call than to
> > increase the stack.
> 
> It was added because of %pV is recursive and recursive
> functions can eat
> a lot of stack.
> 
> Using noinline_for_stack was just a bit more self-documenting.
> 
> I do still think it's a useful notation.

I understand the problem and noinline_for_stack improved some
paths definitely.

On the other hand, the call instruction uses the stack as well.
Note that many of the annotated functions have 5 parameters.

I believe that some of the annotated functions might get inlined
with a lower stack usage in the caller than what is needed
by the call.

The problem is that it depends on the used compiler, optimization,
and architecture. I personally do not want to invest much time
into optimizing this unless people report real life problems.

Best Regards,
Petr