linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe LEROY <christophe.leroy@c-s.fr>,
	Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Alastair D'Silva <alastair@d-silva.org>,
	Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
	Balbir Singh <bsingharora@gmail.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Cyril Bur <cyrilbur@gmail.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Joe Perches <joe@perches.com>,
	Michael Neuling <mikey@neuling.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	Simon Guo <wei.guo.simon@gmail.com>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	"Tobin C . Harding" <me@tobin.cc>,
	linuxppc-dev@lists.ozlabs.org,
	Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH v4 5/6] powerpc: Add show_user_instructions()
Date: Fri, 03 Aug 2018 18:44:54 +1000	[thread overview]
Message-ID: <87pnyzhm9l.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <69cf990b-d4aa-97e7-be3b-7936caa91688@c-s.fr>

Christophe LEROY <christophe.leroy@c-s.fr> writes:
> Le 03/08/2018 à 02:42, Murilo Opsfelder Araujo a écrit :
>> Hi, Christophe.
>> On Thu, Aug 02, 2018 at 07:26:20AM +0200, Christophe LEROY wrote:
>>> Le 01/08/2018 à 23:33, Murilo Opsfelder Araujo a écrit :
>>>> show_user_instructions() is a slightly modified version of
>>>> show_instructions() that allows userspace instruction dump.
>>>>
>>>> This will be useful within show_signal_msg() to dump userspace
>>>> instructions of the faulty location.
>>>>
>>>> Here is a sample of what show_user_instructions() outputs:
>>>>
>>>>     pandafault[10850]: code: 4bfffeec 4bfffee8 3c401002 38427f00 fbe1fff8 f821ffc1 7c3f0b78 3d22fffe
>>>>     pandafault[10850]: code: 392988d0 f93f0020 e93f0020 39400048 <99490000> 39200000 7d234b78 383f0040
>>>>
>>>> The current->comm and current->pid printed can serve as a glue that
>>>> links the instructions dump to its originator, allowing messages to be
>>>> interleaved in the logs.
>>>>
>>>> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>>>> index e9533b4d2f08..364645ac732c 100644
>>>> --- a/arch/powerpc/kernel/process.c
>>>> +++ b/arch/powerpc/kernel/process.c
>>>> @@ -1299,6 +1299,46 @@ static void show_instructions(struct pt_regs *regs)
>>>>    	pr_cont("\n");
>>>>    }
>>>> +void show_user_instructions(struct pt_regs *regs)
>>>> +{
>>>> +	int i;
>>>> +	const char *prefix = KERN_INFO "%s[%d]: code: ";
>>>> +	unsigned long pc = regs->nip - (instructions_to_print * 3 / 4 *
>>>> +					sizeof(int));
>>>> +
>>>> +	printk(prefix, current->comm, current->pid);
>>>
>>> Why not use pr_info() and remove KERN_INFO from *prefix ?
>> 
>> Because it doesn't compile:
>> 
>>    arch/powerpc/kernel/process.c:1317:10: error: expected ‘)’ before ‘prefix’
>>      pr_info(prefix, current->comm, current->pid);
>>              ^
>>    ./include/linux/printk.h:288:21: note: in definition of macro ‘pr_fmt’
>>     #define pr_fmt(fmt) fmt
>>                       ^
>> 
>> `pr_info(prefix, ...)` expands to `printk("\001" "6" prefix, ...)`,
>> which is an invalid string concatenation.
>> 
>> `pr_info("%s", ...)` expands to `printk("\001" "6" "%s", ...)`, which is
>> valid.
>
> Then what about using directly:
>
> pr_info("%s[%d]: code: ", ...);

Yeah that's better, I'll fix it up when applying.

>>>> +#if !defined(CONFIG_BOOKE)
>>>> +		/* If executing with the IMMU off, adjust pc rather
>>>> +		 * than print XXXXXXXX.
>>>> +		 */
>>>> +		if (!(regs->msr & MSR_IR))
>>>> +			pc = (unsigned long)phys_to_virt(pc);
>>>
>>> Shouldn't this be done outside of the loop, only once ?
>> 
>> I don't think so.
>> 
>> pc gets incremented at the bottom of the loop:
>> 
>>    pc += sizeof(int);
>> 
>> Adjusting pc is necessary at each iteration.  Leaving this block inside
>> the loop seems correct.
>
> This looks pretty strange.
> The first time, pc is a physical address, that you change to a virtual 
> address. Then when you increment it it is still a virtual address.
> So when you call phys_to_virt(pc) for the second time, pc is already a 
> virt address, so what happens indeed ?

Yeah that's a bit fishy.

On 64-bit it works because phys_to_virt() == __va() which is:

  #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET))

ie. it uses bitwise or, so __va(__va(x)) == __va(x).

But it looks like on 32-bit it's going to do the wrong thing. Do we ever
actually hit that case though, I'm not sure?


However for this patch I'll just remove the whole thing, because we
don't expect to be dumping user instructions in realmode.

cheers

  reply	other threads:[~2018-08-03  8:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01 21:33 [PATCH v4 0/6] powerpc: Modernize unhandled signals message Murilo Opsfelder Araujo
2018-08-01 21:33 ` [PATCH v4 1/6] powerpc/traps: Print unhandled signals in a separate function Murilo Opsfelder Araujo
2018-08-08 14:26   ` [v4, " Michael Ellerman
2018-08-01 21:33 ` [PATCH v4 2/6] powerpc/traps: Use an explicit ratelimit state for show_signal_msg() Murilo Opsfelder Araujo
2018-08-01 21:33 ` [PATCH v4 3/6] powerpc/traps: Use %lx format in show_signal_msg() Murilo Opsfelder Araujo
2018-08-01 21:33 ` [PATCH v4 4/6] powerpc/traps: Print VMA for unhandled signals Murilo Opsfelder Araujo
2018-08-01 21:33 ` [PATCH v4 5/6] powerpc: Add show_user_instructions() Murilo Opsfelder Araujo
2018-08-02  5:26   ` Christophe LEROY
2018-08-03  0:42     ` Murilo Opsfelder Araujo
2018-08-03  1:22       ` Joe Perches
2018-08-03  6:38       ` Christophe LEROY
2018-08-03  8:44         ` Michael Ellerman [this message]
2018-08-03 11:31           ` Murilo Opsfelder Araujo
2018-08-10  9:29             ` Christophe LEROY
2018-08-10 18:08               ` Murilo Opsfelder Araujo
2018-08-01 21:33 ` [PATCH v4 6/6] powerpc/traps: Show instructions on exceptions Murilo Opsfelder Araujo

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=87pnyzhm9l.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=alastair@d-silva.org \
    --cc=andrew.donnellan@au1.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=cyrilbur@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=me@tobin.cc \
    --cc=mikey@neuling.org \
    --cc=muriloo@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=segher@kernel.crashing.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=wei.guo.simon@gmail.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).