* [PATCH 1/2] ima: Free IMA measurement buffer on error
From: Lakshmi Ramasubramanian @ 2021-01-21 17:30 UTC (permalink / raw)
To: zohar, bauerman, dmitry.kasatkin, ebiederm, gregkh, sashal,
tyhicks
Cc: linux-integrity, linuxppc-dev, linux-kernel
IMA allocates kernel virtual memory to carry forward the measurement
list, from the current kernel to the next kernel on kexec system call,
in ima_add_kexec_buffer() function. In error code paths this memory
is not freed resulting in memory leak.
Free the memory allocated for the IMA measurement list in
the error code paths in ima_add_kexec_buffer() function.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
---
security/integrity/ima/ima_kexec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index 121de3e04af2..212145008a01 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -119,12 +119,14 @@ void ima_add_kexec_buffer(struct kimage *image)
ret = kexec_add_buffer(&kbuf);
if (ret) {
pr_err("Error passing over kexec measurement buffer.\n");
+ vfree(kexec_buffer);
return;
}
ret = arch_ima_add_kexec_buffer(image, kbuf.mem, kexec_segment_size);
if (ret) {
pr_err("Error passing over kexec measurement buffer.\n");
+ vfree(kexec_buffer);
return;
}
--
2.30.0
^ permalink raw reply related
* RE: [PATCH 02/13] module: add a module_loaded helper
From: David Laight @ 2021-01-21 17:44 UTC (permalink / raw)
To: 'Christoph Hellwig', Christophe Leroy
Cc: Petr Mladek, Michal Marek, Andrew Donnellan, Jessica Yu,
linux-kbuild@vger.kernel.org, David Airlie, Masahiro Yamada,
Jiri Kosina, Maarten Lankhorst, linux-kernel@vger.kernel.org,
Maxime Ripard, Joe Lawrence, dri-devel@lists.freedesktop.org,
Thomas Zimmermann, Josh Poimboeuf, Frederic Barrat,
live-patching@vger.kernel.org, Daniel Vetter, Miroslav Benes,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20210121171119.GA29916@lst.de>
>
> On Thu, Jan 21, 2021 at 11:00:20AM +0100, Christophe Leroy wrote:
> > > +bool module_loaded(const char *name);
> >
> > Maybe module_is_loaded() would be a better name.
>
> Fine with me.
It does look like both callers aren't 'unsafe'.
But it is a bit strange returning a stale value.
It did make be look a bit more deeply at try_module_get().
For THIS_MODULE (eg to get an extra reference for a kthread)
I doubt it can ever fail.
But the other cases require a 'module' structure be passed in.
ISTM that unloading the module could invalidate the pointer
that has just been read from some other structure.
I'm guessing that some other lock must always be held.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH net] ibmvnic: device remove has higher precedence over reset
From: Dany Madden @ 2021-01-21 18:24 UTC (permalink / raw)
To: Lijun Pan
Cc: gregkh, julietk, netdev, Uwe Kleine-König, paulus, kernel,
kuba, sukadev, linuxppc-dev, davem
In-Reply-To: <20210121062005.53271-1-ljp@linux.ibm.com>
On 2021-01-20 22:20, Lijun Pan wrote:
> Returning -EBUSY in ibmvnic_remove() does not actually hold the
> removal procedure since driver core doesn't care for the return
> value (see __device_release_driver() in drivers/base/dd.c
> calling dev->bus->remove()) though vio_bus_remove
> (in arch/powerpc/platforms/pseries/vio.c) records the
> return value and passes it on. [1]
>
> During the device removal precedure, we should not schedule
> any new reset (ibmvnic_reset check for REMOVING and exit),
> and should rely on the flush_work and flush_delayed_work
> to complete the pending resets, specifically we need to
> let __ibmvnic_reset() keep running while in REMOVING state since
> flush_work and flush_delayed_work shall call __ibmvnic_reset finally.
> So we skip the checking for REMOVING in __ibmvnic_reset.
>
> [1]
> https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53
> Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during
> device reset")
> Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
> ---
> v1 versus RFC:
> 1/ articulate why remove the REMOVING checking in __ibmvnic_reset
> and why keep the current checking for REMOVING in ibmvnic_reset.
> 2/ The locking issue mentioned by Uwe are being addressed separately
> by https://lists.openwall.net/netdev/2021/01/08/89
> 3/ This patch does not have merge conflict with 2/
>
> drivers/net/ethernet/ibm/ibmvnic.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> b/drivers/net/ethernet/ibm/ibmvnic.c
> index aed985e08e8a..11f28fd03057 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct
> *work)
> while (rwi) {
> spin_lock_irqsave(&adapter->state_lock, flags);
>
> - if (adapter->state == VNIC_REMOVING ||
> - adapter->state == VNIC_REMOVED) {
> + if (adapter->state == VNIC_REMOVED) {
If we do get here, we would crash because ibmvnic_remove() happened. It
frees the adapter struct already.
> spin_unlock_irqrestore(&adapter->state_lock, flags);
> kfree(rwi);
> rc = EBUSY;
> @@ -5372,11 +5371,6 @@ static int ibmvnic_remove(struct vio_dev *dev)
> unsigned long flags;
>
> spin_lock_irqsave(&adapter->state_lock, flags);
> - if (test_bit(0, &adapter->resetting)) {
> - spin_unlock_irqrestore(&adapter->state_lock, flags);
> - return -EBUSY;
> - }
> -
> adapter->state = VNIC_REMOVING;
> spin_unlock_irqrestore(&adapter->state_lock, flags);
^ permalink raw reply
* Re: [PATCH net] ibmvnic: device remove has higher precedence over reset
From: Lijun Pan @ 2021-01-21 18:46 UTC (permalink / raw)
To: Dany Madden
Cc: gregkh, julietk, netdev, Uwe Kleine-König, Jakub Kicinski,
Lijun Pan, kernel, paulus, sukadev, linuxppc-dev, davem
In-Reply-To: <c34816a13d857b7f5d1a25991b58ec63@imap.linux.ibm.com>
On Thu, Jan 21, 2021 at 12:42 PM Dany Madden <drt@linux.ibm.com> wrote:
>
> On 2021-01-20 22:20, Lijun Pan wrote:
> > Returning -EBUSY in ibmvnic_remove() does not actually hold the
> > removal procedure since driver core doesn't care for the return
> > value (see __device_release_driver() in drivers/base/dd.c
> > calling dev->bus->remove()) though vio_bus_remove
> > (in arch/powerpc/platforms/pseries/vio.c) records the
> > return value and passes it on. [1]
> >
> > During the device removal precedure, we should not schedule
> > any new reset (ibmvnic_reset check for REMOVING and exit),
> > and should rely on the flush_work and flush_delayed_work
> > to complete the pending resets, specifically we need to
> > let __ibmvnic_reset() keep running while in REMOVING state since
> > flush_work and flush_delayed_work shall call __ibmvnic_reset finally.
> > So we skip the checking for REMOVING in __ibmvnic_reset.
> >
> > [1]
> > https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53
> > Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during
> > device reset")
> > Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
> > ---
> > v1 versus RFC:
> > 1/ articulate why remove the REMOVING checking in __ibmvnic_reset
> > and why keep the current checking for REMOVING in ibmvnic_reset.
> > 2/ The locking issue mentioned by Uwe are being addressed separately
> > by https://lists.openwall.net/netdev/2021/01/08/89
> > 3/ This patch does not have merge conflict with 2/
> >
> > drivers/net/ethernet/ibm/ibmvnic.c | 8 +-------
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> > b/drivers/net/ethernet/ibm/ibmvnic.c
> > index aed985e08e8a..11f28fd03057 100644
> > --- a/drivers/net/ethernet/ibm/ibmvnic.c
> > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> > @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct
> > *work)
> > while (rwi) {
> > spin_lock_irqsave(&adapter->state_lock, flags);
> >
> > - if (adapter->state == VNIC_REMOVING ||
> > - adapter->state == VNIC_REMOVED) {
> > + if (adapter->state == VNIC_REMOVED) {
>
> If we do get here, we would crash because ibmvnic_remove() happened. It
> frees the adapter struct already.
Not exactly. viodev is gone; netdev is done; ibmvnic_adapter is still there.
Lijun
>
> > spin_unlock_irqrestore(&adapter->state_lock, flags);
> > kfree(rwi);
> > rc = EBUSY;
> > @@ -5372,11 +5371,6 @@ static int ibmvnic_remove(struct vio_dev *dev)
> > unsigned long flags;
> >
> > spin_lock_irqsave(&adapter->state_lock, flags);
> > - if (test_bit(0, &adapter->resetting)) {
> > - spin_unlock_irqrestore(&adapter->state_lock, flags);
> > - return -EBUSY;
> > - }
> > -
> > adapter->state = VNIC_REMOVING;
> > spin_unlock_irqrestore(&adapter->state_lock, flags);
^ permalink raw reply
* Re: [PATCH net] ibmvnic: device remove has higher precedence over reset
From: Lijun Pan @ 2021-01-21 19:48 UTC (permalink / raw)
To: Dany Madden
Cc: gregkh, julietk, netdev, Uwe Kleine-König, Jakub Kicinski,
Lijun Pan, kernel, paulus, sukadev, linuxppc-dev, davem
In-Reply-To: <c34816a13d857b7f5d1a25991b58ec63@imap.linux.ibm.com>
> > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> > b/drivers/net/ethernet/ibm/ibmvnic.c
> > index aed985e08e8a..11f28fd03057 100644
> > --- a/drivers/net/ethernet/ibm/ibmvnic.c
> > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> > @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct
> > *work)
> > while (rwi) {
> > spin_lock_irqsave(&adapter->state_lock, flags);
> >
> > - if (adapter->state == VNIC_REMOVING ||
> > - adapter->state == VNIC_REMOVED) {
> > + if (adapter->state == VNIC_REMOVED) {
>
> If we do get here, we would crash because ibmvnic_remove() happened. It
> frees the adapter struct already.
Not exactly. viodev is gone; netdev is gone; ibmvnic_adapter is still there.
Lijun
^ permalink raw reply
* Re: [PATCH 04/13] livepatch: move klp_find_object_module to module.c
From: Josh Poimboeuf @ 2021-01-21 21:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Joe Lawrence, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Jiri Kosina, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
dri-devel, Thomas Zimmermann, Jessica Yu, Frederic Barrat,
Daniel Vetter, Miroslav Benes, linuxppc-dev
In-Reply-To: <20210121074959.313333-5-hch@lst.de>
On Thu, Jan 21, 2021 at 08:49:50AM +0100, Christoph Hellwig wrote:
> @@ -820,14 +796,25 @@ static int klp_init_object(struct klp_patch *patch, struct klp_object *obj)
> const char *name;
>
> obj->patched = false;
> - obj->mod = NULL;
Why was this line removed?
> if (klp_is_module(obj)) {
> if (strlen(obj->name) >= MODULE_NAME_LEN)
> return -EINVAL;
> name = obj->name;
>
> - klp_find_object_module(obj);
> + /*
> + * We do not want to block removal of patched modules and
> + * therefore we do not take a reference here. The patches are
> + * removed by klp_module_going() instead.
> + *
> + * Do not mess work of klp_module_coming() and
> + * klp_module_going(). Note that the patch might still be
> + * needed before klp_module_going() is called. Module functions
> + * can be called even in the GOING state until mod->exit()
> + * finishes. This is especially important for patches that
> + * modify semantic of the functions.
> + */
> + obj->mod = find_klp_module(obj->name);
These comments don't make sense in this context, they should be kept
with the code in find_klp_module().
--
Josh
^ permalink raw reply
* Re: [PATCH 1/2] ima: Free IMA measurement buffer on error
From: Tyler Hicks @ 2021-01-21 17:35 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: sashal, dmitry.kasatkin, linux-kernel, zohar, ebiederm, gregkh,
linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210121173003.18324-1-nramas@linux.microsoft.com>
On 2021-01-21 09:30:02, Lakshmi Ramasubramanian wrote:
> IMA allocates kernel virtual memory to carry forward the measurement
> list, from the current kernel to the next kernel on kexec system call,
> in ima_add_kexec_buffer() function. In error code paths this memory
> is not freed resulting in memory leak.
>
> Free the memory allocated for the IMA measurement list in
> the error code paths in ima_add_kexec_buffer() function.
>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Tyler
> ---
> security/integrity/ima/ima_kexec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> index 121de3e04af2..212145008a01 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -119,12 +119,14 @@ void ima_add_kexec_buffer(struct kimage *image)
> ret = kexec_add_buffer(&kbuf);
> if (ret) {
> pr_err("Error passing over kexec measurement buffer.\n");
> + vfree(kexec_buffer);
> return;
> }
>
> ret = arch_ima_add_kexec_buffer(image, kbuf.mem, kexec_segment_size);
> if (ret) {
> pr_err("Error passing over kexec measurement buffer.\n");
> + vfree(kexec_buffer);
> return;
> }
>
> --
> 2.30.0
>
^ permalink raw reply
* Re: [PATCH 2/2] ima: Free IMA measurement buffer after kexec syscall
From: Tyler Hicks @ 2021-01-21 17:37 UTC (permalink / raw)
To: Lakshmi Ramasubramanian
Cc: sashal, dmitry.kasatkin, linux-kernel, zohar, ebiederm, gregkh,
linux-integrity, linuxppc-dev, bauerman
In-Reply-To: <20210121173003.18324-2-nramas@linux.microsoft.com>
On 2021-01-21 09:30:03, Lakshmi Ramasubramanian wrote:
> IMA allocates kernel virtual memory to carry forward the measurement
> list, from the current kernel to the next kernel on kexec system call,
> in ima_add_kexec_buffer() function. This buffer is not freed before
> completing the kexec system call resulting in memory leak.
>
> Add ima_buffer field in "struct kimage" to store the virtual address
> of the buffer allocated for the IMA measurement list.
> Free the memory allocated for the IMA measurement list in
> kimage_file_post_load_cleanup() function.
>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> Suggested-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Reviewed-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Tyler
> ---
> include/linux/kexec.h | 5 +++++
> kernel/kexec_file.c | 5 +++++
> security/integrity/ima/ima_kexec.c | 2 ++
> 3 files changed, 12 insertions(+)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 9e93bef52968..5f61389f5f36 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -300,6 +300,11 @@ struct kimage {
> /* Information for loading purgatory */
> struct purgatory_info purgatory_info;
> #endif
> +
> +#ifdef CONFIG_IMA_KEXEC
> + /* Virtual address of IMA measurement buffer for kexec syscall */
> + void *ima_buffer;
> +#endif
> };
>
> /* kexec interface functions */
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index b02086d70492..5c3447cf7ad5 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -166,6 +166,11 @@ void kimage_file_post_load_cleanup(struct kimage *image)
> vfree(pi->sechdrs);
> pi->sechdrs = NULL;
>
> +#ifdef CONFIG_IMA_KEXEC
> + vfree(image->ima_buffer);
> + image->ima_buffer = NULL;
> +#endif /* CONFIG_IMA_KEXEC */
> +
> /* See if architecture has anything to cleanup post load */
> arch_kimage_file_post_load_cleanup(image);
>
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> index 212145008a01..8eadd0674629 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -130,6 +130,8 @@ void ima_add_kexec_buffer(struct kimage *image)
> return;
> }
>
> + image->ima_buffer = kexec_buffer;
> +
> pr_debug("kexec measurement buffer for the loaded kernel at 0x%lx.\n",
> kbuf.mem);
> }
> --
> 2.30.0
>
^ permalink raw reply
* Re: [PATCH net] ibmvnic: device remove has higher precedence over reset
From: Sukadev Bhattiprolu @ 2021-01-21 22:38 UTC (permalink / raw)
To: Lijun Pan
Cc: gregkh, julietk, netdev, Uwe Kleine-König, Jakub Kicinski,
Lijun Pan, kernel, Dany Madden, paulus, linuxppc-dev, davem
In-Reply-To: <CAOhMmr78mzJpfPBSwp9JWmE+KwLxd6JtqpwaA9tmqxU5fCjcgg@mail.gmail.com>
Lijun Pan [lijunp213@gmail.com] wrote:
> > > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> > > b/drivers/net/ethernet/ibm/ibmvnic.c
> > > index aed985e08e8a..11f28fd03057 100644
> > > --- a/drivers/net/ethernet/ibm/ibmvnic.c
> > > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> > > @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct
> > > *work)
> > > while (rwi) {
> > > spin_lock_irqsave(&adapter->state_lock, flags);
> > >
> > > - if (adapter->state == VNIC_REMOVING ||
> > > - adapter->state == VNIC_REMOVED) {
> > > + if (adapter->state == VNIC_REMOVED) {
If the adapter is in REMOVING state, there is no point going
through the reset process. We could just bail out here. We
should also drain any other resets in the queue (something
my other patch set was addressing).
Sukadev
> >
> > If we do get here, we would crash because ibmvnic_remove() happened. It
> > frees the adapter struct already.
>
> Not exactly. viodev is gone; netdev is gone; ibmvnic_adapter is still there.
>
> Lijun
^ permalink raw reply
* Re: [PATCH] powerpc/64: prevent replayed interrupt handlers from running softirqs
From: Nicholas Piggin @ 2021-01-22 0:33 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman
In-Reply-To: <878s8mqwsl.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of January 21, 2021 10:50 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> Running softirqs enables interrupts, which can then end up recursing
>> into the irq soft-mask code we're adjusting, including replaying
>> interrupts itself, which might be theoretically unbounded.
>>
>> This abridged trace shows how this can occur:
>>
>> ! NIP replay_soft_interrupts
>> LR interrupt_exit_kernel_prepare
>> Call Trace:
>> interrupt_exit_kernel_prepare (unreliable)
>> interrupt_return
>> --- interrupt: ea0 at __rb_reserve_next
>> NIP __rb_reserve_next
>> LR __rb_reserve_next
>> Call Trace:
>> ring_buffer_lock_reserve
>> trace_function
>> function_trace_call
>> ftrace_call
>> __do_softirq
>> irq_exit
>> timer_interrupt
>> ! replay_soft_interrupts
>> interrupt_exit_kernel_prepare
>> interrupt_return
>> --- interrupt: ea0 at arch_local_irq_restore
>>
>> Fix this by disabling bhs (softirqs) around the interrupt replay.
>>
>> I don't know that commit 3282a3da25bd ("powerpc/64: Implement soft
>> interrupt replay in C") actually introduced the problem. Prior to that
>> change, the interrupt replay seems like it should still be subect to
>> this recusion, however it's done after all the irq state has been fixed
>> up at the end of the replay, so it seems reasonable to fix back to this
>> commit.
>
> This seems very unhappy for me (on P9 bare metal):
Oh, damn lockdep I always forget it has a bunch of interrupt checks.
In this case it might have a point though. Thanks, I'll try to fix it.
Thanks,
Nick
>
> [ 0.038571] Mountpoint-cache hash table entries: 131072 (order: 4, 1048576 bytes, linear)
> [ 0.040194] ------------[ cut here ]------------
> [ 0.040228] WARNING: CPU: 0 PID: 0 at kernel/softirq.c:176 __local_bh_enable_ip+0x150/0x210
> [ 0.040263] Modules linked in:
> [ 0.040280] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-rc2-00008-g4899f32e4f2a #1
> [ 0.040321] NIP: c000000000114bc0 LR: c0000000000172a0 CTR: c00000000002a020
> [ 0.040360] REGS: c00000000177f670 TRAP: 0700 Not tainted (5.11.0-rc2-00008-g4899f32e4f2a)
> [ 0.040410] MSR: 9000000002021033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 28000224 XER: 20040000
> [ 0.040472] CFAR: c000000000114ae8 IRQMASK: 3
> GPR00: c0000000000172a0 c00000000177f910 c000000001783900 c000000000017290
> GPR04: 0000000000000200 4000000000000000 0000000000000002 00000001312d0000
> GPR08: 0000000000000000 c0000000016f3480 0000000000000202 0000000000000000
> GPR12: c00000000002a020 c0000000023a0000 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000001 00000000100051c6 0000000000000000 0000000000000009
> GPR24: 0000000000000e60 0000000000000900 0000000000000500 0000000000000a00
> GPR28: 0000000000000f00 0000000000000002 0000000000000003 0000000000000200
> [ 0.040824] NIP [c000000000114bc0] __local_bh_enable_ip+0x150/0x210
> [ 0.040863] LR [c0000000000172a0] replay_soft_interrupts+0x2e0/0x340
> [ 0.040904] Call Trace:
> [ 0.040926] [c00000000177f910] [0000000000000500] 0x500 (unreliable)
> [ 0.040962] [c00000000177f950] [c0000000000172a0] replay_soft_interrupts+0x2e0/0x340
> [ 0.041008] [c00000000177fb50] [c000000000017370] arch_local_irq_restore+0x70/0xe0
> [ 0.041042] [c00000000177fb80] [c000000000476514] kmem_cache_alloc+0x474/0x520
> [ 0.041066] [c00000000177fc00] [c0000000004e394c] __d_alloc+0x4c/0x2e0
> [ 0.041109] [c00000000177fc50] [c0000000004e40ac] d_make_root+0x3c/0xa0
> [ 0.041142] [c00000000177fc80] [c000000000679ce0] ramfs_fill_super+0x80/0xb0
> [ 0.041186] [c00000000177fcb0] [c0000000004c1b04] get_tree_nodev+0xb4/0x130
> [ 0.041230] [c00000000177fcf0] [c000000000679578] ramfs_get_tree+0x28/0x40
> [ 0.041282] [c00000000177fd10] [c0000000004bee78] vfs_get_tree+0x48/0x120
> [ 0.041325] [c00000000177fd80] [c0000000004f7fe0] vfs_kern_mount.part.0+0xd0/0x130
> [ 0.041368] [c00000000177fdc0] [c000000001366700] mnt_init+0x1c8/0x2fc
> [ 0.041420] [c00000000177fe60] [c000000001366178] vfs_caches_init+0x110/0x138
> [ 0.041454] [c00000000177fee0] [c000000001331020] start_kernel+0x6d8/0x780
> [ 0.041497] [c00000000177ff90] [c00000000000d354] start_here_common+0x1c/0x5c8
> [ 0.041539] Instruction dump:
> [ 0.041555] e9490002 394a0001 91490000 e90d0028 3d42ffcc 394a4730 7d0a42aa e9490002
> [ 0.041608] 2c280000 394affff 91490000 4082ff30 <0fe00000> 892d0988 39400001 994d0988
> [ 0.041660] irq event stamp: 555
> [ 0.041674] hardirqs last enabled at (553): [<c00000000047654c>] kmem_cache_alloc+0x4ac/0x520
> [ 0.041707] hardirqs last disabled at (554): [<c000000000017368>] arch_local_irq_restore+0x68/0xe0
> [ 0.041750] softirqs last enabled at (0): [<0000000000000000>] 0x0
> [ 0.041778] softirqs last disabled at (555): [<c000000000016fd0>] replay_soft_interrupts+0x10/0x340
> [ 0.041824] ---[ end trace aa6f9769e07e43db ]---
>
>
> And lots and lots of these, or similar:
>
>
> [ 14.369838] =============================
> [ 14.369839] WARNING: suspicious RCU usage
> [ 14.369841] 5.11.0-rc2-00008-g4899f32e4f2a #1 Tainted: G W
> [ 14.369843] -----------------------------
> [ 14.369844] include/linux/rcupdate.h:692 rcu_read_unlock() used illegally while idle!
> [ 14.369846]
> other info that might help us debug this:
>
> [ 14.369848]
> rcu_scheduler_active = 2, debug_locks = 1
> [ 14.369850] RCU used illegally from extended quiescent state!
> [ 14.369851] 2 locks held by swapper/32/0:
> [ 14.369853] #0: c0000000015e6fc0 (rcu_callback){....}-{0:0}, at: rcu_core+0x2e0/0x990
> [ 14.369864] #1: c0000000015e6f30 (rcu_read_lock){....}-{1:3}, at: kmem_cache_free+0x7cc/0x7e0
> [ 14.369874]
> stack backtrace:
> [ 14.369876] CPU: 32 PID: 0 Comm: swapper/32 Tainted: G W 5.11.0-rc2-00008-g4899f32e4f2a #1
> [ 14.369879] Call Trace:
> [ 14.369880] [c000001fff557c10] [c0000000008630b8] dump_stack+0xec/0x144 (unreliable)
> [ 14.369886] [c000001fff557c60] [c0000000001ad2d0] lockdep_rcu_suspicious+0x124/0x144
> [ 14.369890] [c000001fff557cf0] [c00000000047783c] kmem_cache_free+0x2ac/0x7e0
> [ 14.369894] [c000001fff557db0] [c0000000004bdeac] file_free_rcu+0x5c/0xa0
> [ 14.369898] [c000001fff557de0] [c0000000001e214c] rcu_core+0x33c/0x990
> [ 14.369902] [c000001fff557e90] [c000000000f496d0] __do_softirq+0x180/0x688
> [ 14.369906] [c000001fff557f90] [c0000000000307bc] call_do_softirq+0x14/0x24
> [ 14.369911] [c000000002e1fab0] [c000000000017418] do_softirq_own_stack+0x38/0x50
> [ 14.369916] [c000000002e1fad0] [c000000000114a60] do_softirq+0x120/0x130
> [ 14.369920] [c000000002e1fb00] [c000000000114c64] __local_bh_enable_ip+0x1f4/0x210
> [ 14.369924] [c000000002e1fb40] [c0000000000172a0] replay_soft_interrupts+0x2e0/0x340
> [ 14.369928] [c000000002e1fd40] [c000000000017370] arch_local_irq_restore+0x70/0xe0
> [ 14.369933] [c000000002e1fd70] [c000000000c87184] snooze_loop+0x64/0x2e4
> [ 14.369937] [c000000002e1fdb0] [c000000000c84204] cpuidle_enter_state+0x2e4/0x550
> [ 14.369941] [c000000002e1fe10] [c000000000c8450c] cpuidle_enter+0x4c/0x70
> [ 14.369946] [c000000002e1fe50] [c00000000016892c] call_cpuidle+0x4c/0x90
> [ 14.369949] [c000000002e1fe70] [c000000000168d74] do_idle+0x2f4/0x380
> [ 14.369953] [c000000002e1ff10] [c000000000169208] cpu_startup_entry+0x38/0x40
> [ 14.369957] [c000000002e1ff40] [c000000000053484] start_secondary+0x2a4/0x2b0
> [ 14.369961] [c000000002e1ff90] [c00000000000d254] start_secondary_prolog+0x10/0x14
>
>
> cheers
>
^ permalink raw reply
* [PATCH] powerpc/8xx: export 'cpm_setbrg' for modules
From: Randy Dunlap @ 2021-01-22 1:08 UTC (permalink / raw)
To: linux-kernel
Cc: Christophe Leroy, kernel test robot, Randy Dunlap,
Nick Desaulniers, clang-built-linux, Paul Mackerras,
Andrew Morton, linuxppc-dev
Fix missing export for a loadable module build:
ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!
Fixes: 4128a89ac80d ("powerpc/8xx: move CPM1 related files from sysdev/ to platforms/8xx")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: clang-built-linux@googlegroups.com
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/8xx/cpm1.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20210121.orig/arch/powerpc/platforms/8xx/cpm1.c
+++ linux-next-20210121/arch/powerpc/platforms/8xx/cpm1.c
@@ -280,6 +280,7 @@ cpm_setbrg(uint brg, uint rate)
out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
CPM_BRG_EN | CPM_BRG_DIV16);
}
+EXPORT_SYMBOL(cpm_setbrg);
struct cpm_ioport16 {
__be16 dir, par, odr_sor, dat, intr;
^ permalink raw reply
* Re: [PATCH] powerpc: fix AKEBONO build failures
From: Michael Ellerman @ 2021-01-22 1:14 UTC (permalink / raw)
To: Randy Dunlap, Yury Norov, linuxppc-dev, Linux Kernel Mailing List
Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <6c442012-3bef-321b-bbc3-09c54608661f@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> On 1/20/21 1:29 PM, Yury Norov wrote:
>> Hi all,
>>
>> I found the power pc build broken on today's
>> linux-next (647060f3b592).
>
> Darn, I was building linux-5.11-rc4.
>
> I'll try linux-next after I send this.
>
> ---
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fulfill AKEBONO Kconfig requirements.
>
> Fixes these Kconfig warnings (and more) and fixes the subsequent
> build errors:
>
> WARNING: unmet direct dependencies detected for NETDEVICES
> Depends on [n]: NET [=n]
> Selected by [y]:
> - AKEBONO [=y] && PPC_47x [=y]
>
> WARNING: unmet direct dependencies detected for MMC_SDHCI
> Depends on [n]: MMC [=n] && HAS_DMA [=y]
> Selected by [y]:
> - AKEBONO [=y] && PPC_47x [=y]
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Yury Norov <yury.norov@gmail.com>
> ---
> arch/powerpc/platforms/44x/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- lnx-511-rc4.orig/arch/powerpc/platforms/44x/Kconfig
> +++ lnx-511-rc4/arch/powerpc/platforms/44x/Kconfig
> @@ -206,6 +206,7 @@ config AKEBONO
> select PPC4xx_HSTA_MSI
> select I2C
> select I2C_IBM_IIC
> + select NET
> select NETDEVICES
> select ETHERNET
> select NET_VENDOR_IBM
I think the problem here is too much use of select, for things that
should instead be in the defconfig.
The patch below results in the same result for make
44x/akebono_defconfig. Does it fix the original issue?
We don't need to add ETHERNET or NET_VENDOR_IBM to the defconfig because
they're both default y.
cheers
diff --git a/arch/powerpc/configs/44x/akebono_defconfig b/arch/powerpc/configs/44x/akebono_defconfig
index 3894ba8f8ffc..6b08a85f4ce6 100644
--- a/arch/powerpc/configs/44x/akebono_defconfig
+++ b/arch/powerpc/configs/44x/akebono_defconfig
@@ -21,6 +21,7 @@ CONFIG_IRQ_ALL_CPUS=y
# CONFIG_COMPACTION is not set
# CONFIG_SUSPEND is not set
CONFIG_NET=y
+CONFIG_NETDEVICES=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
@@ -98,6 +99,8 @@ CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_PCI is not set
CONFIG_USB_STORAGE=y
CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_M41T80=y
CONFIG_EXT2_FS=y
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 78ac6d67a935..509b329c112f 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -206,15 +206,10 @@ config AKEBONO
select PPC4xx_HSTA_MSI
select I2C
select I2C_IBM_IIC
- select NETDEVICES
- select ETHERNET
- select NET_VENDOR_IBM
select IBM_EMAC_EMAC4 if IBM_EMAC
select USB if USB_SUPPORT
select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
- select MMC_SDHCI
- select MMC_SDHCI_PLTFM
select ATA
select SATA_AHCI_PLATFORM
help
^ permalink raw reply related
* Re: [PATCH] powerpc: fix AKEBONO build failures
From: Randy Dunlap @ 2021-01-22 1:22 UTC (permalink / raw)
To: Michael Ellerman, Yury Norov, linuxppc-dev,
Linux Kernel Mailing List
Cc: Paul Mackerras
In-Reply-To: <875z3prcwg.fsf@mpe.ellerman.id.au>
On January 21, 2021 5:14:23 PM PST, Michael Ellerman <mpe@ellerman.id.au> wrote:
>Randy Dunlap <rdunlap@infradead.org> writes:
>> On 1/20/21 1:29 PM, Yury Norov wrote:
>>> Hi all,
>>>
>>> I found the power pc build broken on today's
>>> linux-next (647060f3b592).
>>
>> Darn, I was building linux-5.11-rc4.
>>
>> I'll try linux-next after I send this.
>>
>> ---
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Fulfill AKEBONO Kconfig requirements.
>>
>> Fixes these Kconfig warnings (and more) and fixes the subsequent
>> build errors:
>>
>> WARNING: unmet direct dependencies detected for NETDEVICES
>> Depends on [n]: NET [=n]
>> Selected by [y]:
>> - AKEBONO [=y] && PPC_47x [=y]
>>
>> WARNING: unmet direct dependencies detected for MMC_SDHCI
>> Depends on [n]: MMC [=n] && HAS_DMA [=y]
>> Selected by [y]:
>> - AKEBONO [=y] && PPC_47x [=y]
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: Yury Norov <yury.norov@gmail.com>
>> ---
>> arch/powerpc/platforms/44x/Kconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> --- lnx-511-rc4.orig/arch/powerpc/platforms/44x/Kconfig
>> +++ lnx-511-rc4/arch/powerpc/platforms/44x/Kconfig
>> @@ -206,6 +206,7 @@ config AKEBONO
>> select PPC4xx_HSTA_MSI
>> select I2C
>> select I2C_IBM_IIC
>> + select NET
>> select NETDEVICES
>> select ETHERNET
>> select NET_VENDOR_IBM
>
>I think the problem here is too much use of select, for things that
>should instead be in the defconfig.
>
>The patch below results in the same result for make
>44x/akebono_defconfig. Does it fix the original issue?
>
>We don't need to add ETHERNET or NET_VENDOR_IBM to the defconfig
>because
>they're both default y.
>
>cheers
>
>
>diff --git a/arch/powerpc/configs/44x/akebono_defconfig
>b/arch/powerpc/configs/44x/akebono_defconfig
>index 3894ba8f8ffc..6b08a85f4ce6 100644
>--- a/arch/powerpc/configs/44x/akebono_defconfig
>+++ b/arch/powerpc/configs/44x/akebono_defconfig
>@@ -21,6 +21,7 @@ CONFIG_IRQ_ALL_CPUS=y
> # CONFIG_COMPACTION is not set
> # CONFIG_SUSPEND is not set
> CONFIG_NET=y
>+CONFIG_NETDEVICES=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> CONFIG_INET=y
>@@ -98,6 +99,8 @@ CONFIG_USB_OHCI_HCD=y
> # CONFIG_USB_OHCI_HCD_PCI is not set
> CONFIG_USB_STORAGE=y
> CONFIG_MMC=y
>+CONFIG_MMC_SDHCI=y
>+CONFIG_MMC_SDHCI_PLTFM=y
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_DRV_M41T80=y
> CONFIG_EXT2_FS=y
>diff --git a/arch/powerpc/platforms/44x/Kconfig
>b/arch/powerpc/platforms/44x/Kconfig
>index 78ac6d67a935..509b329c112f 100644
>--- a/arch/powerpc/platforms/44x/Kconfig
>+++ b/arch/powerpc/platforms/44x/Kconfig
>@@ -206,15 +206,10 @@ config AKEBONO
> select PPC4xx_HSTA_MSI
> select I2C
> select I2C_IBM_IIC
>- select NETDEVICES
>- select ETHERNET
>- select NET_VENDOR_IBM
> select IBM_EMAC_EMAC4 if IBM_EMAC
> select USB if USB_SUPPORT
> select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
> select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
>- select MMC_SDHCI
>- select MMC_SDHCI_PLTFM
> select ATA
> select SATA_AHCI_PLATFORM
> help
Sure. I thought that lots of what was already there
should be in the defconfig. I was just going with the flow.
Thanks for fixing it.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 4899f32e4f2a936dc20fbfc4fde85b003387c5c2
From: kernel test robot @ 2021-01-22 3:37 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 4899f32e4f2a936dc20fbfc4fde85b003387c5c2 powerpc/64: prevent replayed interrupt handlers from running softirqs
elapsed time: 735m
configs tested: 91
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc chrp32_defconfig
sh rsk7203_defconfig
arm h3600_defconfig
m68k m5407c3_defconfig
sh sdk7786_defconfig
c6x dsk6455_defconfig
xtensa generic_kc705_defconfig
powerpc socrates_defconfig
m68k atari_defconfig
arm mxs_defconfig
powerpc currituck_defconfig
arm trizeps4_defconfig
h8300 h8s-sim_defconfig
c6x evmc6678_defconfig
arm tct_hammer_defconfig
mips bigsur_defconfig
powerpc makalu_defconfig
powerpc xes_mpc85xx_defconfig
sh kfr2r09_defconfig
mips pic32mzda_defconfig
mips loongson3_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210121
i386 randconfig-a002-20210121
i386 randconfig-a004-20210121
i386 randconfig-a006-20210121
i386 randconfig-a005-20210121
i386 randconfig-a003-20210121
x86_64 randconfig-a002-20210121
x86_64 randconfig-a003-20210121
x86_64 randconfig-a001-20210121
x86_64 randconfig-a005-20210121
x86_64 randconfig-a006-20210121
x86_64 randconfig-a004-20210121
i386 randconfig-a013-20210121
i386 randconfig-a011-20210121
i386 randconfig-a012-20210121
i386 randconfig-a014-20210121
i386 randconfig-a015-20210121
i386 randconfig-a016-20210121
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes] BUILD SUCCESS 08685be7761d69914f08c3d6211c543a385a5b9c
From: kernel test robot @ 2021-01-22 3:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes
branch HEAD: 08685be7761d69914f08c3d6211c543a385a5b9c powerpc/64s: fix scv entry fallback flush vs interrupt
elapsed time: 735m
configs tested: 91
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc mpc8313_rdb_defconfig
arm sama5_defconfig
mips ar7_defconfig
m68k m5275evb_defconfig
arm h5000_defconfig
sh se7619_defconfig
h8300 h8s-sim_defconfig
mips maltaup_xpa_defconfig
sparc64 alldefconfig
arm cerfcube_defconfig
m68k stmark2_defconfig
powerpc xes_mpc85xx_defconfig
sh kfr2r09_defconfig
mips pic32mzda_defconfig
mips loongson3_defconfig
arm imx_v4_v5_defconfig
arm eseries_pxa_defconfig
mips jmr3927_defconfig
sh sh7770_generic_defconfig
arm tango4_defconfig
arm omap1_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210121
i386 randconfig-a002-20210121
i386 randconfig-a004-20210121
i386 randconfig-a006-20210121
i386 randconfig-a005-20210121
i386 randconfig-a003-20210121
x86_64 randconfig-a002-20210121
x86_64 randconfig-a003-20210121
x86_64 randconfig-a001-20210121
x86_64 randconfig-a005-20210121
x86_64 randconfig-a006-20210121
x86_64 randconfig-a004-20210121
i386 randconfig-a013-20210121
i386 randconfig-a011-20210121
i386 randconfig-a012-20210121
i386 randconfig-a014-20210121
i386 randconfig-a015-20210121
i386 randconfig-a016-20210121
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 534e43a737e9ad2b438eda651272f2774484b922
From: kernel test robot @ 2021-01-22 3:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 534e43a737e9ad2b438eda651272f2774484b922 powerpc/44x: Remove STDBINUTILS kconfig option
elapsed time: 735m
configs tested: 95
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
openrisc alldefconfig
arm lart_defconfig
arm pleb_defconfig
arm assabet_defconfig
sh se7619_defconfig
arm trizeps4_defconfig
arm pxa3xx_defconfig
arm mmp2_defconfig
c6x dsk6455_defconfig
m68k stmark2_defconfig
arm cm_x300_defconfig
mips ip27_defconfig
m68k amcore_defconfig
powerpc sequoia_defconfig
mips ath25_defconfig
arm orion5x_defconfig
powerpc xes_mpc85xx_defconfig
sh kfr2r09_defconfig
mips pic32mzda_defconfig
mips loongson3_defconfig
s390 zfcpdump_defconfig
arm aspeed_g4_defconfig
mips malta_defconfig
csky alldefconfig
powerpc ppa8548_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210121
i386 randconfig-a002-20210121
i386 randconfig-a004-20210121
i386 randconfig-a006-20210121
i386 randconfig-a005-20210121
i386 randconfig-a003-20210121
x86_64 randconfig-a002-20210121
x86_64 randconfig-a003-20210121
x86_64 randconfig-a001-20210121
x86_64 randconfig-a005-20210121
x86_64 randconfig-a006-20210121
x86_64 randconfig-a004-20210121
i386 randconfig-a013-20210121
i386 randconfig-a011-20210121
i386 randconfig-a012-20210121
i386 randconfig-a014-20210121
i386 randconfig-a015-20210121
i386 randconfig-a016-20210121
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
From: Thiago Jung Bauermann @ 2021-01-22 4:37 UTC (permalink / raw)
To: rppt
Cc: riel, kernel-team, Ram Pai, linux-kernel, guro, linux-mm,
Satheesh Rajendran, Konrad Rzeszutek Wilk, iamjoonsoo.kim, mhocko,
linuxppc-dev, akpm, Thiago Jung Bauermann
In-Reply-To: <20201220064959.GB392325@kernel.org>
Mike Rapoport <rppt@kernel.org> writes:
> > Signed-off-by: Roman Gushchin <guro@fb.com>
>
> Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
I've seen a couple of spurious triggers of the WARN_ONCE() removed by this
patch. This happens on some ppc64le bare metal (powernv) server machines with
CONFIG_SWIOTLB=y and crashkernel=4G, as described in a candidate patch I posted
to solve this issue in a different way:
https://lore.kernel.org/linuxppc-dev/20201218062103.76102-1-bauerman@linux.ibm.com/
Since this patch solves that problem, is it possible to include it in the next
feasible v5.11-rcX, with the following tag?
Fixes: 8fabc623238e ("powerpc: Ensure that swiotlb buffer is allocated from low memory")
This is because reverting the commit above also solves the problem on the
machines where I've seen this issue.
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: export 'cpm_setbrg' for modules
From: Christophe Leroy @ 2021-01-22 5:51 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Christophe Leroy, kernel test robot, Nick Desaulniers,
clang-built-linux, Paul Mackerras, Andrew Morton, linuxppc-dev
In-Reply-To: <20210122010819.30986-1-rdunlap@infradead.org>
Le 22/01/2021 à 02:08, Randy Dunlap a écrit :
> Fix missing export for a loadable module build:
>
> ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!
>
> Fixes: 4128a89ac80d ("powerpc/8xx: move CPM1 related files from sysdev/ to platforms/8xx")
I don't understand. Before that commit cpm_setbrg() wasn't exported either.
For me, it fixes the commit that brought the capability to build the cpm uart driver as a module,
that is commit 1da177e4c3f4 ("Linux-2.6.12-rc")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: clang-built-linux@googlegroups.com
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/platforms/8xx/cpm1.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20210121.orig/arch/powerpc/platforms/8xx/cpm1.c
> +++ linux-next-20210121/arch/powerpc/platforms/8xx/cpm1.c
> @@ -280,6 +280,7 @@ cpm_setbrg(uint brg, uint rate)
> out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
> CPM_BRG_EN | CPM_BRG_DIV16);
> }
> +EXPORT_SYMBOL(cpm_setbrg);
>
> struct cpm_ioport16 {
> __be16 dir, par, odr_sor, dat, intr;
>
^ permalink raw reply
* Re: [PATCH v3] powerpc/mce: Remove per cpu variables from MCE handlers
From: Ganesh @ 2021-01-22 6:05 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev, mpe; +Cc: mahesh
In-Reply-To: <1611028087.3uko7j7l9g.astroid@bobo.none>
On 1/19/21 9:28 AM, Nicholas Piggin wrote:
> Excerpts from Ganesh Goudar's message of January 15, 2021 10:58 pm:
>> Access to per-cpu variables requires translation to be enabled on
>> pseries machine running in hash mmu mode, Since part of MCE handler
>> runs in realmode and part of MCE handling code is shared between ppc
>> architectures pseries and powernv, it becomes difficult to manage
>> these variables differently on different architectures, So have
>> these variables in paca instead of having them as per-cpu variables
>> to avoid complications.
> Seems okay.
>
>> Maximum recursive depth of MCE is 4, Considering the maximum depth
>> allowed reduce the size of event to 10 from 100.
> Could you make this a separate patch, with memory saving numbers?
> "Delayed" MCEs are not necessarily the same as recursive (several
> sequential MCEs can occur before the first event is processed).
> But I agree 100 is pretty overboard (as is 4 recursive MCEs really).
Sure.
>> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
>> ---
>> v2: Dynamically allocate memory for machine check event info
>>
>> v3: Remove check for hash mmu lpar, use memblock_alloc_try_nid
>> to allocate memory.
>> ---
>> arch/powerpc/include/asm/mce.h | 21 ++++++++-
>> arch/powerpc/include/asm/paca.h | 4 ++
>> arch/powerpc/kernel/mce.c | 76 +++++++++++++++++-------------
>> arch/powerpc/kernel/setup-common.c | 2 +-
>> 4 files changed, 69 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
>> index e6c27ae843dc..8d6e3a7a9f37 100644
>> --- a/arch/powerpc/include/asm/mce.h
>> +++ b/arch/powerpc/include/asm/mce.h
>> @@ -204,7 +204,18 @@ struct mce_error_info {
>> bool ignore_event;
>> };
>>
>> -#define MAX_MC_EVT 100
>> +#define MAX_MC_EVT 10
>> +
>> +struct mce_info {
>> + int mce_nest_count;
>> + struct machine_check_event mce_event[MAX_MC_EVT];
>> + /* Queue for delayed MCE events. */
>> + int mce_queue_count;
>> + struct machine_check_event mce_event_queue[MAX_MC_EVT];
>> + /* Queue for delayed MCE UE events. */
>> + int mce_ue_count;
>> + struct machine_check_event mce_ue_event_queue[MAX_MC_EVT];
>> +};
>>
>> /* Release flags for get_mce_event() */
>> #define MCE_EVENT_RELEASE true
>> @@ -233,5 +244,13 @@ long __machine_check_early_realmode_p7(struct pt_regs *regs);
>> long __machine_check_early_realmode_p8(struct pt_regs *regs);
>> long __machine_check_early_realmode_p9(struct pt_regs *regs);
>> long __machine_check_early_realmode_p10(struct pt_regs *regs);
>> +#define get_mce_info() local_paca->mce_info
> I don't think this adds anything. Could you open code it?
ok
> Thanks,
> Nick
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: export 'cpm_setbrg' for modules
From: Randy Dunlap @ 2021-01-22 6:11 UTC (permalink / raw)
To: Christophe Leroy, linux-kernel
Cc: Christophe Leroy, kernel test robot, Nick Desaulniers,
clang-built-linux, Paul Mackerras, Andrew Morton, linuxppc-dev
In-Reply-To: <91159e78-4eea-c645-9171-a5b90271710f@csgroup.eu>
On 1/21/21 9:51 PM, Christophe Leroy wrote:
>
>
> Le 22/01/2021 à 02:08, Randy Dunlap a écrit :
>> Fix missing export for a loadable module build:
>>
>> ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!
>>
>> Fixes: 4128a89ac80d ("powerpc/8xx: move CPM1 related files from sysdev/ to platforms/8xx")
>
> I don't understand. Before that commit cpm_setbrg() wasn't exported either.
>
> For me, it fixes the commit that brought the capability to build the cpm uart driver as a module, that is commit 1da177e4c3f4 ("Linux-2.6.12-rc")
OK, I didn't have a lot of confidence in that tag.
Thanks for commenting.
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Cc: Nick Desaulniers <ndesaulniers@google.com>
>> Cc: clang-built-linux@googlegroups.com
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> ---
>> arch/powerpc/platforms/8xx/cpm1.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> --- linux-next-20210121.orig/arch/powerpc/platforms/8xx/cpm1.c
>> +++ linux-next-20210121/arch/powerpc/platforms/8xx/cpm1.c
>> @@ -280,6 +280,7 @@ cpm_setbrg(uint brg, uint rate)
>> out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
>> CPM_BRG_EN | CPM_BRG_DIV16);
>> }
>> +EXPORT_SYMBOL(cpm_setbrg);
>> struct cpm_ioport16 {
>> __be16 dir, par, odr_sor, dat, intr;
>>
--
~Randy
RFC: Features and documentation: http://lwn.net/Articles/260136/
^ permalink raw reply
* Re: [PATCH] lib/sstep: Fix incorrect return from analyze_instr()
From: Naveen N. Rao @ 2021-01-22 6:27 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli
Cc: ravi.bangoria, paulus, sandipan, naveen.n.rao, linuxppc-dev
In-Reply-To: <161124771457.333703.14641179082577500423.stgit@thinktux.local>
On 2021/01/21 10:18PM, Ananth N Mavinakayanahalli wrote:
> We currently just percolate the return value from analyze_instr()
> to the caller of emulate_step(), especially if it is a -1.
>
> For one particular case (opcode = 4) for instructions that
> aren't currently emulated, we are returning 'should not be
> single-stepped' while we should have returned 0 which says
> 'did not emulate, may have to single-step'.
>
> Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/lib/sstep.c | 49 +++++++++++++++++++++++++---------------------
> 1 file changed, 27 insertions(+), 22 deletions(-)
Fixes: 930d6288a26787 ("powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions")
Reviewed-by: Naveen N. Rao < naveen.n.rao@linux.vnet.ibm.com>
- Naveen
^ permalink raw reply
* Re: [PATCH] lib/sstep: Fix incorrect return from analyze_instr()
From: Sandipan Das @ 2021-01-22 7:09 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli
Cc: naveen.n.rao, linuxppc-dev, paulus, ravi.bangoria
In-Reply-To: <161124771457.333703.14641179082577500423.stgit@thinktux.local>
On 21/01/21 10:18 pm, Ananth N Mavinakayanahalli wrote:
> We currently just percolate the return value from analyze_instr()
> to the caller of emulate_step(), especially if it is a -1.
>
> For one particular case (opcode = 4) for instructions that
> aren't currently emulated, we are returning 'should not be
> single-stepped' while we should have returned 0 which says
> 'did not emulate, may have to single-step'.
>
> Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/lib/sstep.c | 49 +++++++++++++++++++++++++---------------------
> 1 file changed, 27 insertions(+), 22 deletions(-)
>
Thanks for fixing this.
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
^ permalink raw reply
* [PATCH] powerpc/32: Use r2 in wrtspr() instead of r0
From: Christophe Leroy @ 2021-01-22 7:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
wrtspr() is a function to write an arbitrary value in a special
register. It is used on 8xx to write to SPRN_NRI, SPRN_EID and
SPRN_EIE. Writing any value to one of those will play with MSR EE
and MSR RI regardless of that value.
r0 is used many places in the generated code and using r0 for
that creates an unnecessary dependency of this instruction with
preceding ones using r0 in a few places in vmlinux.
r2 is most likely the most stable register as it contains the
pointer to 'current'.
Using r2 instead of r0 avoids that unnecessary dependency.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/reg.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index e40a921d78f9..32a9020e93ab 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1392,8 +1392,7 @@ static inline void mtmsr_isync(unsigned long val)
: "r" ((unsigned long)(v)) \
: "memory")
#endif
-#define wrtspr(rn) asm volatile("mtspr " __stringify(rn) ",0" : \
- : : "memory")
+#define wrtspr(rn) asm volatile("mtspr " __stringify(rn) ",2" : : : "memory")
static inline void wrtee(unsigned long val)
{
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/prom: Fix "ibm,arch-vec-5-platform-support" scan
From: Cédric Le Goater @ 2021-01-22 7:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cédric Le Goater, stable
The "ibm,arch-vec-5-platform-support" property is a list of pairs of
bytes representing the options and values supported by the platform
firmware. At boot time, Linux scans this list and activates the
available features it recognizes : Radix and XIVE.
A recent change modified the number of entries to loop on and 8 bytes,
4 pairs of { options, values } entries are always scanned. This is
fine on KVM but not on PowerVM which can advertises less. As a
consequence on this platform, Linux reads extra entries pointing to
random data, interprets these as available features and tries to
activate them, leading to a firmware crash in
ibm,client-architecture-support.
Fix that by using the property length of "ibm,arch-vec-5-platform-support".
Cc: stable@vger.kernel.org # v4.20+
Fixes: ab91239942a9 ("powerpc/prom: Remove VLA in prom_check_platform_support()")
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/kernel/prom_init.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e9d4eb6144e1..ccf77b985c8f 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1331,14 +1331,10 @@ static void __init prom_check_platform_support(void)
if (prop_len > sizeof(vec))
prom_printf("WARNING: ibm,arch-vec-5-platform-support longer than expected (len: %d)\n",
prop_len);
- prom_getprop(prom.chosen, "ibm,arch-vec-5-platform-support",
- &vec, sizeof(vec));
- for (i = 0; i < sizeof(vec); i += 2) {
- prom_debug("%d: index = 0x%x val = 0x%x\n", i / 2
- , vec[i]
- , vec[i + 1]);
- prom_parse_platform_support(vec[i], vec[i + 1],
- &supported);
+ prom_getprop(prom.chosen, "ibm,arch-vec-5-platform-support", &vec, sizeof(vec));
+ for (i = 0; i < prop_len; i += 2) {
+ prom_debug("%d: index = 0x%x val = 0x%x\n", i / 2, vec[i], vec[i + 1]);
+ prom_parse_platform_support(vec[i], vec[i + 1], &supported);
}
}
--
2.26.2
^ permalink raw reply related
* [PATCH v2 04/14] powerpc/40x: Change CRITICAL_EXCEPTION_PROLOG macro to a gas macro
From: Christophe Leroy @ 2021-01-22 10:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, npiggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1611309841.git.christophe.leroy@csgroup.eu>
Change CRITICAL_EXCEPTION_PROLOG macro to a gas macro to
remove the ugly ; and \ on each line.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_40x.S | 71 +++++++++++++++++-----------------
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 283ea6fcfb81..595a4cf83391 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -100,42 +100,43 @@ _ENTRY(saved_ksp_limit)
* Instead we use a couple of words of memory at low physical addresses.
* This is OK since we don't support SMP on these processors.
*/
-#define CRITICAL_EXCEPTION_PROLOG \
- stw r10,crit_r10@l(0); /* save two registers to work with */\
- stw r11,crit_r11@l(0); \
- mfcr r10; /* save CR in r10 for now */\
- mfspr r11,SPRN_SRR3; /* check whether user or kernel */\
- andi. r11,r11,MSR_PR; \
- lis r11,critirq_ctx@ha; \
- tophys(r11,r11); \
- lwz r11,critirq_ctx@l(r11); \
- beq 1f; \
- /* COMING FROM USER MODE */ \
- mfspr r11,SPRN_SPRG_THREAD; /* if from user, start at top of */\
- lwz r11,TASK_STACK-THREAD(r11); /* this thread's kernel stack */\
-1: addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc an excpt frm */\
- tophys(r11,r11); \
- stw r10,_CCR(r11); /* save various registers */\
- stw r12,GPR12(r11); \
- stw r9,GPR9(r11); \
- mflr r10; \
- stw r10,_LINK(r11); \
- mfspr r12,SPRN_DEAR; /* save DEAR and ESR in the frame */\
- stw r12,_DEAR(r11); /* since they may have had stuff */\
- mfspr r9,SPRN_ESR; /* in them at the point where the */\
- stw r9,_ESR(r11); /* exception was taken */\
- mfspr r12,SPRN_SRR2; \
- stw r1,GPR1(r11); \
- mfspr r9,SPRN_SRR3; \
- stw r1,0(r11); \
- tovirt(r1,r11); \
- rlwinm r9,r9,0,14,12; /* clear MSR_WE (necessary?) */\
- stw r0,GPR0(r11); \
- lis r10, STACK_FRAME_REGS_MARKER@ha; /* exception frame marker */\
- addi r10, r10, STACK_FRAME_REGS_MARKER@l; \
- stw r10, 8(r11); \
- SAVE_4GPRS(3, r11); \
+.macro CRITICAL_EXCEPTION_PROLOG
+ stw r10,crit_r10@l(0) /* save two registers to work with */
+ stw r11,crit_r11@l(0)
+ mfcr r10 /* save CR in r10 for now */
+ mfspr r11,SPRN_SRR3 /* check whether user or kernel */
+ andi. r11,r11,MSR_PR
+ lis r11,critirq_ctx@ha
+ tophys(r11,r11)
+ lwz r11,critirq_ctx@l(r11)
+ beq 1f
+ /* COMING FROM USER MODE */
+ mfspr r11,SPRN_SPRG_THREAD /* if from user, start at top of */
+ lwz r11,TASK_STACK-THREAD(r11) /* this thread's kernel stack */
+1: addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE /* Alloc an excpt frm */
+ tophys(r11,r11)
+ stw r10,_CCR(r11) /* save various registers */
+ stw r12,GPR12(r11)
+ stw r9,GPR9(r11)
+ mflr r10
+ stw r10,_LINK(r11)
+ mfspr r12,SPRN_DEAR /* save DEAR and ESR in the frame */
+ stw r12,_DEAR(r11) /* since they may have had stuff */
+ mfspr r9,SPRN_ESR /* in them at the point where the */
+ stw r9,_ESR(r11) /* exception was taken */
+ mfspr r12,SPRN_SRR2
+ stw r1,GPR1(r11)
+ mfspr r9,SPRN_SRR3
+ stw r1,0(r11)
+ tovirt(r1,r11)
+ rlwinm r9,r9,0,14,12 /* clear MSR_WE (necessary?) */
+ stw r0,GPR0(r11)
+ lis r10, STACK_FRAME_REGS_MARKER@ha /* exception frame marker */
+ addi r10, r10, STACK_FRAME_REGS_MARKER@l
+ stw r10, 8(r11)
+ SAVE_4GPRS(3, r11)
SAVE_2GPRS(7, r11)
+.endm
/*
* State at this point:
--
2.25.0
^ permalink raw reply related
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