Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
On Tue, 31 May 2022 16:59:36 +1000, Michael Ellerman wrote: > The ppc_inst_as_str() macro tries to make printing variable length, > aka "prefixed", instructions convenient. It mostly succeeds, but it does > hide an on-stack buffer, which triggers stack protector. > > More problematically it doesn't compile at all with GCC 12, due to the > fact that it returns the char buffer declared inside the macro: > > [...] Applied to powerpc/next. [1/1] powerpc/64: Drop ppc_inst_as_str() https://git.kernel.org/powerpc/c/2a83afe72a2b5760155c2dd840c776aee292dc90 cheers
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
Hi! On Fri, Jun 03, 2022 at 03:03:05PM +1000, Jordan Niethe wrote: > On Thu, Jun 2, 2022 at 6:49 PM Segher Boessenkool > wrote: > > On Thu, Jun 02, 2022 at 01:01:04PM +1000, Jordan Niethe wrote: > > > > What about the more fundamental thing? Have the order of the two halves > > > > of a prefixed insn as ulong not depend on endianness? It really is two > > > > opcodes, and the prefixed one is first, always, even in LE. > > > The reason would be the value of as ulong is then used to write a > > > prefixed instruction to > > > memory with std. > > > If both endiannesses had the halves the same one of them would store > > > the suffix in front of the prefix. > > > > You cannot do such a (possibly) unaligned access from C though, not > > without invoking undefined behaviour. The compiler usually lets you get > > away with it, but there are no guarantees. You can make sure you only > > ever do such an access from assembler code of course. > > Would using inline assembly to do it be ok? You cannot refer to the instruction words as one 8-byte integer in memory (with "m" or similar), since such a thing is not valid C. You can input the address of it to the inline asm of course, and use a clobber "memory", or also give it the actual memory as input, but as bytes or words or such, with something like "m"(*(const u32 (*)[2]) ptr) > > Swapping the two halves of a register costs at most one insn. It is > > harmful premature optimisation to make this single cycle advantage > > override more important consideration (almost everything else :-) ) > > I'm not sure I follow. We are not doing this as an optimisation, but > out of the necessity of writing > the prefixed instruction to memory in a single instruction so that we > don't end up with half an > instruction in the kernel image. Ah. That does not necessitate having this different for LE at all though! The function that does the patching has to do it as one atomic memory access (which an ld only is because prefixed insns cannot cross 64-byte address boundaries btw), but that does not mean the kernel has to use the packing into one u64 it needs for that anywhere else, certainly not if that just complicates matters! Segher
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
On Thu, Jun 2, 2022 at 6:49 PM Segher Boessenkool wrote: > > On Thu, Jun 02, 2022 at 01:01:04PM +1000, Jordan Niethe wrote: > > > What about the more fundamental thing? Have the order of the two halves > > > of a prefixed insn as ulong not depend on endianness? It really is two > > > opcodes, and the prefixed one is first, always, even in LE. > > The reason would be the value of as ulong is then used to write a > > prefixed instruction to > > memory with std. > > If both endiannesses had the halves the same one of them would store > > the suffix in front of the prefix. > > You cannot do such a (possibly) unaligned access from C though, not > without invoking undefined behaviour. The compiler usually lets you get > away with it, but there are no guarantees. You can make sure you only > ever do such an access from assembler code of course. Would using inline assembly to do it be ok? > > Swapping the two halves of a register costs at most one insn. It is > harmful premature optimisation to make this single cycle advantage > override more important consideration (almost everything else :-) ) I'm not sure I follow. We are not doing this as an optimisation, but out of the necessity of writing the prefixed instruction to memory in a single instruction so that we don't end up with half an instruction in the kernel image. > > > Segher
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
On Thu, Jun 02, 2022 at 01:01:04PM +1000, Jordan Niethe wrote: > > What about the more fundamental thing? Have the order of the two halves > > of a prefixed insn as ulong not depend on endianness? It really is two > > opcodes, and the prefixed one is first, always, even in LE. > The reason would be the value of as ulong is then used to write a > prefixed instruction to > memory with std. > If both endiannesses had the halves the same one of them would store > the suffix in front of the prefix. You cannot do such a (possibly) unaligned access from C though, not without invoking undefined behaviour. The compiler usually lets you get away with it, but there are no guarantees. You can make sure you only ever do such an access from assembler code of course. Swapping the two halves of a register costs at most one insn. It is harmful premature optimisation to make this single cycle advantage override more important consideration (almost everything else :-) ) Segher
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
On Thu, Jun 2, 2022 at 2:22 AM Segher Boessenkool
wrote:
>
> On Wed, Jun 01, 2022 at 08:43:01PM +1000, Michael Ellerman wrote:
> > Segher Boessenkool writes:
> > > Hi!
> > >
> > > On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> > >> More problematically it doesn't compile at all with GCC 12, due to the
> > >> fact that it returns the char buffer declared inside the macro:
> > >
> > > It returns a pointer to a buffer on stack. It is not valid C to access
> > > that buffer after the function has returned (and indeed it does not
> > > work, in general).
> >
> > It's a statement expression though, not a function. So it doesn't return
> > as such, that would be obviously wrong.
>
> Yes, wrong language, my bad. But luckily it doesn't matter if this is a
> function or not anyway: the question is about scopes and lifetimes :-)
>
> > But I'm not a language lawyer, so presumably it's not valid to refer to
> > the variable after it's gone out of scope.
> >
> > Although we do use that same pattern in many places where the value of
> > the expression is a scalar type.
>
> It's an object with automatic storage duration. Its lifetime ends when
> the scope is left, which is at the end of the statement expression, so
> before the object is used.
>
> The value of the expression can be used just fine, sure, but the object
> it points to has ceased to exist, so dereferencing that pointer is
> undefined behaviour.
>
> > >> A simpler solution is to just print the value as an unsigned long. For
> > >> normal instructions the output is identical. For prefixed instructions
> > >> the value is printed as a single 64-bit quantity, whereas previously the
> > >> low half was printed first. But that is good enough for debug output,
> > >> especially as prefixed instructions will be rare in practice.
> > >
> > > Prefixed insns might be somewhat rare currently, but it will not stay
> > > that way.
> >
> > These are all printing kernel instructions, not userspace. I should have
> > said that in the change log.
>
> Ah! In that case, it will take quite a bit longer before you will see
> many prefixed insns, sure.
>
> > The kernel doesn't build for -mcpu=power10 because we haven't done any
> > changes for pcrel.
> >
> > We will do that one day, but not soon.
>
> Yeah, pcrel is the big hitter currently. But with the extra opcode
> space we have now, maybe something else will show up that even the
> kernel will use. I cannot predict the future very well :-)
>
> > > It is not hard to fix the problem here? The only tricky part is that
> > > ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
> > > no reason at all :-(
> > >
> > > If it didn't it would be easy to detect prefixed insns (because they
> > > then are guaranteed to be > 0x), and it is easy to print them
> > > with a space between the two opcodes, with a utility function:
> > >
> > > void print_insn_bytes_nicely(unsigned long insn)
> > > {
> > > if (insn > 0x)
> > > printf("%08x ", insn >> 32);
> > > printf("%08x", insn & 0x);
> > > }
> >
> > We don't want to do that because it can lead to interleaving messages
> > between different CPUs in the kernel log.
>
> Yuck.
>
> void print_insn_bytes_nicely(unsigned long insn)
> {
> if (insn > 0x)
> printf("%08x ", insn >> 32, insn & 0x);
> else
> printf("%08x", insn & 0x);
> }
>
> But it makes things much less enticing, alright.
>
> > In the medium term there's some changes to printk that might land soon
> > (printbuf), which would mean we could more easily define a custom printk
> > formatter for printing prefixed instructions.
>
> Yeah :-)
>
> What about the more fundamental thing? Have the order of the two halves
> of a prefixed insn as ulong not depend on endianness? It really is two
> opcodes, and the prefixed one is first, always, even in LE.
The reason would be the value of as ulong is then used to write a
prefixed instruction to
memory with std.
If both endiannesses had the halves the same one of them would store
the suffix in front of the prefix.
>
>
> Segher
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
On Wed, Jun 01, 2022 at 08:43:01PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > Hi!
> >
> > On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> >> More problematically it doesn't compile at all with GCC 12, due to the
> >> fact that it returns the char buffer declared inside the macro:
> >
> > It returns a pointer to a buffer on stack. It is not valid C to access
> > that buffer after the function has returned (and indeed it does not
> > work, in general).
>
> It's a statement expression though, not a function. So it doesn't return
> as such, that would be obviously wrong.
Yes, wrong language, my bad. But luckily it doesn't matter if this is a
function or not anyway: the question is about scopes and lifetimes :-)
> But I'm not a language lawyer, so presumably it's not valid to refer to
> the variable after it's gone out of scope.
>
> Although we do use that same pattern in many places where the value of
> the expression is a scalar type.
It's an object with automatic storage duration. Its lifetime ends when
the scope is left, which is at the end of the statement expression, so
before the object is used.
The value of the expression can be used just fine, sure, but the object
it points to has ceased to exist, so dereferencing that pointer is
undefined behaviour.
> >> A simpler solution is to just print the value as an unsigned long. For
> >> normal instructions the output is identical. For prefixed instructions
> >> the value is printed as a single 64-bit quantity, whereas previously the
> >> low half was printed first. But that is good enough for debug output,
> >> especially as prefixed instructions will be rare in practice.
> >
> > Prefixed insns might be somewhat rare currently, but it will not stay
> > that way.
>
> These are all printing kernel instructions, not userspace. I should have
> said that in the change log.
Ah! In that case, it will take quite a bit longer before you will see
many prefixed insns, sure.
> The kernel doesn't build for -mcpu=power10 because we haven't done any
> changes for pcrel.
>
> We will do that one day, but not soon.
Yeah, pcrel is the big hitter currently. But with the extra opcode
space we have now, maybe something else will show up that even the
kernel will use. I cannot predict the future very well :-)
> > It is not hard to fix the problem here? The only tricky part is that
> > ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
> > no reason at all :-(
> >
> > If it didn't it would be easy to detect prefixed insns (because they
> > then are guaranteed to be > 0x), and it is easy to print them
> > with a space between the two opcodes, with a utility function:
> >
> > void print_insn_bytes_nicely(unsigned long insn)
> > {
> > if (insn > 0x)
> > printf("%08x ", insn >> 32);
> > printf("%08x", insn & 0x);
> > }
>
> We don't want to do that because it can lead to interleaving messages
> between different CPUs in the kernel log.
Yuck.
void print_insn_bytes_nicely(unsigned long insn)
{
if (insn > 0x)
printf("%08x ", insn >> 32, insn & 0x);
else
printf("%08x", insn & 0x);
}
But it makes things much less enticing, alright.
> In the medium term there's some changes to printk that might land soon
> (printbuf), which would mean we could more easily define a custom printk
> formatter for printing prefixed instructions.
Yeah :-)
What about the more fundamental thing? Have the order of the two halves
of a prefixed insn as ulong not depend on endianness? It really is two
opcodes, and the prefixed one is first, always, even in LE.
Segher
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
Segher Boessenkool writes:
> Hi!
>
> On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
>> More problematically it doesn't compile at all with GCC 12, due to the
>> fact that it returns the char buffer declared inside the macro:
>
> It returns a pointer to a buffer on stack. It is not valid C to access
> that buffer after the function has returned (and indeed it does not
> work, in general).
It's a statement expression though, not a function. So it doesn't return
as such, that would be obviously wrong.
But I'm not a language lawyer, so presumably it's not valid to refer to
the variable after it's gone out of scope.
Although we do use that same pattern in many places where the value of
the expression is a scalar type.
>> A simpler solution is to just print the value as an unsigned long. For
>> normal instructions the output is identical. For prefixed instructions
>> the value is printed as a single 64-bit quantity, whereas previously the
>> low half was printed first. But that is good enough for debug output,
>> especially as prefixed instructions will be rare in practice.
>
> Prefixed insns might be somewhat rare currently, but it will not stay
> that way.
These are all printing kernel instructions, not userspace. I should have
said that in the change log.
The kernel doesn't build for -mcpu=power10 because we haven't done any
changes for pcrel.
We will do that one day, but not soon.
> It is not hard to fix the problem here? The only tricky part is that
> ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
> no reason at all :-(
>
> If it didn't it would be easy to detect prefixed insns (because they
> then are guaranteed to be > 0x), and it is easy to print them
> with a space between the two opcodes, with a utility function:
>
> void print_insn_bytes_nicely(unsigned long insn)
> {
> if (insn > 0x)
> printf("%08x ", insn >> 32);
> printf("%08x", insn & 0x);
> }
We don't want to do that because it can lead to interleaving messages
between different CPUs in the kernel log.
In the medium term there's some changes to printk that might land soon
(printbuf), which would mean we could more easily define a custom printk
formatter for printing prefixed instructions.
cheers
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
On 6/1/22 10:03, Bagas Sanjaya wrote: >> >> Reported-by: Bagas Sanjaya >> Reported-by: Petr Mladek >> Signed-off-by: Michael Ellerman > > The arch/powerpc/kernel/trace/ftrace.c builds successfully, however > there is also other build error for which I have reported at [1]. > > Thanks. > > Tested-by: Bagas Sanjaya > > [1]: https://lore.kernel.org/linuxppc-dev/ypbucprm61rli...@debian.me/ > Oops, I forget to mention: is this patch meant for backporting into stable tree? I don't see Fixes: tag and Cc: sta...@vger.kernel.org in the patch. -- An old man doll... just what I always wanted! - Clara
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
Hi,
On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> The ppc_inst_as_str() macro tries to make printing variable length,
> aka "prefixed", instructions convenient. It mostly succeeds, but it does
> hide an on-stack buffer, which triggers stack protector.
>
> More problematically it doesn't compile at all with GCC 12, due to the
> fact that it returns the char buffer declared inside the macro:
>
> arch/powerpc/kernel/trace/ftrace.c: In function '__ftrace_modify_call':
> ./include/linux/printk.h:475:44: error: using a dangling pointer to '__str'
> [-Werror=dangling-pointer=]
> 475 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt,
> ##__VA_ARGS__)
> ...
> arch/powerpc/kernel/trace/ftrace.c:567:17: note: in expansion of macro
> 'pr_err'
> 567 | pr_err("Not expected bl: opcode is %s\n",
> ppc_inst_as_str(op));
> | ^~
> ./arch/powerpc/include/asm/inst.h:156:14: note: '__str' declared here
> 156 | char __str[PPC_INST_STR_LEN]; \
> | ^
>
> This could be fixed by having the caller declare the buffer, but in some
> places there'd need to be two buffers. In all cases where
> ppc_inst_as_str() is used the output is not really meant for user
> consumption, it's almost always indicative of a kernel bug.
>
> A simpler solution is to just print the value as an unsigned long. For
> normal instructions the output is identical. For prefixed instructions
> the value is printed as a single 64-bit quantity, whereas previously the
> low half was printed first. But that is good enough for debug output,
> especially as prefixed instructions will be rare in practice.
>
> Old:
> c070 6042 ori r2,r2,0
> c074 0411 e580fb00 .long 0xe580fb000411
>
> New:
> c010f90c 6042 ori r2,r2,0
> c010f910 e580fb000411 .long 0xe580fb000411
>
> Reported-by: Bagas Sanjaya
> Reported-by: Petr Mladek
> Signed-off-by: Michael Ellerman
The arch/powerpc/kernel/trace/ftrace.c builds successfully, however
there is also other build error for which I have reported at [1].
Thanks.
Tested-by: Bagas Sanjaya
[1]: https://lore.kernel.org/linuxppc-dev/ypbucprm61rli...@debian.me/
--
An old man doll... just what I always wanted! - Clara
Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()
Hi!
On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> More problematically it doesn't compile at all with GCC 12, due to the
> fact that it returns the char buffer declared inside the macro:
It returns a pointer to a buffer on stack. It is not valid C to access
that buffer after the function has returned (and indeed it does not
work, in general).
> A simpler solution is to just print the value as an unsigned long. For
> normal instructions the output is identical. For prefixed instructions
> the value is printed as a single 64-bit quantity, whereas previously the
> low half was printed first. But that is good enough for debug output,
> especially as prefixed instructions will be rare in practice.
Prefixed insns might be somewhat rare currently, but it will not stay
that way.
It is not hard to fix the problem here? The only tricky part is that
ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
no reason at all :-(
If it didn't it would be easy to detect prefixed insns (because they
then are guaranteed to be > 0x), and it is easy to print them
with a space between the two opcodes, with a utility function:
void print_insn_bytes_nicely(unsigned long insn)
{
if (insn > 0x)
printf("%08x ", insn >> 32);
printf("%08x", insn & 0x);
}
or something like that.
Segher
