On (09/14/17 16:01), Luck, Tony wrote:
>
> > let's hear from ia64 and ppc64 guys.
>
> If you write a patch, I can try it on some ia64 h/w.
>
> Please include some test cases (perhaps as a second patch that adds a few
> good/bad %pF and %pS
> to some code (both in base kernel, and in a module).
On (09/14/17 16:01), Luck, Tony wrote:
>
> > let's hear from ia64 and ppc64 guys.
>
> If you write a patch, I can try it on some ia64 h/w.
>
> Please include some test cases (perhaps as a second patch that adds a few
> good/bad %pF and %pS
> to some code (both in base kernel, and in a module).
> let's hear from ia64 and ppc64 guys.
If you write a patch, I can try it on some ia64 h/w.
Please include some test cases (perhaps as a second patch that adds a few
good/bad %pF and %pS
to some code (both in base kernel, and in a module).
-Tony
> let's hear from ia64 and ppc64 guys.
If you write a patch, I can try it on some ia64 h/w.
Please include some test cases (perhaps as a second patch that adds a few
good/bad %pF and %pS
to some code (both in base kernel, and in a module).
-Tony
On 14.09.2017 11:27, Sergey Senozhatsky wrote:
On (09/14/17 10:39), Helge Deller wrote:
[..]
The basic concept of your proposal may work, and since it will avoid such
coding issues in the future I think it's probably the best solution.
Will you come up with a patch ? (I won't have time the
On 14.09.2017 11:27, Sergey Senozhatsky wrote:
On (09/14/17 10:39), Helge Deller wrote:
[..]
The basic concept of your proposal may work, and since it will avoid such
coding issues in the future I think it's probably the best solution.
Will you come up with a patch ? (I won't have time the
On (09/14/17 10:39), Helge Deller wrote:
[..]
> The basic concept of your proposal may work, and since it will avoid such
> coding issues in the future I think it's probably the best solution.
>
> Will you come up with a patch ? (I won't have time the next few days).
> If yes,I'd be happy to test
On (09/14/17 10:39), Helge Deller wrote:
[..]
> The basic concept of your proposal may work, and since it will avoid such
> coding issues in the future I think it's probably the best solution.
>
> Will you come up with a patch ? (I won't have time the next few days).
> If yes,I'd be happy to test
On 14.09.2017 10:03, Sergey Senozhatsky wrote:
On (09/14/17 16:40), Sergey Senozhatsky wrote:
[..]
powerpc and parisc handle kernel .opd section as well:
arch/powerpc/kernel/vmlinux.lds.S: .opd
arch/parisc/kernel/vmlinux.lds.S: .opd
for modules, arch-s define mod_arch_specific
On 14.09.2017 10:03, Sergey Senozhatsky wrote:
On (09/14/17 16:40), Sergey Senozhatsky wrote:
[..]
powerpc and parisc handle kernel .opd section as well:
arch/powerpc/kernel/vmlinux.lds.S: .opd
arch/parisc/kernel/vmlinux.lds.S: .opd
for modules, arch-s define mod_arch_specific
On (09/14/17 16:40), Sergey Senozhatsky wrote:
[..]
> powerpc and parisc handle kernel .opd section as well:
>
> arch/powerpc/kernel/vmlinux.lds.S: .opd
> arch/parisc/kernel/vmlinux.lds.S: .opd
for modules, arch-s define mod_arch_specific struct.
parisc has .opd
(fdesc offset should
On (09/14/17 16:40), Sergey Senozhatsky wrote:
[..]
> powerpc and parisc handle kernel .opd section as well:
>
> arch/powerpc/kernel/vmlinux.lds.S: .opd
> arch/parisc/kernel/vmlinux.lds.S: .opd
for modules, arch-s define mod_arch_specific struct.
parisc has .opd
(fdesc offset should
On (09/08/17 20:28), Helge Deller wrote:
[..]
> I don't like this kind of trying to figure out at runtime at all.
> It's too much guessing in here IMHO.
well, may be we can avoid any guessing by checking that the
pointer belongs to .opd section.
for kernel we can add 2 new unsigned longs -
On (09/08/17 20:28), Helge Deller wrote:
[..]
> I don't like this kind of trying to figure out at runtime at all.
> It's too much guessing in here IMHO.
well, may be we can avoid any guessing by checking that the
pointer belongs to .opd section.
for kernel we can add 2 new unsigned longs -
On (09/08/17 10:25), Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
> > if the addr is not in kernel .text, then try dereferencing it and check
> > if the dereferenced addr is in kernel .text.
>
> If it really is a function pointer, then we know that it is
On (09/08/17 10:25), Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
> > if the addr is not in kernel .text, then try dereferencing it and check
> > if the dereferenced addr is in kernel .text.
>
> If it really is a function pointer, then we know that it is
Hi,
On (09/08/17 22:49), Helge Deller wrote:
[..]
> Sergey, I'm sure there is a way how you can get it somehow to work the way
> you describe above, but even then nobody can guarantee you that it
> will work in 100% of the cases.
>
> It's somehow like "we have %lu and %c specifiers, and it's
Hi,
On (09/08/17 22:49), Helge Deller wrote:
[..]
> Sergey, I'm sure there is a way how you can get it somehow to work the way
> you describe above, but even then nobody can guarantee you that it
> will work in 100% of the cases.
>
> It's somehow like "we have %lu and %c specifiers, and it's
Hi,
On (09/08/17 22:23), Yu, Fenghua wrote:
> > From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> > On (09/07/17 16:05), Luck, Tony wrote:
> > +static inline bool __mod_text_address(struct module *mod,
> > + unsigned long addr) {
> > +
Hi,
On (09/08/17 22:23), Yu, Fenghua wrote:
> > From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> > On (09/07/17 16:05), Luck, Tony wrote:
> > +static inline bool __mod_text_address(struct module *mod,
> > + unsigned long addr) {
> > +
On Wed 2017-09-06 22:27:47, Helge Deller wrote:
> This patch series fixes the wrong usages of the %pF and %pS printk format
> specifiers throughout the kernel code.
>
> Both specifiers have the same result on most architectures. But on ia64, ppc64
> and parisc64 architectures the %pF specifier
On Wed 2017-09-06 22:27:47, Helge Deller wrote:
> This patch series fixes the wrong usages of the %pF and %pS printk format
> specifiers throughout the kernel code.
>
> Both specifiers have the same result on most architectures. But on ia64, ppc64
> and parisc64 architectures the %pF specifier
On Fri 2017-09-08 22:49:51, Helge Deller wrote:
> On 08.09.2017 08:18, Sergey Senozhatsky wrote:
> > On (09/07/17 16:05), Luck, Tony wrote:
> > [..]
> if (not_a_function_descriptor(ptr))
> return ptr;
> >>>
> >>> I'm not sure if it's possible on ia64/ppc64/parisc64
> >>> to
On Fri 2017-09-08 22:49:51, Helge Deller wrote:
> On 08.09.2017 08:18, Sergey Senozhatsky wrote:
> > On (09/07/17 16:05), Luck, Tony wrote:
> > [..]
> if (not_a_function_descriptor(ptr))
> return ptr;
> >>>
> >>> I'm not sure if it's possible on ia64/ppc64/parisc64
> >>> to
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> On (09/07/17 16:05), Luck, Tony wrote:
> +static inline bool __mod_text_address(struct module *mod,
> + unsigned long addr) {
> + /* Make sure it's within the text section. */
> +
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> On (09/07/17 16:05), Luck, Tony wrote:
> +static inline bool __mod_text_address(struct module *mod,
> + unsigned long addr) {
> + /* Make sure it's within the text section. */
> +
On 08.09.2017 08:18, Sergey Senozhatsky wrote:
> On (09/07/17 16:05), Luck, Tony wrote:
> [..]
if (not_a_function_descriptor(ptr))
return ptr;
>>>
>>> I'm not sure if it's possible on ia64/ppc64/parisc64
>>> to reliably detect if it's a function descriptor or not.
>>
>>
On 08.09.2017 08:18, Sergey Senozhatsky wrote:
> On (09/07/17 16:05), Luck, Tony wrote:
> [..]
if (not_a_function_descriptor(ptr))
return ptr;
>>>
>>> I'm not sure if it's possible on ia64/ppc64/parisc64
>>> to reliably detect if it's a function descriptor or not.
>>
>>
On 08.09.2017 08:23, Sergey Senozhatsky wrote:
> On (09/06/17 22:27), Helge Deller wrote:
>> This patch series fixes the wrong usages of the %pF and %pS printk format
>> specifiers throughout the kernel code.
>>
>> Both specifiers have the same result on most architectures. But on ia64,
>> ppc64
On 08.09.2017 08:23, Sergey Senozhatsky wrote:
> On (09/06/17 22:27), Helge Deller wrote:
>> This patch series fixes the wrong usages of the %pF and %pS printk format
>> specifiers throughout the kernel code.
>>
>> Both specifiers have the same result on most architectures. But on ia64,
>> ppc64
On 08.09.2017 19:25, Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
>> if the addr is not in kernel .text, then try dereferencing it and check
>> if the dereferenced addr is in kernel .text.
>
> If it really is a function pointer, then we know that it is
On 08.09.2017 19:25, Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
>> if the addr is not in kernel .text, then try dereferencing it and check
>> if the dereferenced addr is in kernel .text.
>
> If it really is a function pointer, then we know that it is
On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
> if the addr is not in kernel .text, then try dereferencing it and check
> if the dereferenced addr is in kernel .text.
If it really is a function pointer, then we know that it is safe
to dereference. But if it isn't, then maybe
On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
> if the addr is not in kernel .text, then try dereferencing it and check
> if the dereferenced addr is in kernel .text.
If it really is a function pointer, then we know that it is safe
to dereference. But if it isn't, then maybe
On (09/06/17 22:27), Helge Deller wrote:
> This patch series fixes the wrong usages of the %pF and %pS printk format
> specifiers throughout the kernel code.
>
> Both specifiers have the same result on most architectures. But on ia64, ppc64
> and parisc64 architectures the %pF specifier does an
On (09/06/17 22:27), Helge Deller wrote:
> This patch series fixes the wrong usages of the %pF and %pS printk format
> specifiers throughout the kernel code.
>
> Both specifiers have the same result on most architectures. But on ia64, ppc64
> and parisc64 architectures the %pF specifier does an
On (09/07/17 16:05), Luck, Tony wrote:
[..]
> >>if (not_a_function_descriptor(ptr))
> >>return ptr;
> >
> > I'm not sure if it's possible on ia64/ppc64/parisc64
> > to reliably detect if it's a function descriptor or not.
>
> Agreed. I don't know how to write this test (without
On (09/07/17 16:05), Luck, Tony wrote:
[..]
> >>if (not_a_function_descriptor(ptr))
> >>return ptr;
> >
> > I'm not sure if it's possible on ia64/ppc64/parisc64
> > to reliably detect if it's a function descriptor or not.
>
> Agreed. I don't know how to write this test (without
On Thu, 2017-09-07 at 14:38 +0200, Helge Deller wrote:
> Instead, maybe adding some checks to scripts/checkpatch.pl can help?
> E.g. warn if %pF is used in combination with the keywords like
> _builtin_return_address, _RET_IP_, and similar.
coccinelle is probably a better tool for that.
On Thu, 2017-09-07 at 14:38 +0200, Helge Deller wrote:
> Instead, maybe adding some checks to scripts/checkpatch.pl can help?
> E.g. warn if %pF is used in combination with the keywords like
> _builtin_return_address, _RET_IP_, and similar.
coccinelle is probably a better tool for that.
>> if (not_a_function_descriptor(ptr))
>> return ptr;
>
> I'm not sure if it's possible on ia64/ppc64/parisc64
> to reliably detect if it's a function descriptor or not.
Agreed. I don't know how to write this test (without changing the compiler to
put the pointers in a separate
>> if (not_a_function_descriptor(ptr))
>> return ptr;
>
> I'm not sure if it's possible on ia64/ppc64/parisc64
> to reliably detect if it's a function descriptor or not.
Agreed. I don't know how to write this test (without changing the compiler to
put the pointers in a separate
On 07.09.2017 11:51, Sergey Senozhatsky wrote:
> On (09/07/17 18:36), Sergey Senozhatsky wrote:
> [..]
>>> I can look into adding such check-code, but even then the warning will
>>> only show up if you run on ia64, ppc64 and parisc64.
>
> sorry, not sure I understand the "warning" part.
I was
On 07.09.2017 11:51, Sergey Senozhatsky wrote:
> On (09/07/17 18:36), Sergey Senozhatsky wrote:
> [..]
>>> I can look into adding such check-code, but even then the warning will
>>> only show up if you run on ia64, ppc64 and parisc64.
>
> sorry, not sure I understand the "warning" part.
I was
On (09/07/17 18:36), Sergey Senozhatsky wrote:
[..]
> > I can look into adding such check-code, but even then the warning will
> > only show up if you run on ia64, ppc64 and parisc64.
sorry, not sure I understand the "warning" part.
what I'm thinking about is:
- every platform that needs
On (09/07/17 18:36), Sergey Senozhatsky wrote:
[..]
> > I can look into adding such check-code, but even then the warning will
> > only show up if you run on ia64, ppc64 and parisc64.
sorry, not sure I understand the "warning" part.
what I'm thinking about is:
- every platform that needs
(Cc Tony, Fenghua, Benjamin, Paul, Michael)
a brief description:
original patch set:
lkml.kernel.org/r/1504729681-3504-1-git-send-email-del...@gmx.de
start of this discussion:
lkml.kernel.org/r/20170907075653.GA533@jagdpanzerIV.localdomain
basically we are looking at possibilities to make
(Cc Tony, Fenghua, Benjamin, Paul, Michael)
a brief description:
original patch set:
lkml.kernel.org/r/1504729681-3504-1-git-send-email-del...@gmx.de
start of this discussion:
lkml.kernel.org/r/20170907075653.GA533@jagdpanzerIV.localdomain
basically we are looking at possibilities to make
On 07.09.2017 10:32, Sergey Senozhatsky wrote:
> On (09/07/17 16:56), Sergey Senozhatsky wrote:
> [..]
> probe_kernel_address() handles the page fault and returns -EFAULT if
> you give it bad pointer. module_address_lookup() and get_symbol_pos()
> seems to be smart enough not to crash on bad
On 07.09.2017 10:32, Sergey Senozhatsky wrote:
> On (09/07/17 16:56), Sergey Senozhatsky wrote:
> [..]
> probe_kernel_address() handles the page fault and returns -EFAULT if
> you give it bad pointer. module_address_lookup() and get_symbol_pos()
> seems to be smart enough not to crash on bad
On (09/07/17 16:56), Sergey Senozhatsky wrote:
[..]
> BTW, are we sure we can crash? when attempt to deference IP from
> the given descriptor? shall we handle page fault in this case and
> do something sane? just asking.
I don't know... does the below code make any sense?
quick and dirty. NOT
On (09/07/17 16:56), Sergey Senozhatsky wrote:
[..]
> BTW, are we sure we can crash? when attempt to deference IP from
> the given descriptor? shall we handle page fault in this case and
> do something sane? just asking.
I don't know... does the below code make any sense?
quick and dirty. NOT
Hello Helge,
On (09/07/17 08:01), Helge Deller wrote:
[..]
> > hm...
> > can we fix it in lib/vsprintf.c instead?
thanks for a quick reply.
> There is nothing to fix in vsprintf, because it is already providing
> both %pF and %pS for the two different architecture-specific API call
>
Hello Helge,
On (09/07/17 08:01), Helge Deller wrote:
[..]
> > hm...
> > can we fix it in lib/vsprintf.c instead?
thanks for a quick reply.
> There is nothing to fix in vsprintf, because it is already providing
> both %pF and %pS for the two different architecture-specific API call
>
On 07.09.2017 02:45, Sergey Senozhatsky wrote:
> On (09/06/17 22:27), Helge Deller wrote:
>> This patch series fixes the wrong usages of the %pF and %pS printk format
>> specifiers throughout the kernel code.
>>
>> Both specifiers have the same result on most architectures. But on ia64,
>> ppc64
On 07.09.2017 02:45, Sergey Senozhatsky wrote:
> On (09/06/17 22:27), Helge Deller wrote:
>> This patch series fixes the wrong usages of the %pF and %pS printk format
>> specifiers throughout the kernel code.
>>
>> Both specifiers have the same result on most architectures. But on ia64,
>> ppc64
On (09/06/17 22:27), Helge Deller wrote:
> This patch series fixes the wrong usages of the %pF and %pS printk format
> specifiers throughout the kernel code.
>
> Both specifiers have the same result on most architectures. But on ia64, ppc64
> and parisc64 architectures the %pF specifier does an
On (09/06/17 22:27), Helge Deller wrote:
> This patch series fixes the wrong usages of the %pF and %pS printk format
> specifiers throughout the kernel code.
>
> Both specifiers have the same result on most architectures. But on ia64, ppc64
> and parisc64 architectures the %pF specifier does an
This patch series fixes the wrong usages of the %pF and %pS printk format
specifiers throughout the kernel code.
Both specifiers have the same result on most architectures. But on ia64, ppc64
and parisc64 architectures the %pF specifier does an extra conversion because
there function pointers are
This patch series fixes the wrong usages of the %pF and %pS printk format
specifiers throughout the kernel code.
Both specifiers have the same result on most architectures. But on ia64, ppc64
and parisc64 architectures the %pF specifier does an extra conversion because
there function pointers are
60 matches
Mail list logo
