On 10/27/21 23:16, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
>
>
Early exits from for_each_compatible_node() should decrement the
node reference counter. Reported by Coccinelle:
./arch/powerpc/platforms/44x/fsp2.c:206:1-25: WARNING: Function
"for_each_compatible_node" should have of_node_put() before return
around line 218.
Fixes: 7813043e1bbc ("powerpc/44x/f
On 10/26/21 3:28 PM, kajoljain wrote:
>
>
> On 10/22/21 8:19 PM, Paul A. Clarke wrote:
>> Thanks for the changes!
>> More nits below (many left over from prior review)...
>>
>> On Fri, Oct 22, 2021 at 11:55:05AM +0530, Kajol Jain wrote:
>>> Add pmu metric json file for power10 platform.
>>>
>>
Excerpts from Jacques de Laval's message of October 28, 2021 7:08 pm:
> On Thursday, October 28th, 2021 at 5:01 AM, Nicholas Piggin
> wrote:
>> Excerpts from Jacques de Laval's message of October 27, 2021 10:03 pm:
>>
>> > On Wednesday, October 27th, 2021 at 9:52 AM, Christophe Leroy
>> > christ
From: Jing Yao
Reported-by: Zeal Robot
Signed-off-by: Jing Yao
---
drivers/scsi/ibmvscsi/ibmvfc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index d0eab5700dc5..9f20fefc2c02 100644
--- a/drive
On Wed, Oct 27, 2021 at 11:18 PM Dmitry Osipenko wrote:
>
> SoC platforms often have multiple options of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a single option. Add combined power-off+restart handler call chain API,
> which is inspired
On Wed, Oct 27, 2021 at 11:18 PM Dmitry Osipenko wrote:
>
> SoC platforms often have multiple options of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a single option. Add combined power-off+restart handler call chain API,
> which is inspired
On Thu, Oct 28, 2021 at 12:16:33AM +0300, Dmitry Osipenko wrote:
> Add atomic/blocking_notifier_has_unique_priority() helpers which return
> true if given handler has unique priority.
...
> +/**
> + * atomic_notifier_has_unique_priority - Checks whether notifier's
> priority is unique
> + *
Hi Michael!
On 10/28/21 08:39, Michael Ellerman wrote:
>>> No, I will try that now.
>
> That completed fine on my BE VM here.
>
> I ran these in two tmux windows:
> $ sbuild -d sid --arch=powerpc --no-arch-all gcc-11_11.2.0-10.dsc
> $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-11_11.2.0-10
Christophe Leroy writes:
> Le 27/10/2021 à 06:44, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of October 26, 2021 3:39 pm:
>>> set_memory_x() calls pte_mkexec() which sets _PAGE_EXEC.
>>> set_memory_nx() calls pte_exprotec() which clears _PAGE_EXEC.
>>>
>>> Book3e has 2 b
On Thu, Oct 28, 2021 at 12:16:54AM +0300, Dmitry Osipenko wrote:
> Use devm_register_power_handler() that replaces global pm_power_off_prepare
> variable and allows to register multiple power-off handlers.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
module_trampoline_target() is used by __ftrace_modify_call().
Implement it for PPC32 so that CONFIG_DYNAMIC_FTRACE_WITH_REGS
can be activated on PPC32 as well.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/module_32.c| 25
arch/powerpc/kernel/trace/ftrace.c |
This series implements livepatch on PPC32.
This is largely copied from what's done on PPC64.
Christophe Leroy (5):
livepatch: Fix build failure on 32 bits processors
powerpc/ftrace: No need to read LR from stack in _mcount()
powerpc/ftrace: Add module_trampoline_target() for PPC32
powerpc
Unlike PPC64, PPC32 doesn't require any special compiler option
to get _mcount() call not clobbering registers.
Provide ftrace_regs_caller() and ftrace_regs_call() and activate
HAVE_DYNAMIC_FTRACE_WITH_REGS.
That's heavily copied from ftrace_64_mprofile.S
For the time being leave livepatching as
Trying to build livepatch on powerpc/32 results in:
kernel/livepatch/core.c: In function 'klp_resolve_symbols':
kernel/livepatch/core.c:221:23: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
221 | sym = (Elf64_Sym *)sechdr
This is heavily copied from PPC64. Not much to say about it.
Livepatch sample modules all work.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/livepatch.h | 4 +-
arch/powerpc/kernel/trace/ftrace_32.S | 69 ++
All functions calling _mcount do it exactly the same way, with the
following sequence of instructions:
c07de788: 7c 08 02 a6 mflrr0
c07de78c: 90 01 00 04 stw r0,4(r1)
c07de790: 4b 84 13 65 bl c001faf4 <_mcount>
Allthough LR is pus
On 27/10/2021 16:21, Nicholas Piggin wrote:
From: Laurent Vivier
Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
context before enabling irqs") moved guest_exit() into the interrupt
protected area to avoid wrong context warning (or worse). The problem is
that tick-based t
Excerpts from Nicholas Piggin's message of October 28, 2021 7:35 pm:
> Excerpts from Jacques de Laval's message of October 28, 2021 7:08 pm:
>> On Thursday, October 28th, 2021 at 5:01 AM, Nicholas Piggin
>> wrote:
>>> Excerpts from Jacques de Laval's message of October 27, 2021 10:03 pm:
>>>
>>>
On Thu, Oct 28, 2021 at 12:16:40AM +0300, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the
Dmitry Osipenko 於 2021年10月28日 週四 上午5:18寫道：
>
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
On 27/10/2021 16:21, Nicholas Piggin wrote:
From: Laurent Vivier
Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
context before enabling irqs") moved guest_exit() into the interrupt
protected area to avoid wrong context warning (or worse). The problem is
that tick-based t
When ARCH_SUPPORTS_DEBUG_PAGEALLOC is not selected, the user can
still select CONFIG_DEBUG_PAGEALLOC in which case __kernel_map_pages()
is provided by mm/page_poison.c
So only define __kernel_map_pages() when both
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC and CONFIG_DEBUG_PAGEALLOC
are defined.
Fixes:
A e5500 machine running a 32-bit kernel sometimes hangs at boot,
seemingly going into an infinite loop of instruction storage interrupts.
The ESR SPR has a value of 0x80 (store) when this happens, which is
likely set by a previous store. An instruction TLB miss interrupt would
then leave ESR un
On Thu, 28 Oct 2021 14:24:00 +0200
Christophe Leroy wrote:
> This series implements livepatch on PPC32.
>
> This is largely copied from what's done on PPC64.
>
> Christophe Leroy (5):
> livepatch: Fix build failure on 32 bits processors
> powerpc/ftrace: No need to read LR from stack in _mc
Hello!
An update to this post with oss-security CC'ed.
On 10/26/21 10:48, John Paul Adrian Glaubitz wrote:
> I have tested these patches against 5.14 but it seems the problem [1] still
> remains for me
> for big-endian guests. I built a patched kernel yesterday, rebooted the KVM
> server and le
Le 28/10/2021 à 15:30, Nicholas Piggin a écrit :
A e5500 machine running a 32-bit kernel sometimes hangs at boot,
seemingly going into an infinite loop of instruction storage interrupts.
The ESR SPR has a value of 0x80 (store) when this happens, which is
likely set by a previous store. An
Hello!
On 10/28/21 15:52, John Paul Adrian Glaubitz wrote:
> I am not sure what triggered my previous crash but I don't think it's related
> to this
> particular bug. I will keep monitoring the server in any case and open a new
> bug report
> in case I'm running into similar issues.
This is ver
Hi Michael!
On 10/28/21 13:20, John Paul Adrian Glaubitz wrote:
> It seems I also can no longer reproduce the issue, even when building the
> most problematic
> packages and I think we should consider it fixed for now. I will keep
> monitoring the server,
> of course, and will let you know in ca
Hi!
On 10/28/21 16:05, John Paul Adrian Glaubitz wrote:
> The following packages were being built at the same time:
>
> - guest 1: virtuoso-opensource and openturns
> - guest 2: llvm-toolchain-13
>
> I really did a lot of testing today with no issues and just after I sent my
> report
> to oss-s
As well known, hvc backend can register its opertions to hvc backend.
the operations contain put_chars(), get_chars() and so on.
Some hvc backend may do dma in its operations. eg, put_chars() of
virtio-console. But in the code of hvc framework, it may pass DMA
incapable memory to put_chars() under
This revert commit c4baad5029 ("virtio-console: avoid DMA from stack")
hvc framework will never pass stack memory to the put_chars() function,
So the calling of kmemdup() is unnecessary, we can remove it.
Signed-off-by: Xianting Tian
Reviewed-by: Shile Zhang
---
drivers/char/virtio_console.c |
Dear all,
This patch series make hvc framework pass DMA capable memory to
put_chars() of hvc backend(eg, virtio-console), and revert commit
c4baad5029 ("virtio-console: avoid DMA from stack”)
V1
virtio-console: avoid DMA from vmalloc area
https://lkml.org/lkml/2021/7/27/494
For v1 patch, Arnd Be
Am 2021-10-27 um 9:42 p.m. schrieb Alistair Popple:
> On Wednesday, 27 October 2021 3:09:57 AM AEDT Felix Kuehling wrote:
>> Am 2021-10-25 um 12:16 a.m. schrieb Alistair Popple:
>>> MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a
>>> source page was already locked during migr
Le 27/10/2021 à 11:49, Nicholas Piggin a écrit :
Excerpts from Nicholas Piggin's message of October 27, 2021 1:29 pm:
Excerpts from Laurent Dufour's message of October 27, 2021 2:27 am:
When handling the Watchdog interrupt, long processing should not be done
while holding the __wd_smp_lock. Thi
Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
opal notifier. But I missed to unregister the notifier during module unload
path. This results in below call trace if you try to unload and load
opal_prd module.
Also add new notifier_block for OPAL_MSG_PRD2 message.
Samp
On 10/1/21 11:40 AM, Daniel Axtens wrote:
Hi Vasant,
Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
opal notifier. But I missed to unregister the notifier during module unload
path. This results in below call trace if you try to unload and load
opal_prd module.
Fix
Hi Nick,
> A e5500 machine running a 32-bit kernel sometimes hangs at boot,
> seemingly going into an infinite loop of instruction storage interrupts.
> The ESR SPR has a value of 0x80 (store) when this happens, which is
> likely set by a previous store. An instruction TLB miss interrupt would
Excerpts from Laurent Vivier's message of October 28, 2021 10:48 pm:
> On 27/10/2021 16:21, Nicholas Piggin wrote:
>> From: Laurent Vivier
>>
>> Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
>> context before enabling irqs") moved guest_exit() into the interrupt
>> protec
Excerpts from John Paul Adrian Glaubitz's message of October 29, 2021 12:05 am:
> Hi Michael!
>
> On 10/28/21 13:20, John Paul Adrian Glaubitz wrote:
>> It seems I also can no longer reproduce the issue, even when building the
>> most problematic
>> packages and I think we should consider it fixe
Excerpts from Christophe Leroy's message of October 28, 2021 11:52 pm:
>
>
> Le 28/10/2021 à 15:30, Nicholas Piggin a écrit :
>> A e5500 machine running a 32-bit kernel sometimes hangs at boot,
>> seemingly going into an infinite loop of instruction storage interrupts.
>> The ESR SPR has a value
Excerpts from Daniel Axtens's message of October 29, 2021 8:13 am:
> Hi Nick,
>
>> A e5500 machine running a 32-bit kernel sometimes hangs at boot,
>> seemingly going into an infinite loop of instruction storage interrupts.
>> The ESR SPR has a value of 0x80 (store) when this happens, which is
28.10.2021 14:00, Andy Shevchenko пишет:
> On Thu, Oct 28, 2021 at 12:16:33AM +0300, Dmitry Osipenko wrote:
>> Add atomic/blocking_notifier_has_unique_priority() helpers which return
>> true if given handler has unique priority.
>
> ...
>
>> +/**
>> + * atomic_notifier_has_unique_priority - Chec
28.10.2021 12:53, Rafael J. Wysocki пишет:
>> +/**
>> + * struct power_handler - Machine power-off + restart handler
>> + *
>> + * Describes power-off and restart handlers which are invoked by kernel
>> + * to power off or restart this machine. Supports prioritized chaining for
>> + * both restart
28.10.2021 12:59, Rafael J. Wysocki пишет:
>> +#define RESTART_PRIO_RESERVED 0
>> +#define RESTART_PRIO_DEFAULT 128
>> +#define RESTART_PRIO_HIGH 192
>>
>> enum reboot_mode {
>> REBOOT_UNDEFINED = -1,
>> @@ -49,6 +55,167 @@ int register_restart_handler(struc
28.10.2021 12:59, Rafael J. Wysocki пишет:
>> +/**
>> + * struct power_handler - Machine power-off + restart handler
>> + *
>> + * Describes power-off and restart handlers which are invoked by kernel
>> + * to power off or restart this machine. Supports prioritized chaining for
>> + * both restart
28.10.2021 00:16, Dmitry Osipenko пишет:
> mfd: ab8500: Use devm_register_trivial_power_off_handler()
> reset: ath79: Use devm_register_simple_restart_handler()
> reset: intel-gw: Use devm_register_simple_restart_handler()
> reset: lpc18xx: Use devm_register_prioritized_restart_handler()
>
28.10.2021 14:00, Andy Shevchenko пишет:
>> +while ((*nl) != NULL && (*nl)->priority >= n->priority) {
> ' != NULL' is not needed.
>
I'll change it in v3, thanks.
29.10.2021 00:32, Dmitry Osipenko пишет:
>>> + /*
>>> +* This code gets used during boot-up, when task switching is
>>> +* not yet working and interrupts must remain disabled. At
>> One space is enough.
> This comment is replicated multiple times over this source file. You can
> find it
Daniel Borkmann writes:
> On 10/25/21 8:15 AM, Naveen N. Rao wrote:
>> Hari Bathini wrote:
>>> Running program with bpf-to-bpf function calls results in data access
>>> exception (0x300) with the below call trace:
>>>
>>> [c0113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
>>>
During Live Partition Migration (LPM), it is observed that perf
counter values reports zero post migration completion. However
'perf stat' with workload continues to show counts post migration
since PMU gets disabled/enabled during sched switches. But incase
of system/cpu wide monitoring, zero coun
On 28/10/2021 08:30, Brian King wrote:
On 10/26/21 12:39 AM, Alexey Kardashevskiy wrote:
On 10/26/21 01:40, Brian King wrote:
On 10/23/21 7:18 AM, Alexey Kardashevskiy wrote:
On 23/10/2021 07:18, Brian King wrote:
On 10/22/21 7:24 AM, Alexey Kardashevskiy wrote:
On 22/10/2021 04:44,
Excerpts from Athira Rajeev's message of October 29, 2021 1:05 pm:
> During Live Partition Migration (LPM), it is observed that perf
> counter values reports zero post migration completion. However
> 'perf stat' with workload continues to show counts post migration
> since PMU gets disabled/enabled
On Friday, 29 October 2021 2:33:31 AM AEDT Felix Kuehling wrote:
> Am 2021-10-27 um 9:42 p.m. schrieb Alistair Popple:
> > On Wednesday, 27 October 2021 3:09:57 AM AEDT Felix Kuehling wrote:
> >> Am 2021-10-25 um 12:16 a.m. schrieb Alistair Popple:
> >>> MIGRATE_PFN_LOCKED is used to indicate to mi
54 matches
Mail list logo
