From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
James Bottomley <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
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: [PATCHv3 2/7] sections: split dereference_function_descriptor()
Date: Wed, 04 Oct 2017 09:00:43 +0000 [thread overview]
Message-ID: <20171004090043.GD20084@pathway.suse.cz> (raw)
In-Reply-To: <20170930025319.987-3-sergey.senozhatsky@gmail.com>
On Sat 2017-09-30 11:53:14, Sergey Senozhatsky wrote:
> There are two format specifiers to print out a pointer in symbolic
> format: '%pS/%ps' and '%pF/%pf'. On most architectures, the two
> mean exactly the same thing, but some architectures (ia64, ppc64,
> parisc64) use an indirect pointer for C function pointers, where
> the function pointer points to a function descriptor (which in
> turn contains the actual pointer to the code). The '%pF/%pf, when
> used appropriately, automatically does the appropriate function
> descriptor dereference on such architectures.
>
> The "when used appropriately" part is tricky. Basically this is
> a subtle ABI detail, specific to some platforms, that made it to
> the API level and people can be unaware of it and miss the whole
> "we need to dereference the function" business out. [1] proves
> that point (note that it fixes only '%pF' and '%pS', there might
> be '%pf' and '%ps' cases as well).
>
> It appears that we can handle everything within the affected
> arches and make '%pS/%ps' smart enough to retire '%pF/%pf'.
> Function descriptors live in .opd elf section and all affected
> arches (ia64, ppc64, parisc64) handle it properly for kernel
> and modules. So we, technically, can decide if the dereference
> is needed by simply looking at the pointer: if it belongs to
> .opd section then we need to dereference it.
Great catch. I really like this approach!
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index e5da44eddd2f..387f22c41e0d 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -29,6 +29,7 @@
> * __ctors_start, __ctors_end
> * __irqentry_text_start, __irqentry_text_end
> * __softirqentry_text_start, __softirqentry_text_end
> + * __start_opd, __end_opd
> */
> extern char _text[], _stext[], _etext[];
> extern char _data[], _sdata[], _edata[];
> @@ -47,12 +48,15 @@ extern char __softirqentry_text_start[], __softirqentry_text_end[];
> /* Start and end of .ctors section - used for constructor calls. */
> extern char __ctors_start[], __ctors_end[];
>
> +/* Start and end of .opd section - used for function descriptors. */
> +extern char __start_opd[], __end_opd[];
> +
> extern __visible const void __nosave_begin, __nosave_end;
>
> -/* function descriptor handling (if any). Override
> - * in asm/sections.h */
> +/* Function descriptor handling (if any). Override in asm/sections.h */
> #ifndef dereference_function_descriptor
> #define dereference_function_descriptor(p) (p)
> +#define dereference_kernel_function_descriptor(p) (p)
> #endif
>
> /* random extra sections (if any). Override
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 4d0cb9bba93e..172904e9cded 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -85,6 +85,10 @@ void module_arch_cleanup(struct module *mod);
> /* Any cleanup before freeing mod->module_init */
> void module_arch_freeing_init(struct module *mod);
>
> +/* Dereference module function descriptor */
> +unsigned long dereference_module_function_descriptor(struct module *mod,
> + unsigned long addr);
> +
The function is used when the module is already loaded. IMHO,
include/linux/module.h would be a better place.
One advantage would be that we could use the same trick
as in include/asm-generic/sections.h. I mean:
#define dereference_module_function_descriptor(mod, addr) (addr)
and redefine it in the three affected
arch/<arch>/include/asm/module.h headers. Then it might be completely
optimized out on all architectures.
Anyway, we need to get ack from Jessica for this change.
Best Regards,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
James Bottomley <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
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: [PATCHv3 2/7] sections: split dereference_function_descriptor()
Date: Wed, 4 Oct 2017 11:00:43 +0200 [thread overview]
Message-ID: <20171004090043.GD20084@pathway.suse.cz> (raw)
In-Reply-To: <20170930025319.987-3-sergey.senozhatsky@gmail.com>
On Sat 2017-09-30 11:53:14, Sergey Senozhatsky wrote:
> There are two format specifiers to print out a pointer in symbolic
> format: '%pS/%ps' and '%pF/%pf'. On most architectures, the two
> mean exactly the same thing, but some architectures (ia64, ppc64,
> parisc64) use an indirect pointer for C function pointers, where
> the function pointer points to a function descriptor (which in
> turn contains the actual pointer to the code). The '%pF/%pf, when
> used appropriately, automatically does the appropriate function
> descriptor dereference on such architectures.
>
> The "when used appropriately" part is tricky. Basically this is
> a subtle ABI detail, specific to some platforms, that made it to
> the API level and people can be unaware of it and miss the whole
> "we need to dereference the function" business out. [1] proves
> that point (note that it fixes only '%pF' and '%pS', there might
> be '%pf' and '%ps' cases as well).
>
> It appears that we can handle everything within the affected
> arches and make '%pS/%ps' smart enough to retire '%pF/%pf'.
> Function descriptors live in .opd elf section and all affected
> arches (ia64, ppc64, parisc64) handle it properly for kernel
> and modules. So we, technically, can decide if the dereference
> is needed by simply looking at the pointer: if it belongs to
> .opd section then we need to dereference it.
Great catch. I really like this approach!
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index e5da44eddd2f..387f22c41e0d 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -29,6 +29,7 @@
> * __ctors_start, __ctors_end
> * __irqentry_text_start, __irqentry_text_end
> * __softirqentry_text_start, __softirqentry_text_end
> + * __start_opd, __end_opd
> */
> extern char _text[], _stext[], _etext[];
> extern char _data[], _sdata[], _edata[];
> @@ -47,12 +48,15 @@ extern char __softirqentry_text_start[], __softirqentry_text_end[];
> /* Start and end of .ctors section - used for constructor calls. */
> extern char __ctors_start[], __ctors_end[];
>
> +/* Start and end of .opd section - used for function descriptors. */
> +extern char __start_opd[], __end_opd[];
> +
> extern __visible const void __nosave_begin, __nosave_end;
>
> -/* function descriptor handling (if any). Override
> - * in asm/sections.h */
> +/* Function descriptor handling (if any). Override in asm/sections.h */
> #ifndef dereference_function_descriptor
> #define dereference_function_descriptor(p) (p)
> +#define dereference_kernel_function_descriptor(p) (p)
> #endif
>
> /* random extra sections (if any). Override
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index 4d0cb9bba93e..172904e9cded 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -85,6 +85,10 @@ void module_arch_cleanup(struct module *mod);
> /* Any cleanup before freeing mod->module_init */
> void module_arch_freeing_init(struct module *mod);
>
> +/* Dereference module function descriptor */
> +unsigned long dereference_module_function_descriptor(struct module *mod,
> + unsigned long addr);
> +
The function is used when the module is already loaded. IMHO,
include/linux/module.h would be a better place.
One advantage would be that we could use the same trick
as in include/asm-generic/sections.h. I mean:
#define dereference_module_function_descriptor(mod, addr) (addr)
and redefine it in the three affected
arch/<arch>/include/asm/module.h headers. Then it might be completely
optimized out on all architectures.
Anyway, we need to get ack from Jessica for this change.
Best Regards,
Petr
next prev parent reply other threads:[~2017-10-04 9:00 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-30 2:53 [PATCHv3 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-09-30 2:53 ` [PATCHv3 1/7] switch dereference_function_descriptor() to `unsigned long' Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 8:24 ` Petr Mladek
2017-10-04 8:24 ` Petr Mladek
2017-10-19 6:50 ` Sergey Senozhatsky
2017-10-19 6:50 ` Sergey Senozhatsky
2017-10-20 13:25 ` Petr Mladek
2017-10-20 13:25 ` Petr Mladek
2017-09-30 2:53 ` [PATCHv3 2/7] sections: split dereference_function_descriptor() Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 9:00 ` Petr Mladek [this message]
2017-10-04 9:00 ` Petr Mladek
2017-10-19 6:45 ` Sergey Senozhatsky
2017-10-19 6:45 ` Sergey Senozhatsky
2017-09-30 2:53 ` [PATCHv3 3/7] ia64: Add .opd based function descriptor dereference Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 9:05 ` Petr Mladek
2017-10-04 9:05 ` Petr Mladek
2017-09-30 2:53 ` [PATCHv3 4/7] powerpc64: " Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 9:21 ` Petr Mladek
2017-10-04 9:21 ` Petr Mladek
2017-10-04 11:06 ` Michael Ellerman
2017-10-04 11:06 ` Michael Ellerman
2017-10-19 14:01 ` Sergey Senozhatsky
2017-10-19 14:01 ` Sergey Senozhatsky
2017-10-19 6:45 ` Sergey Senozhatsky
2017-10-19 6:45 ` Sergey Senozhatsky
2017-09-30 2:53 ` [PATCHv3 5/7] parisc64: " Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 10:40 ` Petr Mladek
2017-10-04 10:40 ` Petr Mladek
2017-10-19 6:44 ` Sergey Senozhatsky
2017-10-19 6:44 ` Sergey Senozhatsky
2017-09-30 2:53 ` [PATCHv3 6/7] symbol lookup: use new kernel and module dereference functions Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 11:53 ` Petr Mladek
2017-10-04 11:53 ` Petr Mladek
2017-10-19 6:42 ` Sergey Senozhatsky
2017-10-19 6:42 ` Sergey Senozhatsky
2017-10-20 13:08 ` Petr Mladek
2017-10-20 13:08 ` Petr Mladek
2017-10-23 8:38 ` Sergey Senozhatsky
2017-10-23 8:38 ` Sergey Senozhatsky
2017-09-30 2:53 ` [PATCHv3 7/7] checkpatch: add pF/pf deprecation warning Sergey Senozhatsky
2017-09-30 2:53 ` Sergey Senozhatsky
2017-10-04 12:08 ` Petr Mladek
2017-10-04 12:08 ` 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=20171004090043.GD20084@pathway.suse.cz \
--to=pmladek@suse.com \
--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=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.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 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.