public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Santosh Sivaraj <santosh@fossix.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	James Bottomley <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>, Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jessica Yu <jeyu@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers
Date: Wed, 27 Sep 2017 06:26:44 +0000	[thread overview]
Message-ID: <87y3p0ejx7.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20170922053404.3zpfpwetabjut2er@santosiv.in.ibm.com>

Santosh Sivaraj <santosh@fossix.org> writes:

> * Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote (on 2017-09-20 16:29:02 +0000):
>
>>         Hello
>> 
>>         RFC
>> 
>>         On some arches C function pointers are indirect and point to
>> a function descriptor, which contains the actual pointer to the code.
>> This mostly doesn't matter, except for cases when people want to print
>> out function pointers in symbolic format, because the usual '%pS/%ps'
>> does not work on those arches as expected. That's the reason why we
>> have '%pF/%pf', but since it's here because of a subtle ABI detail
>> specific to some arches (ppc64/ia64/parisc64) it's easy to misuse
>> '%pF/%pf' and '%pS/%ps' (see [1], for example).
>> 
>>         This patch set attempts to move ia64/ppc64/parisc64 C function
>> pointer ABI details out of printk() to arch code. Function dereference
>> code now checks if a pointer belongs to a .opd ELF section and dereferences
>> that pointer only if it does. The kernel and modules have their own .opd
>> sections that's why I use two different ARCH functions: for kernel and
>> for module pointer dereference.
>> 
>>         I planned to remove dereference_function_descriptor() entirely,
>> but then I discovered a bunch other uses cases (kgdbts, init/main.c,
>> extable, etc.), so I decided to keep dereference_function_descriptor()
>> around because the main point of this patch set is to deprecate %pF/%pf.
>> But at the same time, I think I can go further and handle both kernel
>> and module descriptor dereference in dereference_function_descriptor().
>> We need a module pointer for module .opd check, so that will come at an
>> extra cost of module lookup (may be there will some other issues along
>> the way, haven't checked it).
>> 
>> Right now we've got:
>> 
>> - dereference_function_descriptor(addr)
>>         a generic (old) function. it simply attempts to dereference
>>         whatever pointer we give it.
>> 
>> - dereference_kernel_function_descriptor(addr)
>>         dereferences a kernel pointer if it's within the kernel's .opd
>>         section.
>> 
>> - dereference_module_function_descriptor(module, addr)
>>         dereference a module pointer if it's within the module's .opd
>>         section.
>> 
>> 
>> *** A BIG NOTE ***
>>         I don't own ia64/ppc64/parisc64 hardware, so the patches are not
>>         tested. Sorry about that!
>
> Tested patch series on ppc64 sucessfully.
>
> You may add tested by to the series.
>
> Tested-by: Santosh Sivaraj <santosh@fossix.org>

Thanks Santosh.

I also gave it a quick spin. I'll give you an ack for the powerpc changes.

Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)


Thanks for cleaning this up Sergey.

cheers

  parent reply	other threads:[~2017-09-27  6:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-20 16:29 [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 1/7] switch dereference_function_descriptor() to `unsigned long' Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 2/7] sections: split dereference_function_descriptor() Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 3/7] ia64: Add .opd based function descriptor dereference Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 4/7] powerpc64: " Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 5/7] parisc64: " Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 6/7] symbol lookup: use new kernel and module dereference functions Sergey Senozhatsky
2017-09-21  9:38   ` Sergey Senozhatsky
2017-09-20 16:29 ` [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning Sergey Senozhatsky
2017-09-20 17:38   ` Joe Perches
2017-09-20 17:53     ` Helge Deller
2017-09-20 18:24       ` Joe Perches
2017-09-21  7:43         ` Sergey Senozhatsky
2017-09-21  0:27     ` Sergey Senozhatsky
2017-09-21  2:28       ` Joe Perches
2017-09-20 16:29 ` Sergey Senozhatsky
2017-09-20 16:33   ` Sergey Senozhatsky
2017-09-20 20:14 ` [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers Helge Deller
2017-09-21  0:30   ` Sergey Senozhatsky
2017-09-22  5:46 ` Santosh Sivaraj
2017-09-22  8:00   ` Sergey Senozhatsky
2017-09-22 16:48     ` Luck, Tony
2017-09-25  7:05       ` Sergey Senozhatsky
2017-09-25 16:29         ` Luck, Tony
2017-09-25 17:05           ` Helge Deller
2017-09-27  5:01         ` Michael Ellerman
2017-10-19 14:11           ` Sergey Senozhatsky
2017-09-27  6:26   ` Michael Ellerman [this message]
2017-09-28  1:11     ` Sergey Senozhatsky

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=87y3p0ejx7.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=deller@gmx.de \
    --cc=fenghua.yu@intel.com \
    --cc=jejb@parisc-linux.org \
    --cc=jeyu@kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=santosh@fossix.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tony.luck@intel.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