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!
Another note:
I need to check what is BPF symbol lookup and do we need to
do any dereference there.
[1] https://marc.info/?l=linux-kernel&m=150472969730573
Sergey Senozhatsky (5):
sections: split dereference_function_descriptor()
ia64: Add .opd based function descriptor dereference
powerpc64: Add .opd based function descriptor dereference
parisc64: Add .opd based function descriptor dereference
symbol lookup: use new kernel and module dereference functions
Documentation/printk-formats.txt | 15 +++++----------
arch/ia64/include/asm/sections.h | 14 +++++++++++++-
arch/ia64/kernel/module.c | 13 +++++++++++++
arch/ia64/kernel/vmlinux.lds.S | 2 ++
arch/parisc/boot/compressed/vmlinux.lds.S | 2 ++
arch/parisc/include/asm/sections.h | 3 +++
arch/parisc/kernel/module.c | 14 ++++++++++++++
arch/parisc/kernel/process.c | 10 ++++++++++
arch/parisc/kernel/vmlinux.lds.S | 2 ++
arch/powerpc/include/asm/module.h | 3 +++
arch/powerpc/include/asm/sections.h | 13 +++++++++++++
arch/powerpc/kernel/module_64.c | 16 ++++++++++++++++
arch/powerpc/kernel/vmlinux.lds.S | 2 ++
include/asm-generic/sections.h | 4 ++--
include/linux/moduleloader.h | 4 ++++
kernel/kallsyms.c | 1 +
kernel/module.c | 7 +++++++
lib/vsprintf.c | 5 +----
18 files changed, 113 insertions(+), 17 deletions(-)
--
2.14.1
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.
The kernel and modules have their own .opd sections, obviously,
that's why we need to split dereference_function_descriptor()
and use separate kernel and module dereference arch callbacks.
This patch does the first step, it
a) adds dereference_kernel_function_descriptor() function.
b) adds a weak alias to dereference_module_function_descriptor()
function.
So, for the time being, we will have:
1) dereference_function_descriptor()
A generic function, that simply dereferences the pointer. There is
bunch of places that call it: kgdbts, init/main.c, extable, etc.
2) dereference_kernel_function_descriptor()
A function to call on kernel symbols that does kernel .opd section
address range test.
3) dereference_module_function_descriptor()
A function to call on modules' symbols that does modules' .opd
section address range test.
[1] https://marc.info/?l=linux-kernel&m=150472969730573
Signed-off-by: Sergey Senozhatsky <redacted>
---
include/asm-generic/sections.h | 4 ++--
include/linux/moduleloader.h | 4 ++++
kernel/module.c | 6 ++++++
3 files changed, 12 insertions(+), 2 deletions(-)
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for IA64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky <redacted>
---
arch/ia64/include/asm/sections.h | 14 +++++++++++++-
arch/ia64/kernel/module.c | 13 +++++++++++++
arch/ia64/kernel/vmlinux.lds.S | 2 ++
3 files changed, 28 insertions(+), 1 deletion(-)
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for powerpc64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky <redacted>
---
arch/powerpc/include/asm/module.h | 3 +++
arch/powerpc/include/asm/sections.h | 13 +++++++++++++
arch/powerpc/kernel/module_64.c | 16 ++++++++++++++++
arch/powerpc/kernel/vmlinux.lds.S | 2 ++
4 files changed, 34 insertions(+)
@@ -45,6 +45,9 @@ struct mod_arch_specific {unsignedlongtramp;#endif+/* For module function descriptor dereference */+unsignedlongstart_opd;+unsignedlongend_opd;#else /* powerpc64 *//* Indices of PLT sections within module. */unsignedintcore_plt_section;
@@ -344,6 +344,11 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,elseif(strcmp(secstrings+sechdrs[i].sh_name,"__versions")==0)dedotify_versions((void*)hdr+sechdrs[i].sh_offset,sechdrs[i].sh_size);+elseif(strcmp(secstrings+sechdrs[i].sh_name,".opd")==0){+me->arch.start_opd=sechdrs[i].sh_offset;+me->arch.end_opd=me->arch.start_opd++sechdrs[i].sh_size;+}/* We don't handle .init for the moment: rename to _init */while((p=strstr(secstrings+sechdrs[i].sh_name,".init")))
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for parisc64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky <redacted>
---
arch/parisc/boot/compressed/vmlinux.lds.S | 2 ++
arch/parisc/include/asm/sections.h | 3 +++
arch/parisc/kernel/module.c | 14 ++++++++++++++
arch/parisc/kernel/process.c | 10 ++++++++++
arch/parisc/kernel/vmlinux.lds.S | 2 ++
5 files changed, 31 insertions(+)
Call appropriate function descriptor dereference ARCH callbacks:
- dereference_kernel_function_descriptor() if the pointer is a
kernel symbol;
- dereference_module_function_descriptor() if the pointer is a
module symbol.
This patch also removes dereference_function_descriptor() from
'%pF/%pf' vsprintf handler, because it has the same behavior with
'%pS/%ps' now.
Signed-off-by: Sergey Senozhatsky <redacted>
---
Documentation/printk-formats.txt | 15 +++++----------
kernel/kallsyms.c | 1 +
kernel/module.c | 1 +
lib/vsprintf.c | 5 +----
4 files changed, 8 insertions(+), 14 deletions(-)
@@ -50,26 +50,23 @@ Symbols/Function Pointers ::+ %pS versatile_init+0x0/0x110+ %ps versatile_init %pF versatile_init+0x0/0x110 %pf versatile_init- %pS versatile_init+0x0/0x110 %pSR versatile_init+0x9/0x110 (with __builtin_extract_return_addr() translation)- %ps versatile_init %pB prev_fn_of_versatile_init+0x88/0x88-The ``F`` and ``f`` specifiers are for printing function pointers,-for example, f->func, &gettimeofday. They have the same result as-``S`` and ``s`` specifiers. But they do an extra conversion on-ia64, ppc64 and parisc64 architectures where the function pointers-are actually function descriptors.- The ``S`` and ``s`` specifiers can be used for printing symbols from direct addresses, for example, __builtin_return_address(0), (void *)regs->ip. They result in the symbol name with (``S``) or without (``s``) offsets. If KALLSYMS are disabled then the symbol address is printed instead.+Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)+and thus deprecated.+ The ``B`` specifier results in the symbol name with offsets and should be used when printing stack backtraces. The specifier takes into consideration the effect of compiler optimisations which may occur
@@ -77,8 +74,6 @@ when tail-call``s are used and marked with the noreturn GCC attribute. Examples::- printk("Going to call: %pF\n", gettimeofday);- printk("Going to call: %pF\n", p->func); printk("%s: called from %pS\n", __func__, (void *)_RET_IP_); printk("%s: called from %pS\n", __func__, (void *)__builtin_return_address(0));
From: Naveen N. Rao <hidden> Date: 2017-09-16 09:44:00
On 2017/09/16 12:53PM, Sergey Senozhatsky wrote:
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for powerpc64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Would it be simpler to just use kernel_text_address() and dereference
everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only
dereference function descriptor for non-text symbols") for a related
patch.
- Naveen
Would it be simpler to just use kernel_text_address() and dereference
everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only
dereference function descriptor for non-text symbols") for a related
patch.
I had this idea, see
lkml.kernel.org/r/20170908172528.qc2vdtxzqh777k6o@intel.com
-ss
On Sat, Sep 16, 2017 at 12:53:42PM +0900, Sergey Senozhatsky wrote:
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).
A few new warnings when building on ia64:
arch/ia64/kernel/module.c:931: warning: passing argument 1 of 'dereference_function_descriptor' makes pointer from integer without a cast
arch/ia64/kernel/module.c:931: warning: return makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: assignment makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: passing argument 1 of 'dereference_kernel_function_descriptor' makes pointer from integer without a cast
Tried out the module case with a simple Hello-world test case.
This code:
char buf[1];
int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
printk("using %%p my init_module is at %p\n", init_module);
printk("using %%pF my init_module is at %pF\n", init_module);
printk("using %%pS my init_module is at %pS\n", init_module);
printk("using %%p my buf is at %p\n", buf);
printk("using %%pF my buf is at %pF\n", buf);
printk("using %%pS my buf is at %pS\n", buf);
return 0;
}
Gave this console output:
Hello world 1.
using %p my init_module is at a000000203bf0328
using %pF my init_module is at init_module+0x0/0x140 [hello_1]
using %pS my init_module is at init_module+0x0/0x140 [hello_1]
using %p my buf is at a000000203bf0648
using %pF my buf is at buf+0x0/0xfffffffffffffb58 [hello_1]
using %pS my buf is at buf+0x0/0xfffffffffffffb58 [hello_1]
Which looks like what you wanted. People unaware of the vagaries
of ppc64/ia64/parisc64 can use the wrong %p[SF] variant, but still
get the right output.
-Tony
On Sat, Sep 16, 2017 at 12:53:42PM +0900, Sergey Senozhatsky wrote:
quoted
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).
A few new warnings when building on ia64:
arch/ia64/kernel/module.c:931: warning: passing argument 1 of 'dereference_function_descriptor' makes pointer from integer without a cast
arch/ia64/kernel/module.c:931: warning: return makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: assignment makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: passing argument 1 of 'dereference_kernel_function_descriptor' makes pointer from integer without a cast
I got similiar warnings on parisc.
This patch on top of yours fixed those:
@@ -322,7 +322,7 @@ const char *kallsyms_lookup(unsigned long addr,if(is_ksym_addr(addr)){unsignedlongpos;-addr=dereference_kernel_function_descriptor(addr);+addr=dereference_kernel_function_descriptor((void*)addr);pos=get_symbol_pos(addr,symbolsize,offset);/* Grab name */kallsyms_expand_symbol(get_symbol_offset(pos),
I did tried your testcases too.
"echo 1 > /proc/sys/vm/drop_caches" gave correct output:
printk#1 schedule_timeout+0x0/0x4a8
printk#2 schedule_timeout+0x0/0x4a8
printk#3 proc_sys_call_handler+0x120/0x180
printk#4 proc_sys_call_handler+0x120/0x180
printk#5 proc_sys_call_handler+0x120/0x180
printk#6 proc_sys_call_handler+0x120/0x180
and here is "modprobe zram":
printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#9 do_one_initcall+0x194/0x290
printk#10 do_one_initcall+0x194/0x290
printk#11 do_one_initcall+0x194/0x290
printk#12 do_one_initcall+0x194/0x290
printk#13 zram_init+0x22c/0x2a0 [zram]
printk#14 zram_init+0x22c/0x2a0 [zram]
printk#15 zram_init+0x22c/0x2a0 [zram]
printk#16 zram_init+0x22c/0x2a0 [zram]
I wonder why printk#7 and printk#8 don't show "zram_init"...
Regarding your patches:
In arch/parisc/kernel/process.c:
+void *dereference_kernel_function_descriptor(void *ptr)
+{
+ if (ptr < (void *)__start_opd || (void *)__end_opd < ptr)
This needs to be (__end_opd is outside):
+ if (ptr < (void *)__start_opd || (void *)__end_opd <= ptr)
The same is true for the checks in the other arches.
I'd suggest to move the various
extern char __start_opd[], __end_opd[];
out of arch/<arch>/include/asm/sections.h and into <asm-generic/sections.h>
I'll continue to test.
Helge
A few new warnings when building on ia64:
arch/ia64/kernel/module.c:931: warning: passing argument 1 of 'dereference_function_descriptor' makes pointer from integer without a cast
arch/ia64/kernel/module.c:931: warning: return makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: assignment makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: passing argument 1 of 'dereference_kernel_function_descriptor' makes pointer from integer without a cast
I got similiar warnings on parisc.
This patch on top of yours fixed those:
Tony, Helge,
thanks for the reports!
I'll simply convert everything to `unsigned long'. including the
dereference_function_descriptor() function [I believe there are
still some casts happening when we pass addr from kernel/module
dereference functions to dereference_function_descriptor(), or
when we return `void *' back to symbol resolution code, etc.)
besides, it seems that everything that uses
dereference_function_descriptor() wants `unsigned long' anyway:
drivers/misc/kgdbts.c: addr = (unsigned long) dereference_function_descriptor((void *)addr);
init/main.c: addr = (unsigned long) dereference_function_descriptor(fn);
kernel/extable.c: addr = (unsigned long) dereference_function_descriptor(ptr);
kernel/module.c: unsigned long a = (unsigned long)dereference_function_descriptor(addr);
so I'll just switch it to ulong.
I did tried your testcases too.
"echo 1 > /proc/sys/vm/drop_caches" gave correct output:
printk#1 schedule_timeout+0x0/0x4a8
printk#2 schedule_timeout+0x0/0x4a8
printk#3 proc_sys_call_handler+0x120/0x180
printk#4 proc_sys_call_handler+0x120/0x180
printk#5 proc_sys_call_handler+0x120/0x180
printk#6 proc_sys_call_handler+0x120/0x180
and here is "modprobe zram":
printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#9 do_one_initcall+0x194/0x290
printk#10 do_one_initcall+0x194/0x290
printk#11 do_one_initcall+0x194/0x290
printk#12 do_one_initcall+0x194/0x290
printk#13 zram_init+0x22c/0x2a0 [zram]
printk#14 zram_init+0x22c/0x2a0 [zram]
printk#15 zram_init+0x22c/0x2a0 [zram]
printk#16 zram_init+0x22c/0x2a0 [zram]
I wonder why printk#7 and printk#8 don't show "zram_init"...
interesting... what does the unpatched kernel show?
Regarding your patches:
In arch/parisc/kernel/process.c:
+void *dereference_kernel_function_descriptor(void *ptr)
+{
+ if (ptr < (void *)__start_opd || (void *)__end_opd < ptr)
This needs to be (__end_opd is outside):
+ if (ptr < (void *)__start_opd || (void *)__end_opd <= ptr)
The same is true for the checks in the other arches.
um... yeah. __end_opd is definitely not a valid place for a descriptor!
I think I had `if (!(ptr >= __start_opd && ptr < __end_opd))' which I
wrongly converted. "shame, shame, shame".
thanks!
I'd suggest to move the various
extern char __start_opd[], __end_opd[];
out of arch/<arch>/include/asm/sections.h and into <asm-generic/sections.h>
A few new warnings when building on ia64:
arch/ia64/kernel/module.c:931: warning: passing argument 1 of 'dereference_function_descriptor' makes pointer from integer without a cast
arch/ia64/kernel/module.c:931: warning: return makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: assignment makes integer from pointer without a cast
kernel/kallsyms.c:325: warning: passing argument 1 of 'dereference_kernel_function_descriptor' makes pointer from integer without a cast
got it, will address in v2.
[..]
Which looks like what you wanted. People unaware of the vagaries
of ppc64/ia64/parisc64 can use the wrong %p[SF] variant, but still
get the right output.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-09-19 10:22:43
"Naveen N. Rao" [off-list ref] writes:
On 2017/09/16 12:53PM, Sergey Senozhatsky wrote:
quoted
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for powerpc64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Would it be simpler to just use kernel_text_address() and dereference
everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only
dereference function descriptor for non-text symbols") for a related
patch.
Yeah that would be a lot simpler and probably work perfectly well.
cheers
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for powerpc64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Would it be simpler to just use kernel_text_address() and dereference
everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only
dereference function descriptor for non-text symbols") for a related
patch.
Yeah that would be a lot simpler and probably work perfectly well.
unlike ppc_function_entry(), printk() can get called on any symbol,
not just function pointers.
for example,
cat /proc/kallsyms | grep shrinker_rwsem
ffffffff81a4b1e0 d shrinker_rwsem
or
cat /proc/kallsyms | grep vm_total_pages
ffffffff81dcd418 B vm_total_pages
and so on.
-ss
From: David Laight <hidden> Date: 2017-09-19 13:38:56
From: Sergey Senozhatsky
Sent: 19 September 2017 03:06
...
I'll simply convert everything to `unsigned long'. including the
dereference_function_descriptor() function [I believe there are
still some casts happening when we pass addr from kernel/module
dereference functions to dereference_function_descriptor(), or
when we return `void *' back to symbol resolution code, etc.)
besides, it seems that everything that uses
dereference_function_descriptor() wants `unsigned long' anyway:
Using 'unsigned long' for any kind of pointer is an accident
waiting do happen.
It also makes it difficult to typecheck the function calls.
Using 'void *' isn't any better.
Either a pointer to an undefined struct, or a struct containing
a single 'char' member, is likely to be safest.
David
and here is "modprobe zram":
printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#9 do_one_initcall+0x194/0x290
printk#10 do_one_initcall+0x194/0x290
printk#11 do_one_initcall+0x194/0x290
printk#12 do_one_initcall+0x194/0x290
printk#13 zram_init+0x22c/0x2a0 [zram]
printk#14 zram_init+0x22c/0x2a0 [zram]
printk#15 zram_init+0x22c/0x2a0 [zram]
printk#16 zram_init+0x22c/0x2a0 [zram]
I wonder why printk#7 and printk#8 don't show "zram_init"...
interesting... what does the unpatched kernel show?
Really strange.
The unpatched kernel shows __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 too.
The symbol should be known, because later on in printk13 it shows correctly zram_init.
I'll need to dig deeper into it, but at least the regression is not due
to your patch.
Helge
and here is "modprobe zram":
printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
printk#9 do_one_initcall+0x194/0x290
printk#10 do_one_initcall+0x194/0x290
printk#11 do_one_initcall+0x194/0x290
printk#12 do_one_initcall+0x194/0x290
printk#13 zram_init+0x22c/0x2a0 [zram]
printk#14 zram_init+0x22c/0x2a0 [zram]
printk#15 zram_init+0x22c/0x2a0 [zram]
printk#16 zram_init+0x22c/0x2a0 [zram]
I wonder why printk#7 and printk#8 don't show "zram_init"...
interesting... what does the unpatched kernel show?
Really strange.
The unpatched kernel shows __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 too.
The symbol should be known, because later on in printk13 it shows correctly zram_init.
I'll need to dig deeper into it, but at least the regression is not due
to your patch.
Sergey, I was wrong with this assumption.
Your implementation of dereference_module_function_descriptor() in
arch/parisc/kernel/module.c is faulty.
mod->arch.fdesc_offset is relative to the base address of the module,
so you need to add to mod->core_layout.base.
Here is the relevant patch to fix this issue (against mainline).
Additionally I compare against mod->arch.fdesc_count instead of
mod->arch.fdesc_max.
Can you please fold it into your patch
[PATCH 4/5] parisc64: Add .opd based function descriptor dereference
for the next round?
Thanks,
Helge
Signed-off-by: Helge Deller <deller@gmx.de>
I'll simply convert everything to `unsigned long'. including the
dereference_function_descriptor() function [I believe there are
still some casts happening when we pass addr from kernel/module
dereference functions to dereference_function_descriptor(), or
when we return `void *' back to symbol resolution code, etc.)
besides, it seems that everything that uses
dereference_function_descriptor() wants `unsigned long' anyway:
Using 'unsigned long' for any kind of pointer is an accident
waiting do happen.
It also makes it difficult to typecheck the function calls.
Using 'void *' isn't any better.
Either a pointer to an undefined struct, or a struct containing
a single 'char' member, is likely to be safest.
David, you might be right in most cases, but in this case I'd prefer
unsigned long too. I think this will create the least amount of
typecasts here.
Helge
Your implementation of dereference_module_function_descriptor() in
arch/parisc/kernel/module.c is faulty.
mod->arch.fdesc_offset is relative to the base address of the module,
so you need to add to mod->core_layout.base.
aha, got it. I should have figured that out.
many thanks!
Here is the relevant patch to fix this issue (against mainline).
Additionally I compare against mod->arch.fdesc_count instead of
mod->arch.fdesc_max.
hmm, .fdesc_max looked relevant to me. it's count_fdescs() - the
number of R_PARISC_FPTR64 relocation entries.
but ok, will use .fdesc_count.
Can you please fold it into your patch
[PATCH 4/5] parisc64: Add .opd based function descriptor dereference
for the next round?
sure, will fold. + SoB.
I think I'll try to re-spin the series today (or tomorrow, I'm slightly
overloaded with another stuff right now). I've received enough bug reports
no need to wait for another week ;)
-ss
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-09-20 01:51:56
Sergey Senozhatsky [off-list ref] writes:
On (09/19/17 20:22), Michael Ellerman wrote:
quoted
quoted
On 2017/09/16 12:53PM, Sergey Senozhatsky wrote:
quoted
We are moving towards separate kernel and module function descriptor
dereference callbacks. This patch enables it for powerpc64.
For pointers that belong to the kernel
- Added __start_opd and __end_opd pointers, to track the kernel
.opd section address range;
- Added dereference_kernel_function_descriptor(). Now we
will dereference only function pointers that are within
[__start_opd, __end_opd];
For pointers that belong to a module
- Added dereference_module_function_descriptor() to handle module
function descriptor dereference. Now we will dereference only
pointers that are within [module->opd.start, module->opd.end].
Would it be simpler to just use kernel_text_address() and dereference
everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only
dereference function descriptor for non-text symbols") for a related
patch.
Yeah that would be a lot simpler and probably work perfectly well.
unlike ppc_function_entry(), printk() can get called on any symbol,
not just function pointers.
for example,
cat /proc/kallsyms | grep shrinker_rwsem
ffffffff81a4b1e0 d shrinker_rwsem
Yep, good point. So your patch is probably good then. Maybe someone
other than me can find time to test it ;)
cheers
unlike ppc_function_entry(), printk() can get called on any symbol,
not just function pointers.
for example,
cat /proc/kallsyms | grep shrinker_rwsem
ffffffff81a4b1e0 d shrinker_rwsem
Yep, good point. So your patch is probably good then. Maybe someone
other than me can find time to test it ;)
From: David Laight <hidden> Date: 2017-09-20 08:42:20
From: Helge Deller
Sent: 19 September 2017 21:08
...
quoted
Using 'unsigned long' for any kind of pointer is an accident
waiting do happen.
It also makes it difficult to typecheck the function calls.
Using 'void *' isn't any better.
Either a pointer to an undefined struct, or a struct containing
a single 'char' member, is likely to be safest.
=20
David, you might be right in most cases, but in this case I'd prefer
unsigned long too. I think this will create the least amount of
typecasts here.
I've not looked at the specifics case...
Another option is using a struct with a single member and
passing it by value.
This could be used for things like user-space pointers or
even errno values.
The only problem is old ABI where even small structures are
always passed by reference.
David
Using 'unsigned long' for any kind of pointer is an accident
waiting do happen.
It also makes it difficult to typecheck the function calls.
Using 'void *' isn't any better.
Either a pointer to an undefined struct, or a struct containing
a single 'char' member, is likely to be safest.
David, you might be right in most cases, but in this case I'd prefer
unsigned long too. I think this will create the least amount of
typecasts here.
I've not looked at the specifics case...
Another option is using a struct with a single member and
passing it by value.
Actually, we do already have correct structs which could be referenced:
parisc: struct Elf64_Fdesc
ia64: struct fdesc
ppc64: struct ppc64_opd_entry
One could "#define platform_opd_entry" to each of those depending on the platform and use it.
It might be misleading though, because the pointer which is handed over to
dereference_function_descriptor() can be such a pointer but isn't necessary.
I'll leave it up to Sergey to decide.
Helge
I've not looked at the specifics case...
Another option is using a struct with a single member and
passing it by value.
Actually, we do already have correct structs which could be referenced:
parisc: struct Elf64_Fdesc
ia64: struct fdesc
ppc64: struct ppc64_opd_entry
One could "#define platform_opd_entry" to each of those depending on the platform and use it.
It might be misleading though, because the pointer which is handed over to
dereference_function_descriptor() can be such a pointer but isn't necessary.
I'll leave it up to Sergey to decide.
Hello,
I think I'll keep 'unsigned long' for now.
-ss