All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Nick Desaulniers <ndesaulniers@google.com>, dave.anglin@bell.net
Cc: jejb@parisc-linux.org,
	Nathan Chancellor <natechancellor@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Pravin Shedge <pravin.shedge4linux@gmail.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-parisc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Alistair Strachan <astrachan@google.com>
Subject: Re: [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions
Date: Sat, 4 Aug 2018 00:34:19 +0200	[thread overview]
Message-ID: <1d577675-c337-d433-f235-1e46e5d56d4c@gmx.de> (raw)
In-Reply-To: <CAKwvOdmXi_EY5=sOO9tRqeoFrHjLsF9L988cGC2yjnFYBxac4w@mail.gmail.com>

On 03.08.2018 22:33, Nick Desaulniers wrote:
> On Fri, Aug 3, 2018 at 12:09 PM John David Anglin <dave.anglin@bell.net> wrote:
>>
>> On 2018-08-03 2:11 PM, Nick Desaulniers wrote:
>>> But the kernel uses the generic_THIS_IP_  *everywhere*, not parisc's
>>> custom current_text_addr().  So if this did actually break unwinding,
>>> you should have noticed by now.
>> The unwind problem was noticed.
> 
> So parisc is currently broken (doesn't unwind) due to the pervasive
> use of _THIS_IP_ (generic C) throughout the kernel?

I tested it on the 32bit kernel.
The answer is: No. Unwinding works (with and without your patch).
 
> If no, that implies this patch (generic C) causes no unwinding problems.

correct.

> If yes, that implies that the diff I posted later in this thread
> (inline assembly) is preferable, and that parisc has bigger problems
> (and probably needs to do rewrite the unwinding code to handle these
> extra labels everywhere).
> 
>> Patches were recently applied to gcc and binutils to try and fix it.
>> The gcc patch moved
>> branch tables to rodata so that the label at the head of the table
>> wasn't in text.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01804.html
>> https://sourceware.org/ml/binutils/2018-07/msg00474.html
>>
>> When I saw your suggested change, I realized there was another source of
>> text labels
>> that need linker relocations.
> 
> Thank you for the links.
> 
> On Fri, Aug 3, 2018 at 10:57 AM John David Anglin <dave.anglin@bell.net> wrote:
>> The label breaks the unwind data, not the unwind code.  So, localizing
>> the use of
>> current_text_addr() to the parisc unwind code doesn't help.
> 
> Have you confirmed that applying my patch breaks *the ability to
> unwind correctly*?

I tested your patch (on 32bit).
Your patch does not break anything.

> It looks like return_address() is used in
> ftrace_return_address(), so I assume you can boot a kernel with my
> patch applied, and CONFIG_FTRACE=y, then run:
> 
> $ sudo trace-cmd record -p function date
> $ trace-cmd report | grep date- | less
> 
> and see if the stacks aren't unwound or look messed up.

I faced issues with trace-cmd, but calling ftracing functions manually worked.

So, your patch is basically OK and doesn't break anything.
But I agree with Dave that Andrew, that THIS_IP is ugly.

Helge

  reply	other threads:[~2018-08-03 22:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01 18:22 [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions Nick Desaulniers
2018-08-01 20:10 ` John David Anglin
2018-08-01 20:52   ` Nick Desaulniers
2018-08-01 21:27     ` John David Anglin
2018-08-01 21:49       ` Nick Desaulniers
2018-08-01 22:12         ` John David Anglin
2018-08-01 22:18           ` Nick Desaulniers
2018-08-02  0:49             ` John David Anglin
2018-08-02 20:31               ` Nick Desaulniers
2018-08-03 17:57                 ` John David Anglin
2018-08-03 18:11                   ` Nick Desaulniers
2018-08-03 19:09                     ` John David Anglin
2018-08-03 20:33                       ` Nick Desaulniers
2018-08-03 22:34                         ` Helge Deller [this message]
2018-08-07 18:11                           ` Nick Desaulniers
2018-08-07 20:30                             ` Helge Deller
2018-08-07 21:29                               ` Nick Desaulniers

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=1d577675-c337-d433-f235-1e46e5d56d4c@gmx.de \
    --to=deller@gmx.de \
    --cc=astrachan@google.com \
    --cc=dave.anglin@bell.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jejb@parisc-linux.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=pravin.shedge4linux@gmail.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.