linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Yue Haibing <yuehaibing@huawei.com>,
	sergey.senozhatsky@gmail.com, andriy.shevchenko@linux.intel.com,
	geert+renesas@glider.be, me@tobin.cc,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Joe Perches <joe@perches.com>
Subject: Re: [PATCH -next] lib/vsprintf: Make function pointer_string static
Date: Mon, 29 Apr 2019 10:39:25 -0400	[thread overview]
Message-ID: <20190429103925.6233e45f@gandalf.local.home> (raw)
In-Reply-To: <20190429143037.3qu5fzdo6g26rsmf@pathway.suse.cz>


[ added Joe ]

On Mon, 29 Apr 2019 16:30:37 +0200
Petr Mladek <pmladek@suse.com> wrote:

> On Mon 2019-04-29 09:13:20, Steven Rostedt wrote:
> > On Mon, 29 Apr 2019 13:08:01 +0200
> > Petr Mladek <pmladek@suse.com> wrote:
> >   
> > > > Looks like commit "vsprintf: Do not check address of well-known
> > > > strings" removed the: "static noinline_for_stack"
> > > > 
> > > > Does pointer_string() need that still?    
> > > 
> > > Heh, it was removed by mistake and well hidden in the diff.
> > > 
> > > I have pushed Yue's fix into printk.git, branch
> > > for-5.2-vsprintf-hardening
> > > 
> > > Thanks for the patch.  
> > 
> > But doesn't it still need the "noinline_for_stack", that doesn't look
> > like it changed.  
> 
> 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.

Although the commit you posted is back in 2010, and compilers and I
think even our stack size has changed since then. This may not be a
critical issue today, and just making it static and letting the
compiler decide might be the right solution.

Let's add Yue's patch as is for now, and perhaps revisit this as a
separate thread.

-- Steve

> 
> It is evidently useful in some cases. But I somehow doubt
> that it really makes things better when used everywhere.
> Therefore I have got a bit relaxed and omitted it in most
> newly added functions that did not affect the results.
> 
> They are the same before and after the patchset:
> 
> pmladek@pathway:/prace/kernel/linux-printk> objdump -d lib/vsprintf.o | perl scripts/checkstack.pl
> 0x00000e12 symbol_string [vsprintf.o]:                  248
> 0x00000e6d symbol_string [vsprintf.o]:                  248
> 0x000012fb ip6_addr_string_sa [vsprintf.o]:             112
> 0x00001415 ip6_addr_string_sa [vsprintf.o]:             112
> 0x000028c6 resource_string.isra.9 [vsprintf.o]:         104
> 0x00002964 resource_string.isra.9 [vsprintf.o]:         104
> 
> 
> Would you like to fix this clearly, for example, rebase and
> put both "static noinline_for_stack" back or add yet
> another commit or?
> 
> IMHO, it is not too important. Anyway, I am open for any
> advice. I do not want to create more mess.
> 
> Best Regards,
> Petr


  reply	other threads:[~2019-04-29 14:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26 16:46 [PATCH -next] lib/vsprintf: Make function pointer_string static Yue Haibing
2019-04-26 17:02 ` Steven Rostedt
2019-04-29 11:08   ` Petr Mladek
2019-04-29 13:13     ` Steven Rostedt
2019-04-29 14:30       ` Petr Mladek
2019-04-29 14:39         ` Steven Rostedt [this message]
2019-04-29 16:42           ` Joe Perches
2019-04-30  8:42             ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190429103925.6233e45f@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=geert+renesas@glider.be \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@tobin.cc \
    --cc=pmladek@suse.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).