* Re: Endless soft-lockups for compiling workload since next-20200519
From: Qian Cai @ 2020-05-20 14:06 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alexandre Chartre, Paul E. McKenney, Frederic Weisbecker,
Linux Kernel Mailing List, Borislav Petkov, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <20200520125056.GC325280@hirez.programming.kicks-ass.net>
On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote:
> On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
> > Just a head up. Repeatedly compiling kernels for a while would trigger
> > endless soft-lockups since next-20200519 on both x86_64 and powerpc.
> > .config are in,
>
> Could be 90b5363acd47 ("sched: Clean up scheduler_ipi()"), although I've
> not seen anything like that myself. Let me go have a look.
Yes, I ended up figuring out the same commit a bit earlier. Since then I
reverted that commit and its dependency,
2a0a24ebb499 ("sched: Make scheduler_ipi inline")
Everything works fine so far.
>
>
> In as far as the logs are readable (they're a wrapped mess, please don't
> do that!), they contain very little useful, as is typical with IPIs :/
Sorry about that. I forgot that gmail webUI will wrap things around. I will
switch to mutt.
>
> > [ 1167.993773][ C1] WARNING: CPU: 1 PID: 0 at kernel/smp.c:127
> > flush_smp_call_function_queue+0x1fa/0x2e0
> > [ 1168.003333][ C1] Modules linked in: nls_iso8859_1 nls_cp437 vfat
> > fat kvm_amd ses kvm enclosure dax_pmem irqbypass dax_pmem_core efivars
> > acpi_cpufreq efivarfs ip_tables x_tables xfs sd_mod smartpqi
> > scsi_transport_sas tg3 mlx5_core libphy firmware_class dm_mirror
> > dm_region_hash dm_log dm_mod
> > [ 1168.029492][ C1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> > 5.7.0-rc6-next-20200519 #1
> > [ 1168.037665][ C1] Hardware name: HPE ProLiant DL385
> > Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> > [ 1168.046978][ C1] RIP: 0010:flush_smp_call_function_queue+0x1fa/0x2e0
> > [ 1168.053658][ C1] Code: 01 0f 87 c9 12 00 00 83 e3 01 0f 85 cc fe
> > ff ff 48 c7 c7 c0 55 a9 8f c6 05 f6 86 cd 01 01 e8 de 09 ea ff 0f 0b
> > e9 b2 fe ff ff <0f> 0b e9 52 ff ff ff 0f 0b e9 f2 fe ff ff 65 44 8b 25
> > 10 52 3f 71
> > [ 1168.073262][ C1] RSP: 0018:ffffc90000178918 EFLAGS: 00010046
> > [ 1168.079253][ C1] RAX: 0000000000000000 RBX: ffff8888430c58f8
> > RCX: ffffffff8ec26083
> > [ 1168.087156][ C1] RDX: 0000000000000003 RSI: dffffc0000000000
> > RDI: ffff8888430c58f8
> > [ 1168.095054][ C1] RBP: ffffc900001789a8 R08: ffffed1108618cec
> > R09: ffffed1108618cec
> > [ 1168.102964][ C1] R10: ffff8888430c675b R11: 0000000000000000
> > R12: ffff8888430c58e0
> > [ 1168.110866][ C1] R13: ffffffff8eb30c40 R14: ffff8888430c5880
> > R15: ffff8888430c58e0
> > [ 1168.118767][ C1] FS: 0000000000000000(0000)
> > GS:ffff888843080000(0000) knlGS:0000000000000000
> > [ 1168.127628][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 1168.134129][ C1] CR2: 000055b169604560 CR3: 0000000d08a14000
> > CR4: 00000000003406e0
> > [ 1168.142026][ C1] Call Trace:
> > [ 1168.145206][ C1] <IRQ>
> > [ 1168.147957][ C1] ? smp_call_on_cpu_callback+0xd0/0xd0
> > [ 1168.153421][ C1] ? rcu_read_lock_sched_held+0xac/0xe0
> > [ 1168.158880][ C1] ? rcu_read_lock_bh_held+0xc0/0xc0
> > [ 1168.164076][ C1] generic_smp_call_function_single_interrupt+0x13/0x2b
> > [ 1168.170938][ C1] smp_call_function_single_interrupt+0x157/0x4e0
> > [ 1168.177278][ C1] ? smp_call_function_interrupt+0x4e0/0x4e0
> > [ 1168.183172][ C1] ? interrupt_entry+0xe4/0xf0
> > [ 1168.187846][ C1] ? trace_hardirqs_off_caller+0x8d/0x1f0
> > [ 1168.193478][ C1] ? trace_hardirqs_on_caller+0x1f0/0x1f0
> > [ 1168.199116][ C1] ? _nohz_idle_balance+0x221/0x360
> > [ 1168.204228][ C1] ? trace_hardirqs_off_thunk+0x1a/0x1c
> > [ 1168.209690][ C1] call_function_single_interrupt+0xf/0x20
^ permalink raw reply
* Re: [Regression 5.7-rc1] Random hangs on 32-bit PowerPC (PowerBook6,7)
From: Christophe Leroy @ 2020-05-20 13:53 UTC (permalink / raw)
To: Aneesh Kumar K.V, Rui Salvaterra; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <877dx6g1rr.fsf@linux.ibm.com>
Le 20/05/2020 à 15:43, Aneesh Kumar K.V a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>
>> Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :
>>> Hi again, Christophe,
>>>
>>> On Mon, 18 May 2020 at 15:03, Christophe Leroy
>>> <christophe.leroy@csgroup.eu> wrote:
>>>>
>>>> Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
>>>> have broken swap.
>>>
>>> Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
>>> survives the beating. I'll be happy to test a definitive patch!
>>>
>>
>> Yeah I discovered recently that the way swap is implemented on powerpc
>> expects RW and other important bits not be one of the 3 least
>> significant bits (see __pte_to_swp_entry() )
>
> The last 3 bits are there to track the _PAGE_PRESENT right? What is the
> RW dependency there? Are you suggesting of read/write migration entry?
> A swap entry should not retain the pte rw bits right?
>
> A swap entry is built using swap type + offset. And it should not have a
> dependency on pte RW bits. Along with type and offset we also should
> have the ability to mark it as a pte entry and also set not present
> bits. With that understanding what am I missing here?
That's probably me who is missing something, I have not digged into the
swap functionning yet indeed, so that was only my first feeling.
By the way, the problems is definitely due to the order changes in the
PTE bits, whether that's because _PAGE_RW was moved to the last 3 bits
or whether that's because _PAGE_PRESENT was moved out of the last 3
bits, I don't know yet.
My (bad) understanding is from the fact that __pte_to_swp_entry() is a
right shift by 3 bits, so it looses the last 3 bits, and therefore
__swp_entry_to_pte(__pte_to_swp_entry(pte)) looses the last 3 bits of a PTE.
Is there somewhere a description of how swap works exactly ?
Christophe
^ permalink raw reply
* Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
From: rananta @ 2020-05-20 13:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg KH, andrew, linuxppc-dev, linux-kernel
In-Reply-To: <cb5bd2b2-f33a-b541-ed3c-70da14c7252d@suse.cz>
On 2020-05-20 02:38, Jiri Slaby wrote:
> On 15. 05. 20, 1:22, rananta@codeaurora.org wrote:
>> On 2020-05-13 00:04, Greg KH wrote:
>>> On Tue, May 12, 2020 at 02:39:50PM -0700, rananta@codeaurora.org
>>> wrote:
>>>> On 2020-05-12 01:25, Greg KH wrote:
>>>> > On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
>>>> > > commit bdb498c20040616e94b05c31a0ceb3e134b7e829
>>>> > > Author: Jiri Slaby <jslaby@suse.cz>
>>>> > > Date: Tue Aug 7 21:48:04 2012 +0200
>>>> > >
>>>> > > TTY: hvc_console, add tty install
>>>> > >
>>>> > > added hvc_install but did not move 'tty->driver_data = NULL;' from
>>>> > > hvc_open's fail path to hvc_cleanup.
>>>> > >
>>>> > > IOW hvc_open now NULLs tty->driver_data even for another task which
>>>> > > opened the tty earlier. The same holds for
>>>> > > "tty_port_tty_set(&hp->port,
>>>> > > NULL);" there. And actually "tty_port_put(&hp->port);" is also
>>>> > > incorrect
>>>> > > for the 2nd task opening the tty.
>>>> > >
>
> ...
>
>> These are the traces you get when the issue happens:
>> [ 154.212291] hvc_install called for pid: 666
>> [ 154.216705] hvc_open called for pid: 666
>> [ 154.233657] hvc_open: request_irq failed with rc -22.
>> [ 154.238934] hvc_open called for pid: 678
>> [ 154.243012] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000000000000c4
>> # hvc_install isn't called for pid: 678 as the file wasn't closed yet.
>
> Nice. Does the attached help?
Yeah, it looks good. I think it also eliminates the port.count reference
issue discussed on the v2 patch. Are you planning to mainline this?
>
> I wonder how comes the tty_port_put in hvc_open does not cause a UAF? I
> would say hvc_open fails, tty_port_put is called. It decrements the
> reference taken in hvc_install. So far so good.
>
> Now, this should happen IMO:
> tty_open
> -> hvc_open (fails)
> -> tty_port_put
hvc_console driver defines port->ops->destruct(). Upon tty_port_put(),
the
tty_port_destructor() calls port->ops->destruct(), rather than
kfree(port).
> -> tty_release
> -> tty_release_struct
> -> tty_kref_put
> -> queue_release_one_tty
> SCHEDULED WORKQUEUE
> release_one_tty
> -> hvc_cleanup
> -> tty_port_put (should die terrible death now)
Since port is not free'd, I think we should be good.
>
> What am I missing?
>
> thanks,
Thank you.
Raghavendra
^ permalink raw reply
* Re: [Regression 5.7-rc1] Random hangs on 32-bit PowerPC (PowerBook6, 7)
From: Aneesh Kumar K.V @ 2020-05-20 13:43 UTC (permalink / raw)
To: Christophe Leroy, Rui Salvaterra; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <c00ed41c-e13e-6bd6-4084-501ca14adb4c@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 18/05/2020 à 17:19, Rui Salvaterra a écrit :
>> Hi again, Christophe,
>>
>> On Mon, 18 May 2020 at 15:03, Christophe Leroy
>> <christophe.leroy@csgroup.eu> wrote:
>>>
>>> Can you try reverting 697ece78f8f749aeea40f2711389901f0974017a ? It may
>>> have broken swap.
>>
>> Yeah, that was a good call. :) Linux 5.7-rc1 with the revert on top
>> survives the beating. I'll be happy to test a definitive patch!
>>
>
> Yeah I discovered recently that the way swap is implemented on powerpc
> expects RW and other important bits not be one of the 3 least
> significant bits (see __pte_to_swp_entry() )
The last 3 bits are there to track the _PAGE_PRESENT right? What is the
RW dependency there? Are you suggesting of read/write migration entry?
A swap entry should not retain the pte rw bits right?
A swap entry is built using swap type + offset. And it should not have a
dependency on pte RW bits. Along with type and offset we also should
have the ability to mark it as a pte entry and also set not present
bits. With that understanding what am I missing here?
>
> I guess the easiest for the time being is to revert the commit with a
> proper explanation of the issue, then one day we'll modify the way
> powerpc manages swap.
>
-aneesh
^ permalink raw reply
* [PATCH] powerpc/64s: Disable STRICT_KERNEL_RWX
From: Michael Ellerman @ 2020-05-20 13:36 UTC (permalink / raw)
To: linuxppc-dev
Several strange crashes have been eventually traced back to
STRICT_KERNEL_RWX and its interaction with code patching.
Various paths in our ftrace, kprobes and other patching code need to
be hardened against patching failures, otherwise we can end up running
with partially/incorrectly patched ftrace paths, kprobes or jump
labels, which can then cause strange crashes.
Although fixes for those are in development, they're not -rc material.
There also seem to be problems with the underlying strict RWX logic,
which needs further debugging.
So for now disable STRICT_KERNEL_RWX on 64-bit to prevent people from
enabling the option and tripping over the bugs.
Fixes: 1e0fc9d1eb2b ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some configs")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 924c541a9260..d13b5328ca10 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -130,7 +130,7 @@ config PPC
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_MEMBARRIER_CALLBACKS
select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE && PPC_BOOK3S_64
- select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !HIBERNATION)
+ select ARCH_HAS_STRICT_KERNEL_RWX if (PPC32 && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE
select ARCH_HAS_UACCESS_MCSAFE if PPC64
--
2.25.1
^ permalink raw reply related
* Re: Endless soft-lockups for compiling workload since next-20200519
From: Peter Zijlstra @ 2020-05-20 12:50 UTC (permalink / raw)
To: Qian Cai
Cc: Paul E. McKenney, Frederic Weisbecker, Linux Kernel Mailing List,
Borislav Petkov, Thomas Gleixner, linuxppc-dev
In-Reply-To: <CAG=TAF6jUsQrW-fjbS3vpjkMfn8=MUDsuQxjk3NMfvQa250RHA@mail.gmail.com>
On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
> Just a head up. Repeatedly compiling kernels for a while would trigger
> endless soft-lockups since next-20200519 on both x86_64 and powerpc.
> .config are in,
Could be 90b5363acd47 ("sched: Clean up scheduler_ipi()"), although I've
not seen anything like that myself. Let me go have a look.
In as far as the logs are readable (they're a wrapped mess, please don't
do that!), they contain very little useful, as is typical with IPIs :/
> [ 1167.993773][ C1] WARNING: CPU: 1 PID: 0 at kernel/smp.c:127
> flush_smp_call_function_queue+0x1fa/0x2e0
> [ 1168.003333][ C1] Modules linked in: nls_iso8859_1 nls_cp437 vfat
> fat kvm_amd ses kvm enclosure dax_pmem irqbypass dax_pmem_core efivars
> acpi_cpufreq efivarfs ip_tables x_tables xfs sd_mod smartpqi
> scsi_transport_sas tg3 mlx5_core libphy firmware_class dm_mirror
> dm_region_hash dm_log dm_mod
> [ 1168.029492][ C1] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 5.7.0-rc6-next-20200519 #1
> [ 1168.037665][ C1] Hardware name: HPE ProLiant DL385
> Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
> [ 1168.046978][ C1] RIP: 0010:flush_smp_call_function_queue+0x1fa/0x2e0
> [ 1168.053658][ C1] Code: 01 0f 87 c9 12 00 00 83 e3 01 0f 85 cc fe
> ff ff 48 c7 c7 c0 55 a9 8f c6 05 f6 86 cd 01 01 e8 de 09 ea ff 0f 0b
> e9 b2 fe ff ff <0f> 0b e9 52 ff ff ff 0f 0b e9 f2 fe ff ff 65 44 8b 25
> 10 52 3f 71
> [ 1168.073262][ C1] RSP: 0018:ffffc90000178918 EFLAGS: 00010046
> [ 1168.079253][ C1] RAX: 0000000000000000 RBX: ffff8888430c58f8
> RCX: ffffffff8ec26083
> [ 1168.087156][ C1] RDX: 0000000000000003 RSI: dffffc0000000000
> RDI: ffff8888430c58f8
> [ 1168.095054][ C1] RBP: ffffc900001789a8 R08: ffffed1108618cec
> R09: ffffed1108618cec
> [ 1168.102964][ C1] R10: ffff8888430c675b R11: 0000000000000000
> R12: ffff8888430c58e0
> [ 1168.110866][ C1] R13: ffffffff8eb30c40 R14: ffff8888430c5880
> R15: ffff8888430c58e0
> [ 1168.118767][ C1] FS: 0000000000000000(0000)
> GS:ffff888843080000(0000) knlGS:0000000000000000
> [ 1168.127628][ C1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1168.134129][ C1] CR2: 000055b169604560 CR3: 0000000d08a14000
> CR4: 00000000003406e0
> [ 1168.142026][ C1] Call Trace:
> [ 1168.145206][ C1] <IRQ>
> [ 1168.147957][ C1] ? smp_call_on_cpu_callback+0xd0/0xd0
> [ 1168.153421][ C1] ? rcu_read_lock_sched_held+0xac/0xe0
> [ 1168.158880][ C1] ? rcu_read_lock_bh_held+0xc0/0xc0
> [ 1168.164076][ C1] generic_smp_call_function_single_interrupt+0x13/0x2b
> [ 1168.170938][ C1] smp_call_function_single_interrupt+0x157/0x4e0
> [ 1168.177278][ C1] ? smp_call_function_interrupt+0x4e0/0x4e0
> [ 1168.183172][ C1] ? interrupt_entry+0xe4/0xf0
> [ 1168.187846][ C1] ? trace_hardirqs_off_caller+0x8d/0x1f0
> [ 1168.193478][ C1] ? trace_hardirqs_on_caller+0x1f0/0x1f0
> [ 1168.199116][ C1] ? _nohz_idle_balance+0x221/0x360
> [ 1168.204228][ C1] ? trace_hardirqs_off_thunk+0x1a/0x1c
> [ 1168.209690][ C1] call_function_single_interrupt+0xf/0x20
^ permalink raw reply
* Re: [PATCH v2] tty: hvc: Fix data abort due to race in hvc_open
From: rananta @ 2020-05-20 12:43 UTC (permalink / raw)
To: Jiri Slaby; +Cc: gregkh, andrew, linuxppc-dev, linux-kernel, stable
In-Reply-To: <f84a9da7-bb0f-7538-fa00-968c9625335b@suse.cz>
On 2020-05-20 01:59, Jiri Slaby wrote:
> On 20. 05. 20, 8:47, Raghavendra Rao Ananta wrote:
>> Potentially, hvc_open() can be called in parallel when two tasks calls
>> open() on /dev/hvcX. In such a scenario, if the
>> hp->ops->notifier_add()
>> callback in the function fails, where it sets the tty->driver_data to
>> NULL, the parallel hvc_open() can see this NULL and cause a memory
>> abort.
>> Hence, do a NULL check at the beginning, before proceeding ahead.
>>
>> The issue can be easily reproduced by launching two tasks
>> simultaneously
>> that does an open() call on /dev/hvcX.
>> For example:
>> $ cat /dev/hvc0 & cat /dev/hvc0 &
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
>> ---
>> drivers/tty/hvc/hvc_console.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/tty/hvc/hvc_console.c
>> b/drivers/tty/hvc/hvc_console.c
>> index 436cc51c92c3..80709f754cc8 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -350,6 +350,9 @@ static int hvc_open(struct tty_struct *tty, struct
>> file * filp)
>> unsigned long flags;
>> int rc = 0;
>>
>> + if (!hp)
>> + return -ENODEV;
>> +
>
> This is still not fixing the bug properly. See:
> https://lore.kernel.org/linuxppc-dev/0f7791f5-0a53-59f6-7277-247a789f30c2@suse.cz/
>
> In particular, the paragraph starting "IOW".
>
You are right. This doesn't fix the problem entirely. There are other
parts to it which is
not handled in a clean way by the driver. Apart from the things you've
mentioned, it doesn't
seem to handle the hp->port.count correctly as well.
hvc_open:
hp->port.count++
hp->ops->notifier_add(hp, hp->data) fails
tty->driver_data = NULL
hvc_close:
returns immediately as tty->driver_data == NULL, without
hp->port.count--
This would leave the port in a stale state, and the second caller of
hvc_open doesn't get
a chance to call/retry hp->ops->notifier_add(hp, hp->data);
However, the patch is not trying to address the logical issues with
hvc_open and hvc_close.
It's only trying to eliminate the potential NULL pointer dereference,
leading to a panic.
From what I see, the hvc_open is serialized by tty_lock, and adding a
NULL check here is
preventing the second caller.
> thanks,
Thank you.
Raghavendra
^ permalink raw reply
* Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Mark Brown @ 2020-05-20 12:38 UTC (permalink / raw)
To: Shengjiu Wang
Cc: sumit.semwal, linaro-mm-sig, Linux-ALSA, linuxppc-dev,
linux-kernel, Timur Tabi, Xiubo Li, shawnguo, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, dri-devel, perex, Nicolin Chen,
linux-imx, kernel, linux-media, Fabio Estevam, s.hauer,
linux-arm-kernel, Lucas Stach
In-Reply-To: <CAA+D8APAMRwtVneqFsuBgAhozmQo3R0AQi0bVdUCQO4Af4xVfw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Wed, May 20, 2020 at 07:22:19PM +0800, Shengjiu Wang wrote:
> I see some driver also request dma channel in open() or hw_params().
> how can they avoid the defer probe issue?
> for example：
> sound/arm/pxa2xx-pcm-lib.c
> sound/soc/sprd/sprd-pcm-dma.c
Other drivers having problems means those drivers should be fixed, not
that we should copy the problems. In the case of the PXA driver that's
very old code which predates deferred probe by I'd guess a decade.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add ppc_inst_next()
From: Christophe Leroy @ 2020-05-20 12:30 UTC (permalink / raw)
To: Jordan Niethe, Michael Ellerman; +Cc: Christophe Leroy, linuxppc-dev
In-Reply-To: <CACzsE9p2c2ZLny86eOEtbyoiYtSNp0kmw9KE7GdfdxhqhWwLOQ@mail.gmail.com>
Le 20/05/2020 à 14:21, Jordan Niethe a écrit :
> On Wed, May 20, 2020 at 9:44 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> In a few places we want to calculate the address of the next
>> instruction. Previously that was simple, we just added 4 bytes, or if
>> using a u32 * we incremented that pointer by 1.
>>
>> But prefixed instructions make it more complicated, we need to advance
>> by either 4 or 8 bytes depending on the actual instruction. We also
>> can't do pointer arithmetic using struct ppc_inst, because it is
>> always 8 bytes in size on 64-bit, even though we might only need to
>> advance by 4 bytes.
>>
>> So add a ppc_inst_next() helper which calculates the location of the
>> next instruction, if the given instruction was located at the given
>> address. Note the instruction doesn't need to actually be at the
>> address in memory.
>>
>> Convert several locations to use it.
>>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>> arch/powerpc/include/asm/inst.h | 9 +++++++++
>> arch/powerpc/kernel/uprobes.c | 2 +-
>> arch/powerpc/lib/feature-fixups.c | 10 +++++-----
>> arch/powerpc/xmon/xmon.c | 2 +-
>> 4 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
>> index d82e0c99cfa1..7d5ee1309b92 100644
>> --- a/arch/powerpc/include/asm/inst.h
>> +++ b/arch/powerpc/include/asm/inst.h
>> @@ -100,6 +100,15 @@ static inline int ppc_inst_len(struct ppc_inst x)
>> return ppc_inst_prefixed(x) ? 8 : 4;
>> }
>>
>> +/*
>> + * Return the address of the next instruction, if the instruction @value was
>> + * located at @location.
>> + */
>> +static inline struct ppc_inst *ppc_inst_next(void *location, struct ppc_inst value)
>> +{
>> + return location + ppc_inst_len(value);
>> +}
> I think this is a good idea. I tried something similar in the initial
> post for an instruction type. I had:
> +#define PPC_INST_NEXT(ptr) ((ptr) += PPC_INST_LEN(DEREF_PPC_INST_PTR((ptr))))
> but how you've got it is much more clear/usable.
Yes I agree
> I wonder why not
> +static inline struct ppc_inst *ppc_inst_next(void *location)
> +{
> + return location + ppc_inst_len(ppc_inst_read((struct ppc_inst
> *)location);
> +}
Because as Michael explains, the instruction to be skipped might not yet
be at the pointed memory location (for instance in insert_bpts() )
>
>> +
>> int probe_user_read_inst(struct ppc_inst *inst,
>> struct ppc_inst __user *nip);
>>
>> diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
>> index 83e883e1a42d..683ba76919a7 100644
>> --- a/arch/powerpc/kernel/uprobes.c
>> +++ b/arch/powerpc/kernel/uprobes.c
>> @@ -112,7 +112,7 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
>> * support doesn't exist and have to fix-up the next instruction
>> * to be executed.
>> */
>> - regs->nip = utask->vaddr + ppc_inst_len(ppc_inst_read(&auprobe->insn));
>> + regs->nip = (unsigned long)ppc_inst_next((void *)utask->vaddr, auprobe->insn);
>>
>> user_disable_single_step(current);
>> return 0;
>> diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
>> index 80f320c2e189..0ad01eebf112 100644
>> --- a/arch/powerpc/lib/feature-fixups.c
>> +++ b/arch/powerpc/lib/feature-fixups.c
>> @@ -84,13 +84,13 @@ static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
>> src = alt_start;
>> dest = start;
>>
>> - for (; src < alt_end; src = (void *)src + ppc_inst_len(ppc_inst_read(src)),
>> - (dest = (void *)dest + ppc_inst_len(ppc_inst_read(dest)))) {
>> + for (; src < alt_end; src = ppc_inst_next(src, *src),
>> + dest = ppc_inst_next(dest, *dest)) {
> The reason to maybe use ppc_inst_read() in the helper instead of just
> *dest would be we don't always need to read 8 bytes.
And reading 8 bytes might trigger a page fault if we are reading the
very last non prefixed instruction of the last page.
>> if (patch_alt_instruction(src, dest, alt_start, alt_end))
>> return 1;
>> }
>>
>> - for (; dest < end; dest = (void *)dest + ppc_inst_len(ppc_inst(PPC_INST_NOP)))
>> + for (; dest < end; dest = ppc_inst_next(dest, ppc_inst(PPC_INST_NOP)))
> But then you wouldn't be able to do this as easily I guess.
>> raw_patch_instruction(dest, ppc_inst(PPC_INST_NOP));
>>
>> return 0;
>> @@ -405,8 +405,8 @@ static void do_final_fixups(void)
>> while (src < end) {
>> inst = ppc_inst_read(src);
>> raw_patch_instruction(dest, inst);
>> - src = (void *)src + ppc_inst_len(inst);
>> - dest = (void *)dest + ppc_inst_len(inst);
>> + src = ppc_inst_next(src, *src);
>> + dest = ppc_inst_next(dest, *dest);
>> }
>> #endif
>> }
>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>> index fb135f2cd6b0..aa123f56b7d4 100644
>> --- a/arch/powerpc/xmon/xmon.c
>> +++ b/arch/powerpc/xmon/xmon.c
>> @@ -939,7 +939,7 @@ static void insert_bpts(void)
>> }
>>
>> patch_instruction(bp->instr, instr);
>> - patch_instruction((void *)bp->instr + ppc_inst_len(instr),
>> + patch_instruction(ppc_inst_next(bp->instr, instr),
>> ppc_inst(bpinstr));
>> if (bp->enabled & BP_CIABR)
>> continue;
>> --
>> 2.25.1
>>
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc: Add ppc_inst_next()
From: Jordan Niethe @ 2020-05-20 12:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Christophe Leroy, linuxppc-dev
In-Reply-To: <20200520114446.956215-1-mpe@ellerman.id.au>
On Wed, May 20, 2020 at 9:44 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> In a few places we want to calculate the address of the next
> instruction. Previously that was simple, we just added 4 bytes, or if
> using a u32 * we incremented that pointer by 1.
>
> But prefixed instructions make it more complicated, we need to advance
> by either 4 or 8 bytes depending on the actual instruction. We also
> can't do pointer arithmetic using struct ppc_inst, because it is
> always 8 bytes in size on 64-bit, even though we might only need to
> advance by 4 bytes.
>
> So add a ppc_inst_next() helper which calculates the location of the
> next instruction, if the given instruction was located at the given
> address. Note the instruction doesn't need to actually be at the
> address in memory.
>
> Convert several locations to use it.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/inst.h | 9 +++++++++
> arch/powerpc/kernel/uprobes.c | 2 +-
> arch/powerpc/lib/feature-fixups.c | 10 +++++-----
> arch/powerpc/xmon/xmon.c | 2 +-
> 4 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
> index d82e0c99cfa1..7d5ee1309b92 100644
> --- a/arch/powerpc/include/asm/inst.h
> +++ b/arch/powerpc/include/asm/inst.h
> @@ -100,6 +100,15 @@ static inline int ppc_inst_len(struct ppc_inst x)
> return ppc_inst_prefixed(x) ? 8 : 4;
> }
>
> +/*
> + * Return the address of the next instruction, if the instruction @value was
> + * located at @location.
> + */
> +static inline struct ppc_inst *ppc_inst_next(void *location, struct ppc_inst value)
> +{
> + return location + ppc_inst_len(value);
> +}
I think this is a good idea. I tried something similar in the initial
post for an instruction type. I had:
+#define PPC_INST_NEXT(ptr) ((ptr) += PPC_INST_LEN(DEREF_PPC_INST_PTR((ptr))))
but how you've got it is much more clear/usable.
I wonder why not
+static inline struct ppc_inst *ppc_inst_next(void *location)
+{
+ return location + ppc_inst_len(ppc_inst_read((struct ppc_inst
*)location);
+}
> +
> int probe_user_read_inst(struct ppc_inst *inst,
> struct ppc_inst __user *nip);
>
> diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> index 83e883e1a42d..683ba76919a7 100644
> --- a/arch/powerpc/kernel/uprobes.c
> +++ b/arch/powerpc/kernel/uprobes.c
> @@ -112,7 +112,7 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> * support doesn't exist and have to fix-up the next instruction
> * to be executed.
> */
> - regs->nip = utask->vaddr + ppc_inst_len(ppc_inst_read(&auprobe->insn));
> + regs->nip = (unsigned long)ppc_inst_next((void *)utask->vaddr, auprobe->insn);
>
> user_disable_single_step(current);
> return 0;
> diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
> index 80f320c2e189..0ad01eebf112 100644
> --- a/arch/powerpc/lib/feature-fixups.c
> +++ b/arch/powerpc/lib/feature-fixups.c
> @@ -84,13 +84,13 @@ static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
> src = alt_start;
> dest = start;
>
> - for (; src < alt_end; src = (void *)src + ppc_inst_len(ppc_inst_read(src)),
> - (dest = (void *)dest + ppc_inst_len(ppc_inst_read(dest)))) {
> + for (; src < alt_end; src = ppc_inst_next(src, *src),
> + dest = ppc_inst_next(dest, *dest)) {
The reason to maybe use ppc_inst_read() in the helper instead of just
*dest would be we don't always need to read 8 bytes.
> if (patch_alt_instruction(src, dest, alt_start, alt_end))
> return 1;
> }
>
> - for (; dest < end; dest = (void *)dest + ppc_inst_len(ppc_inst(PPC_INST_NOP)))
> + for (; dest < end; dest = ppc_inst_next(dest, ppc_inst(PPC_INST_NOP)))
But then you wouldn't be able to do this as easily I guess.
> raw_patch_instruction(dest, ppc_inst(PPC_INST_NOP));
>
> return 0;
> @@ -405,8 +405,8 @@ static void do_final_fixups(void)
> while (src < end) {
> inst = ppc_inst_read(src);
> raw_patch_instruction(dest, inst);
> - src = (void *)src + ppc_inst_len(inst);
> - dest = (void *)dest + ppc_inst_len(inst);
> + src = ppc_inst_next(src, *src);
> + dest = ppc_inst_next(dest, *dest);
> }
> #endif
> }
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index fb135f2cd6b0..aa123f56b7d4 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -939,7 +939,7 @@ static void insert_bpts(void)
> }
>
> patch_instruction(bp->instr, instr);
> - patch_instruction((void *)bp->instr + ppc_inst_len(instr),
> + patch_instruction(ppc_inst_next(bp->instr, instr),
> ppc_inst(bpinstr));
> if (bp->enabled & BP_CIABR)
> continue;
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH] powerpc/configs/64s: Enable CONFIG_PRINTK_CALLER
From: Michael Ellerman @ 2020-05-20 12:12 UTC (permalink / raw)
To: linuxppc-dev
This adds the CPU or thread number to printk messages. This helps a
lot when deciphering concurrent oopses that have been interleaved.
Example output, of PID1 (T1) triggering a warning:
[ 1.581678][ T1] WARNING: CPU: 0 PID: 1 at crypto/rsa-pkcs1pad.c:539 pkcs1pad_verify+0x38/0x140
[ 1.581681][ T1] Modules linked in:
[ 1.581693][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc5-gcc-8.2.0-00121-gf84c2e595927-dirty #1515
[ 1.581700][ T1] NIP: c000000000207d64 LR: c000000000207d3c CTR: c000000000207d2c
[ 1.581708][ T1] REGS: c0000000fd2e7560 TRAP: 0700 Not tainted (5.5.0-rc5-gcc-8.2.0-00121-gf84c2e595927-dirty)
[ 1.581712][ T1] MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44000222 XER: 00040000
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/configs/powernv_defconfig | 1 +
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
index df8bdbaa5d8f..2de9aadf0f50 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -347,3 +347,4 @@ CONFIG_KVM_BOOK3S_64=m
CONFIG_KVM_BOOK3S_64_HV=m
CONFIG_VHOST_NET=m
CONFIG_PRINTK_TIME=y
+CONFIG_PRINTK_CALLER=y
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index bae8170d7401..57142a648ebd 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -358,6 +358,7 @@ CONFIG_CRYPTO_DEV_NX=y
CONFIG_CRYPTO_DEV_NX_ENCRYPT=m
CONFIG_CRYPTO_DEV_VMX=y
CONFIG_PRINTK_TIME=y
+CONFIG_PRINTK_CALLER=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACK_USAGE=y
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 0bea4d3ffb85..dfa4a726333b 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -322,3 +322,4 @@ CONFIG_KVM_BOOK3S_64=m
CONFIG_KVM_BOOK3S_64_HV=m
CONFIG_VHOST_NET=m
CONFIG_PRINTK_TIME=y
+CONFIG_PRINTK_CALLER=y
--
2.25.1
^ permalink raw reply related
* [PATCH] powerpc: Add ppc_inst_next()
From: Michael Ellerman @ 2020-05-20 11:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: christophe.leroy, jniethe5
In a few places we want to calculate the address of the next
instruction. Previously that was simple, we just added 4 bytes, or if
using a u32 * we incremented that pointer by 1.
But prefixed instructions make it more complicated, we need to advance
by either 4 or 8 bytes depending on the actual instruction. We also
can't do pointer arithmetic using struct ppc_inst, because it is
always 8 bytes in size on 64-bit, even though we might only need to
advance by 4 bytes.
So add a ppc_inst_next() helper which calculates the location of the
next instruction, if the given instruction was located at the given
address. Note the instruction doesn't need to actually be at the
address in memory.
Convert several locations to use it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/inst.h | 9 +++++++++
arch/powerpc/kernel/uprobes.c | 2 +-
arch/powerpc/lib/feature-fixups.c | 10 +++++-----
arch/powerpc/xmon/xmon.c | 2 +-
4 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
index d82e0c99cfa1..7d5ee1309b92 100644
--- a/arch/powerpc/include/asm/inst.h
+++ b/arch/powerpc/include/asm/inst.h
@@ -100,6 +100,15 @@ static inline int ppc_inst_len(struct ppc_inst x)
return ppc_inst_prefixed(x) ? 8 : 4;
}
+/*
+ * Return the address of the next instruction, if the instruction @value was
+ * located at @location.
+ */
+static inline struct ppc_inst *ppc_inst_next(void *location, struct ppc_inst value)
+{
+ return location + ppc_inst_len(value);
+}
+
int probe_user_read_inst(struct ppc_inst *inst,
struct ppc_inst __user *nip);
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index 83e883e1a42d..683ba76919a7 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -112,7 +112,7 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
* support doesn't exist and have to fix-up the next instruction
* to be executed.
*/
- regs->nip = utask->vaddr + ppc_inst_len(ppc_inst_read(&auprobe->insn));
+ regs->nip = (unsigned long)ppc_inst_next((void *)utask->vaddr, auprobe->insn);
user_disable_single_step(current);
return 0;
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index 80f320c2e189..0ad01eebf112 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -84,13 +84,13 @@ static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
src = alt_start;
dest = start;
- for (; src < alt_end; src = (void *)src + ppc_inst_len(ppc_inst_read(src)),
- (dest = (void *)dest + ppc_inst_len(ppc_inst_read(dest)))) {
+ for (; src < alt_end; src = ppc_inst_next(src, *src),
+ dest = ppc_inst_next(dest, *dest)) {
if (patch_alt_instruction(src, dest, alt_start, alt_end))
return 1;
}
- for (; dest < end; dest = (void *)dest + ppc_inst_len(ppc_inst(PPC_INST_NOP)))
+ for (; dest < end; dest = ppc_inst_next(dest, ppc_inst(PPC_INST_NOP)))
raw_patch_instruction(dest, ppc_inst(PPC_INST_NOP));
return 0;
@@ -405,8 +405,8 @@ static void do_final_fixups(void)
while (src < end) {
inst = ppc_inst_read(src);
raw_patch_instruction(dest, inst);
- src = (void *)src + ppc_inst_len(inst);
- dest = (void *)dest + ppc_inst_len(inst);
+ src = ppc_inst_next(src, *src);
+ dest = ppc_inst_next(dest, *dest);
}
#endif
}
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index fb135f2cd6b0..aa123f56b7d4 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -939,7 +939,7 @@ static void insert_bpts(void)
}
patch_instruction(bp->instr, instr);
- patch_instruction((void *)bp->instr + ppc_inst_len(instr),
+ patch_instruction(ppc_inst_next(bp->instr, instr),
ppc_inst(bpinstr));
if (bp->enabled & BP_CIABR)
continue;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
From: Shengjiu Wang @ 2020-05-20 11:22 UTC (permalink / raw)
To: Lucas Stach
Cc: sumit.semwal, linaro-mm-sig, Linux-ALSA, linuxppc-dev,
linux-kernel, Timur Tabi, Xiubo Li, shawnguo, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, dri-devel, perex, Nicolin Chen,
Mark Brown, linux-imx, kernel, Fabio Estevam, s.hauer,
linux-arm-kernel, linux-media
In-Reply-To: <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
Hi
On Wed, May 20, 2020 at 5:42 PM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > Hi
> >
> > On Tue, May 19, 2020 at 6:04 PM Lucas Stach <l.stach@pengutronix.de> wrote:
> > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > There are two requirements that we need to move the request
> > > > of dma channel from probe to open.
> > >
> > > How do you handle -EPROBE_DEFER return code from the channel request if
> > > you don't do it in probe?
> >
> > I use the dma_request_slave_channel or dma_request_channel instead
> > of dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER
> > return code.
>
> This is a pretty weak argument. The dmaengine device might probe after
> you try to get the channel. Using a function to request the channel
> that doesn't allow you to handle probe deferral is IMHO a bug and
> should be fixed, instead of building even more assumptions on top of
> it.
>
I see some driver also request dma channel in open() or hw_params().
how can they avoid the defer probe issue?
for example：
sound/arm/pxa2xx-pcm-lib.c
sound/soc/sprd/sprd-pcm-dma.c
> > > > - When dma device binds with power-domains, the power will
> > > > be enabled when we request dma channel. If the request of dma
> > > > channel happen on probe, then the power-domains will be always
> > > > enabled after kernel boot up, which is not good for power
> > > > saving, so we need to move the request of dma channel to .open();
> > >
> > > This is certainly something which could be fixed in the dmaengine
> > > driver.
> >
> > Dma driver always call the pm_runtime_get_sync in
> > device_alloc_chan_resources, the device_alloc_chan_resources is
> > called when channel is requested. so power is enabled on channel
> > request.
>
> So why can't you fix the dmaengine driver to do that RPM call at a
> later time when the channel is actually going to be used? This will
> allow further power savings with other slave devices than the audio
> PCM.
>
> Regards,
> Lucas
>
It seems the best place for calling pm_runtime_get_sync is the
device_alloc_chan_resources, and calling pm_runtime_put_sync
in the .device_free_chan_resources
For the slave_sg mode, the .device_prep_slave_sg and
.device_issue_pending will be called many times after
.device_alloc_chan_resources. so it is not good to call
pm_runtime_get_sync in .device_prep_slave_sg or
.device_issue_pending
best regards
wang shengjiu
^ permalink raw reply
* [PATCH] powerpc/xmon: Show task->thread.regs in process display
From: Michael Ellerman @ 2020-05-20 11:17 UTC (permalink / raw)
To: linuxppc-dev
Show the address of the tasks regs in the process listing in xmon. The
regs should always be on the stack page that we also print the address
of, but it's still helpful not to have to find them by hand.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/xmon/xmon.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index de585204d1d2..fb135f2cd6b0 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -3185,8 +3185,8 @@ static void show_task(struct task_struct *tsk)
(tsk->exit_state & EXIT_DEAD) ? 'E' :
(tsk->state & TASK_INTERRUPTIBLE) ? 'S' : '?';
- printf("%px %016lx %6d %6d %c %2d %s\n", tsk,
- tsk->thread.ksp,
+ printf("%16px %16lx %16px %6d %6d %c %2d %s\n", tsk,
+ tsk->thread.ksp, tsk->thread.regs,
tsk->pid, rcu_dereference(tsk->parent)->pid,
state, task_cpu(tsk),
tsk->comm);
@@ -3309,7 +3309,7 @@ static void show_tasks(void)
unsigned long tskv;
struct task_struct *tsk = NULL;
- printf(" task_struct ->thread.ksp PID PPID S P CMD\n");
+ printf(" task_struct ->thread.ksp ->thread.regs PID PPID S P CMD\n");
if (scanhex(&tskv))
tsk = (struct task_struct *)tskv;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc/5200: update contact email
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: linux-kernel, Wolfram Sang
Cc: devicetree, Rob Herring, Paul Mackerras, kernel, linuxppc-dev
In-Reply-To: <20200502142642.18979-1-wsa@kernel.org>
On Sat, 2 May 2020 16:26:42 +0200, Wolfram Sang wrote:
> My 'pengutronix' address is defunct for years. Merge the entries and use
> the proper contact address.
Applied to powerpc/next.
[1/1] powerpc/5200: update contact email
https://git.kernel.org/powerpc/c/ad0f522df1b2f4fe5d4ae6418e1ea216154a0662
cheers
^ permalink raw reply
* Re: [PATCH v4 0/2] powerpc/eeh: Release EEH device state synchronously
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev; +Cc: Nathan Lynch, Oliver O'Halloran
In-Reply-To: <cover.1588045502.git.sbobroff@linux.ibm.com>
On Tue, 28 Apr 2020 13:45:04 +1000, Sam Bobroff wrote:
> Here are some fixes and cleanups that have come from other work but that I
> think stand on their own.
>
> Only one patch ("Release EEH device state synchronously", suggested by Oliver
> O'Halloran) is a significant change: it moves the cleanup of some EEH device
> data out of the (possibly asynchronous) device release handler and into the
> (synchronously called) bus notifier. This is useful for future work as it makes
> it easier to reason about the lifetimes of EEH structures.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/eeh: Fix pseries_eeh_configure_bridge()
https://git.kernel.org/powerpc/c/6fa13640aea7bb0760846981aa2da4245307bd26
[2/2] powerpc/eeh: Release EEH device state synchronously
https://git.kernel.org/powerpc/c/466381ecdc741b1767d980e10b1ec49f6bde56f3
cheers
^ permalink raw reply
* Re: [PATCH v6 00/16] powerpc/watchpoint: Preparation for more than one watchpoint
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: mikey, Ravi Bangoria, mpe
Cc: christophe.leroy, apopple, peterz, fweisbec, oleg, npiggin,
linux-kernel, paulus, jolsa, naveen.n.rao, linuxppc-dev, mingo
In-Reply-To: <20200514111741.97993-1-ravi.bangoria@linux.ibm.com>
On Thu, 14 May 2020 16:47:25 +0530, Ravi Bangoria wrote:
> So far, powerpc Book3S code has been written with an assumption of
> only one watchpoint. But Power10[1] is introducing second watchpoint
> register (DAWR). Even though this patchset does not enable 2nd DAWR,
> it makes the infrastructure ready so that enabling 2nd DAWR should
> just be a matter of changing count.
>
> Existing functionality works fine with the patchset. I've tested it
> with perf, ptrace(gdb), xmon. All hw-breakpoint selftests are passing
> as well. And I've build tested for 8xx and 'AMCC 44x, 46x or 47x'.
>
> [...]
Applied to powerpc/next.
[01/16] powerpc/watchpoint: Rename current DAWR macros
https://git.kernel.org/powerpc/c/09f82b063aa9c248a3ef919aeec361054e7b044a
[02/16] powerpc/watchpoint: Add SPRN macros for second DAWR
https://git.kernel.org/powerpc/c/4a4ec2289a5d748cb64ff67ca8d74535a76a8436
[03/16] powerpc/watchpoint: Introduce function to get nr watchpoints dynamically
https://git.kernel.org/powerpc/c/a6ba44e8799230e36c8ab06fda7f77f421e9e795
[04/16] powerpc/watchpoint/ptrace: Return actual num of available watchpoints
https://git.kernel.org/powerpc/c/45093b382e0ac25c206b4dcd210c6be1f5e56e60
[05/16] powerpc/watchpoint: Provide DAWR number to set_dawr
https://git.kernel.org/powerpc/c/a18b834625d345bfa89c4e2754dd6cbb0133c4d7
[06/16] powerpc/watchpoint: Provide DAWR number to __set_breakpoint
https://git.kernel.org/powerpc/c/4a8a9379f2af4c9928529b3959bc2d8f7023c6bc
[07/16] powerpc/watchpoint: Get watchpoint count dynamically while disabling them
https://git.kernel.org/powerpc/c/c2919132734f29a7a33e1339bef8a67b11f322eb
[08/16] powerpc/watchpoint: Disable all available watchpoints when !dawr_force_enable
https://git.kernel.org/powerpc/c/22a214e461c5cc9428b86915d9cfcf84c6e11ad7
[09/16] powerpc/watchpoint: Convert thread_struct->hw_brk to an array
https://git.kernel.org/powerpc/c/303e6a9ddcdc168e92253c78cdb4bbe1e10d78b3
[10/16] powerpc/watchpoint: Use loop for thread_struct->ptrace_bps
https://git.kernel.org/powerpc/c/6b424efa119d5ea06b15ff240dddc3b4b9f9cdfb
[11/16] powerpc/watchpoint: Introduce is_ptrace_bp() function
https://git.kernel.org/powerpc/c/c9e82aeb197df2d93b1b4234bc0c80943fa594e8
[12/16] powerpc/watchpoint: Use builtin ALIGN*() macros
https://git.kernel.org/powerpc/c/e68ef121c1f4c38edf87a3354661ceb99d522729
[13/16] powerpc/watchpoint: Prepare handler to handle more than one watchpoint
https://git.kernel.org/powerpc/c/74c6881019b7d56c327fffc268d97adb5eb1b4f9
[14/16] powerpc/watchpoint: Don't allow concurrent perf and ptrace events
https://git.kernel.org/powerpc/c/29da4f91c0c1fbda12b8a31be0d564930208c92e
[15/16] powerpc/watchpoint/xmon: Don't allow breakpoint overwriting
https://git.kernel.org/powerpc/c/514db915e7b33e7eaf8e40192b93380f79b319b5
[16/16] powerpc/watchpoint/xmon: Support 2nd DAWR
https://git.kernel.org/powerpc/c/30df74d67d48949da87e3a5b57c381763e8fd526
cheers
^ permalink raw reply
* Re: [PATCH v4 00/16] powerpc: machine check and system reset fixes
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20200508043408.886394-1-npiggin@gmail.com>
On Fri, 8 May 2020 14:33:52 +1000, Nicholas Piggin wrote:
> Since v3, I fixed a compile error and returned the generic machine check
> exception handler to be NMI on 32 and 64e, as caught by Christophe's
> review.
>
> Also added the last patch, just found it by looking at the code, a
> review for 32s would be good.
>
> [...]
Patches 1-15 applied to powerpc/next.
[01/16] powerpc/64s/exception: Fix machine check no-loss idle wakeup
https://git.kernel.org/powerpc/c/8a5054d8cbbe03c68dcb0957c291c942132e4101
[02/16] powerpc/64s/exceptions: Fix in_mce accounting in unrecoverable path
https://git.kernel.org/powerpc/c/ac2a2a1417391180ef12f908a2864692d6d76d40
[03/16] powerpc/64s/exceptions: Change irq reconcile for NMIs from reusing _DAR to RESULT
https://git.kernel.org/powerpc/c/16754d25bd7d4e53a52b311d99cc7a8fba875d81
[04/16] powerpc/64s/exceptions: Machine check reconcile irq state
https://git.kernel.org/powerpc/c/f0fd9dd3c213c947dfb5bc2cad3ef5e30d3258ec
[05/16] powerpc/pseries/ras: Avoid calling rtas_token() in NMI paths
https://git.kernel.org/powerpc/c/7368b38b21bfa39df637701a480262c15ab1a49e
[06/16] powerpc/pseries/ras: Fix FWNMI_VALID off by one
https://git.kernel.org/powerpc/c/deb70f7a35a22dffa55b2c3aac71bc6fb0f486ce
[07/16] powerpc/pseries/ras: fwnmi avoid modifying r3 in error case
https://git.kernel.org/powerpc/c/dff681e95a23f28b3c688a8bd5535f78bd726bc8
[08/16] powerpc/pseries/ras: fwnmi sreset should not interlock
https://git.kernel.org/powerpc/c/d7b14c5c042865070a1411078ab49ea17bad0b41
[09/16] powerpc/pseries: Limit machine check stack to 4GB
https://git.kernel.org/powerpc/c/d2cbbd45d433b96e41711a293e59cff259143694
[10/16] powerpc/pseries: Machine check use rtas_call_unlocked() with args on stack
https://git.kernel.org/powerpc/c/2576f5f9169620bf329cf1e91086e6041b98e4b2
[11/16] powerpc/64s: machine check interrupt update NMI accounting
https://git.kernel.org/powerpc/c/116ac378bb3ff844df333e7609e7604651a0db9d
[12/16] powerpc: Implement ftrace_enabled() helpers
https://git.kernel.org/powerpc/c/f2d7f62e4abdb03de3f4267361d96c417312d05c
[13/16] powerpc/64s: machine check do not trace real-mode handler
https://git.kernel.org/powerpc/c/abd106fb437ad1cd8c8df8ccabd0fa941ef6342a
[14/16] powerpc/traps: Do not trace system reset
https://git.kernel.org/powerpc/c/bbbc8032b00f8ef287894425fbdb691049e28d39
[15/16] powerpc/traps: Make unrecoverable NMIs die instead of panic
https://git.kernel.org/powerpc/c/265d6e588d87194c2fe2d6c240247f0264e0c19b
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: Update Speculation_Store_Bypass in /proc/<pid>/status
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: gwalbon, ricklind
In-Reply-To: <20200402124929.3574166-1-mpe@ellerman.id.au>
On Thu, 2 Apr 2020 23:49:29 +1100, Michael Ellerman wrote:
> Currently we don't report anything useful in /proc/<pid>/status:
>
> $ grep Speculation_Store_Bypass /proc/self/status
> Speculation_Store_Bypass: unknown
>
> Our mitigation is currently always a barrier instruction, which
> doesn't map that well onto the existing possibilities for the PR_SPEC
> values.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64: Update Speculation_Store_Bypass in /proc/<pid>/status
https://git.kernel.org/powerpc/c/d93e5e2d03d4f41dfedb92200a2c0413ab8ee4e7
cheers
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc/64s: Always has full regs, so remove remnant checks
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200507121332.2233629-1-mpe@ellerman.id.au>
On Thu, 7 May 2020 22:13:29 +1000, Michael Ellerman wrote:
>
Applied to powerpc/next.
[1/4] powerpc/64s: Always has full regs, so remove remnant checks
https://git.kernel.org/powerpc/c/feb9df3462e688d073848d85c8bb132fe8fd9ae5
[2/4] powerpc: Use set_trap() and avoid open-coding trap masking
https://git.kernel.org/powerpc/c/db30144b5c9cfb09c6b8b2fa7a9c351c94aa3433
[3/4] powerpc: trap_is_syscall() helper to hide syscall trap number
https://git.kernel.org/powerpc/c/912237ea166428edcbf3c137adf12cb987c477f2
[4/4] powerpc: Use trap metadata to prevent double restart rather than zeroing trap
https://git.kernel.org/powerpc/c/4e0e45b07d790253643ee05300784ab2156e2d5e
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64: Don't initialise init_task->thread.regs
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aneesh.kumar
In-Reply-To: <20200428123130.73078-1-mpe@ellerman.id.au>
On Tue, 28 Apr 2020 22:31:30 +1000, Michael Ellerman wrote:
> Aneesh increased the size of struct pt_regs by 16 bytes and started
> seeing this WARN_ON:
>
> smp: Bringing up secondary CPUs ...
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at arch/powerpc/kernel/process.c:455 giveup_all+0xb4/0x110
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+ #318
> NIP: c00000000001a2b4 LR: c00000000001a29c CTR: c0000000031d0000
> REGS: c0000000026d3980 TRAP: 0700 Not tainted (5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+)
> MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48048224 XER: 00000000
> CFAR: c000000000019cc8 IRQMASK: 1
> GPR00: c00000000001a264 c0000000026d3c20 c0000000026d7200 800000000280b033
> GPR04: 0000000000000001 0000000000000000 0000000000000077 30206d7372203164
> GPR08: 0000000000002000 0000000002002000 800000000280b033 3230303030303030
> GPR12: 0000000000008800 c0000000031d0000 0000000000800050 0000000002000066
> GPR16: 000000000309a1a0 000000000309a4b0 000000000309a2d8 000000000309a890
> GPR20: 00000000030d0098 c00000000264da40 00000000fd620000 c0000000ff798080
> GPR24: c00000000264edf0 c0000001007469f0 00000000fd620000 c0000000020e5e90
> GPR28: c00000000264edf0 c00000000264d200 000000001db60000 c00000000264d200
> NIP [c00000000001a2b4] giveup_all+0xb4/0x110
> LR [c00000000001a29c] giveup_all+0x9c/0x110
> Call Trace:
> [c0000000026d3c20] [c00000000001a264] giveup_all+0x64/0x110 (unreliable)
> [c0000000026d3c90] [c00000000001ae34] __switch_to+0x104/0x480
> [c0000000026d3cf0] [c000000000e0b8a0] __schedule+0x320/0x970
> [c0000000026d3dd0] [c000000000e0c518] schedule_idle+0x38/0x70
> [c0000000026d3df0] [c00000000019c7c8] do_idle+0x248/0x3f0
> [c0000000026d3e70] [c00000000019cbb8] cpu_startup_entry+0x38/0x40
> [c0000000026d3ea0] [c000000000011bb0] rest_init+0xe0/0xf8
> [c0000000026d3ed0] [c000000002004820] start_kernel+0x990/0x9e0
> [c0000000026d3f90] [c00000000000c49c] start_here_common+0x1c/0x400
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64: Don't initialise init_task->thread.regs
https://git.kernel.org/powerpc/c/7ffa8b7dc11752827329e4e84a574ea6aaf24716
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Add a test of counting larx/stcx
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200426114410.3917383-1-mpe@ellerman.id.au>
On Sun, 26 Apr 2020 21:44:10 +1000, Michael Ellerman wrote:
> This is based on the count_instructions test.
>
> However this one also counts the number of failed stcx's, and in
> conjunction with knowing the size of the stcx loop, can calculate the
> total number of instructions executed even in the face of
> non-deterministic stcx failures.
Applied to powerpc/next.
[1/1] selftests/powerpc: Add a test of counting larx/stcx
https://git.kernel.org/powerpc/c/7481cad4747303442209bc5dba2f56c3afcea07d
cheers
^ permalink raw reply
* Re: [PATCH] drivers/macintosh: Fix memleak in windfarm_pm112 driver
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: erhard_f
In-Reply-To: <20200423060038.3308530-1-mpe@ellerman.id.au>
On Thu, 23 Apr 2020 16:00:38 +1000, Michael Ellerman wrote:
> create_cpu_loop() calls smu_sat_get_sdb_partition() which does
> kmalloc() and returns the allocated buffer. In fact it's called twice,
> and neither buffer is freed.
>
> This results in a memory leak as reported by Erhard:
> unreferenced object 0xc00000047081f840 (size 32):
> comm "kwindfarm", pid 203, jiffies 4294880630 (age 5552.877s)
> hex dump (first 32 bytes):
> c8 06 02 7f ff 02 ff 01 fb bf 00 41 00 20 00 00 ...........A. ..
> 00 07 89 37 00 a0 00 00 00 00 00 00 00 00 00 00 ...7............
> backtrace:
> [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
> [<000000003010fcb7>] .pm112_wf_notify+0x104c/0x13bc [windfarm_pm112]
> [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
> [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
> [<00000000131d8149>] .wf_thread_func+0x114/0x1a0
> [<000000000d54838d>] .kthread+0x13c/0x190
> [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
> unreferenced object 0xc0000004737089f0 (size 16):
> comm "kwindfarm", pid 203, jiffies 4294880879 (age 5552.050s)
> hex dump (first 16 bytes):
> c4 04 01 7f 22 11 e0 e6 ff 55 7b 12 ec 11 00 00 ...."....U{.....
> backtrace:
> [<0000000083f0a65c>] .smu_sat_get_sdb_partition+0xc4/0x2d0 [windfarm_smu_sat]
> [<00000000b94ef7e1>] .pm112_wf_notify+0x1294/0x13bc [windfarm_pm112]
> [<00000000b958b2dd>] .notifier_call_chain+0xa8/0x180
> [<0000000070490868>] .blocking_notifier_call_chain+0x64/0x90
> [<00000000131d8149>] .wf_thread_func+0x114/0x1a0
> [<000000000d54838d>] .kthread+0x13c/0x190
> [<00000000669b72bc>] .ret_from_kernel_thread+0x58/0x64
>
> [...]
Applied to powerpc/next.
[1/1] drivers/macintosh: Fix memleak in windfarm_pm112 driver
https://git.kernel.org/powerpc/c/93900337b9ac2f4eca427eff6d187be2dc3b5551
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Drop unneeded cast in task_pt_regs()
From: Michael Ellerman @ 2020-05-20 11:00 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200428123152.73566-1-mpe@ellerman.id.au>
On Tue, 28 Apr 2020 22:31:52 +1000, Michael Ellerman wrote:
> There's no need to cast in task_pt_regs() as tsk->thread.regs should
> already be a struct pt_regs. If someone's using task_pt_regs() on
> something that's not a task but happens to have a thread.regs then
> we'll deal with them later.
Applied to powerpc/next.
[1/1] powerpc: Drop unneeded cast in task_pt_regs()
https://git.kernel.org/powerpc/c/24ac99e97fa7b8f0db9b48413a76def9cf73295c
cheers
^ permalink raw reply
* Re: [PATCH v8 00/30] Initial Prefixed Instruction support
From: Michael Ellerman @ 2020-05-20 10:59 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe; +Cc: alistair, naveen.n.rao, dja, npiggin, bala24
In-Reply-To: <20200506034050.24806-1-jniethe5@gmail.com>
On Wed, 6 May 2020 13:40:20 +1000, Jordan Niethe wrote:
> A future revision of the ISA will introduce prefixed instructions. A
> prefixed instruction is composed of a 4-byte prefix followed by a
> 4-byte suffix.
>
> All prefixes have the major opcode 1. A prefix will never be a valid
> word instruction. A suffix may be an existing word instruction or a
> new instruction.
>
> [...]
Applied to powerpc/next.
[01/30] powerpc/xmon: Remove store_inst() for patch_instruction()
https://git.kernel.org/powerpc/c/802268fd82676ffce432776f60b93a0b15e58e0c
[02/30] powerpc/xmon: Move breakpoint instructions to own array
https://git.kernel.org/powerpc/c/51c9ba11f17f25ace1ea6bbfd4586c59105432de
[03/30] powerpc/xmon: Move breakpoints to text section
https://git.kernel.org/powerpc/c/4eff2b4f32a309e2171bfe53db3e93b5614f77cb
[04/30] powerpc/xmon: Use bitwise calculations in_breakpoint_table()
https://git.kernel.org/powerpc/c/5a7fdcab54ef17c395fc47e73c828a1432e51683
[05/30] powerpc: Change calling convention for create_branch() et. al.
https://git.kernel.org/powerpc/c/7c95d8893fb55869882c9f68f4c94840dc43f18f
[06/30] powerpc: Use a macro for creating instructions from u32s
https://git.kernel.org/powerpc/c/753462512868674a788ecc77bb96752efb818785
[07/30] powerpc: Use an accessor for instructions
https://git.kernel.org/powerpc/c/777e26f0edf8dab58b8dd474d35d83bde0ac6d76
[08/30] powerpc: Use a function for getting the instruction op code
https://git.kernel.org/powerpc/c/8094892d1aff14269d3b7bfcd8b941217eecd81f
[09/30] powerpc: Use a function for byte swapping instructions
https://git.kernel.org/powerpc/c/aabd2233b6aefeee6d7a2f667076d8346be1d30a
[10/30] powerpc: Introduce functions for instruction equality
https://git.kernel.org/powerpc/c/217862d9b98bf08958d57fd7b31b9de0f1a9477d
[11/30] powerpc: Use a datatype for instructions
https://git.kernel.org/powerpc/c/94afd069d937d84fb4f696eb9a78db4084e43d21
[12/30] powerpc: Use a function for reading instructions
https://git.kernel.org/powerpc/c/f8faaffaa7d99028e457ef2d1dcb43a98f736938
[13/30] powerpc: Add a probe_user_read_inst() function
https://git.kernel.org/powerpc/c/7ba68b2172c19031fdc2a2caf37328edd146e299
[14/30] powerpc: Add a probe_kernel_read_inst() function
https://git.kernel.org/powerpc/c/95b980a00d1220ca67550a933166704db8bc5c14
[15/30] powerpc/kprobes: Use patch_instruction()
https://git.kernel.org/powerpc/c/a8646f43ba5046e7f5c4396125d5136bfcb17b49
[16/30] powerpc: Define and use get_user_instr() et. al.
https://git.kernel.org/powerpc/c/5249385ad7f0ac178433f0ae9cc5b64612c8ff77
[17/30] powerpc: Introduce a function for reporting instruction length
https://git.kernel.org/powerpc/c/622cf6f436a12338bbcfbb3474629755547fd112
[18/30] powerpc/xmon: Use a function for reading instructions
https://git.kernel.org/powerpc/c/6c7a4f0a9f66fc7fdc6e208559e5d562f53e0991
[19/30] powerpc/xmon: Move insertion of breakpoint for xol'ing
https://git.kernel.org/powerpc/c/7fccfcfba04f9cb46438f368755d368f6c57f3a0
[20/30] powerpc: Make test_translate_branch() independent of instruction length
https://git.kernel.org/powerpc/c/0b582db5490a1f250ef63337dd46d5c7599dae80
[21/30] powerpc: Enable Prefixed Instructions
https://git.kernel.org/powerpc/c/2aa6195e43b3740258ead93aee42ac719dd4c4b0
[22/30] powerpc: Define new SRR1 bits for a ISA v3.1
https://git.kernel.org/powerpc/c/b691505ef9232a6e82f1c160911afcb4cb20487b
[23/30] powerpc: Add prefixed instructions to instruction data type
https://git.kernel.org/powerpc/c/650b55b707fdfa764e9f2b81314d3eb4216fb962
[24/30] powerpc: Test prefixed code patching
https://git.kernel.org/powerpc/c/f77f8ff7f13e6411c2e0ba25bb7e012a5ae6c927
[25/30] powerpc: Test prefixed instructions in feature fixups
https://git.kernel.org/powerpc/c/785b79d1e02873c2088ee1301154c66dace66ce5
[26/30] powerpc/xmon: Don't allow breakpoints on suffixes
https://git.kernel.org/powerpc/c/c9c831aebd8663d0129bbcee4d76be889f0627fe
[27/30] powerpc/kprobes: Don't allow breakpoints on suffixes
https://git.kernel.org/powerpc/c/b4657f7650babc9bfb41ce875abe41b18604a105
[28/30] powerpc: Support prefixed instructions in alignment handler
https://git.kernel.org/powerpc/c/9409d2f9dad2f0679d67dc24d8116dd3e837b035
[29/30] powerpc sstep: Add support for prefixed load/stores
https://git.kernel.org/powerpc/c/50b80a12e4ccff46d53b93754d817acd98bc9ae0
[30/30] powerpc sstep: Add support for prefixed fixed-point arithmetic
https://git.kernel.org/powerpc/c/3920742b92f5ea19a220edb947b6f33c99f501da
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox