On Fri, May 06, 2022 at 09:48:28PM +0200, Thomas Gleixner wrote:
> Ricardo,
Thank you very much for your feedback Thomas! I am sorry for my late reply, I
had been out of office.
>
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> > Certain types of interrupts, such as NMI, do not have an
On Fri, May 06, 2022 at 10:05:34PM +0200, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> > There are no restrictions in hardware to set MSI messages with its
> > own delivery mode.
>
> "messages with its own" ? Plural/singular confusion.
Yes, this is not correct.
On Mon, Apr 18, 2022 at 03:02:37PM +, Kuppuswamy Sathyanarayanan wrote:
> Currently the aer_irq() handler returns IRQ_NONE for cases without bits
> PCI_ERR_ROOT_UNCOR_RCV or PCI_ERR_ROOT_COR_RCV are set. But this
> assumption is incorrect.
>
> Consider a scenario where aer_irq() is triggered
On Fri, May 06, 2022 at 09:53:54PM +0200, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> > Currently, the delivery mode of all interrupts is set to the mode of the
> > APIC driver in use. There are no restrictions in hardware to configure the
> > delivery mode of each
smp_shutdown_nonboot_cpus() repeats the same code chunk as
migrate_to_reboot_cpu() to ensure that the rebooting happens on a valid
cpu.
if (!cpu_online(primary_cpu))
primary_cpu = cpumask_first(cpu_online_mask);
This is due to an unexpected cpu-down event like the
On 5/11/22 4:40 PM, Bjorn Helgaas wrote:
On Mon, Apr 18, 2022 at 03:02:37PM +, Kuppuswamy Sathyanarayanan wrote:
Currently the aer_irq() handler returns IRQ_NONE for cases without bits
PCI_ERR_ROOT_UNCOR_RCV or PCI_ERR_ROOT_COR_RCV are set. But this
assumption is incorrect.
Consider a
On 5/11/22 4:27 PM, Bjorn Helgaas wrote:
[Eric: proposed reproducing steps]
Fixes: 4696b828ca37 ("PCI/AER: Hoist aerdrv.c, aer_inject.c up to
drivers/pci/pcie/")
4696b828ca37 only*moves* drivers/pci/pcie/aer/aerdrv.c to
drivers/pci/pcie/aer.c, so I don't think it's related.
I think the
On Mon, May 9, 2022 at 4:09 AM Masahiro Yamada wrote:
>
> There were more EXPORT_SYMBOL types in the past. The following commits
> removed unused ones.
>
> - f1c3d73e973c ("module: remove EXPORT_SYMBOL_GPL_FUTURE")
> - 367948220fce ("module: remove EXPORT_UNUSED_SYMBOL*")
>
> There are 3
On Mon, May 9, 2022 at 4:09 AM Masahiro Yamada wrote:
>
> This is a remnant of commit 6543becf26ff ("mod/file2alias: make
> modalias generation safe for cross compiling").
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
>
> Changes in v4:
> - New patch
>
>
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: ee8348496c77e3737d0a6cda307a521f2cff954f KVM: PPC: Book3S PR:
Enable MSR_DR for switch_mmu_context()
elapsed time: 751m
configs tested: 182
configs skipped: 114
The following configs have
On Mon, Apr 18, 2022 at 03:02:37PM +, Kuppuswamy Sathyanarayanan wrote:
> Currently the aer_irq() handler returns IRQ_NONE for cases without bits
> PCI_ERR_ROOT_UNCOR_RCV or PCI_ERR_ROOT_COR_RCV are set. But this
> assumption is incorrect.
>
> Consider a scenario where aer_irq() is triggered
This patch series implements KASAN on 64-bit POWER with radix MMU,
such as POWER9 or POWER10. Daniel Axtens posted previous versions of
these patches, but is no longer working on KASAN, and I have been
asked to get them ready for inclusion.
Because of various technical difficulties, mostly
of_find_i2c_device_by_node() takes a reference,
In error paths, we should call put_device() to drop
the reference to aviod refount leak.
Fixes: 81e8e4926167 ("ASoC: fsl: add sgtl5000 clock support for imx-sgtl5000")
Signed-off-by: Miaoqian Lin
---
sound/soc/fsl/imx-sgtl5000.c | 14
Thanks for reviewing this patch Aneesh,
"Aneesh Kumar K.V" writes:
> Vaibhav Jain writes:
>
>> Right now 'char *' elements allocated individual 'stat_id' in
>> 'papr_scm_priv.nvdimm_events_map' during papr_scm_pmu_check_events() leak in
>> papr_scm_remove() and papr_scm_pmu_register(),
From: Daniel Axtens
Implement a limited form of KASAN for Book3S 64-bit machines running under
the Radix MMU, supporting only outline mode.
- Enable the compiler instrumentation to check addresses and maintain the
shadow region. (This is the guts of KASAN which we can easily reuse.)
-
From: Daniel Axtens
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Daniel Axtens
Signed-off-by: Paul Mackerras
---
Documentation/dev-tools/kasan.rst | 8 ++--
From: Daniel Axtens
kasan is already implied by the directory name, we don't need to
repeat it.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
Signed-off-by: Paul Mackerras
---
arch/powerpc/mm/kasan/Makefile | 2 +-
arch/powerpc/mm/kasan/{kasan_init_32.c
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300774|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=215389
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #300775|0 |1
is obsolete|
Right now 'char *' elements allocated for individual 'stat_id' in
'papr_scm_priv.nvdimm_events_map[]' during papr_scm_pmu_check_events(), get
leaked in papr_scm_remove() and papr_scm_pmu_register(),
papr_scm_pmu_check_events() error paths.
Also individual 'stat_id' arent NULL terminated 'char *'
On Wed, May 11, 2022 at 3:58 AM Miaoqian Lin wrote:
>
> of_find_i2c_device_by_node() takes a reference,
> In error paths, we should call put_device() to drop
> the reference to aviod refount leak.
s/aviod refount/avoid refcount
> Fixes: 81e8e4926167 ("ASoC: fsl: add sgtl5000 clock support for
The session topology test fails in powerpc pSeries platform.
Test logs:
<<>>
Session topology : FAILED!
<<>>
This testcases tests cpu topology by checking the core_id and
socket_id stored in perf_env from perf session. The data from
perf session is compared with the cpu topology information
from
Perf BPF filter test fails in environment where "clang"
is not installed.
Test failure logs:
<<>>
42: BPF filter:
42.1: Basic BPF filtering : Skip
42.2: BPF pinning : FAILED!
42.3: BPF prologue generation : FAILED!
<<>>
Enabling verbose option
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When unmapping a hugetlb page, we will get the relevant page table
entry by
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size specified.
When migrating a hugetlb page, we will get the relevant page table
entry by
It is incorrect to use ptep_clear_flush() to nuke a hugetlb page
table when unmapping or migrating a hugetlb page, and will change
to use huge_ptep_clear_flush() instead in the following patches.
So this is a preparation patch, which changes the huge_ptep_clear_flush()
to return the original pte
Hi,
Now migrating a hugetlb page or unmapping a poisoned hugetlb page, we'll
use ptep_clear_flush() and set_pte_at() to nuke the page table entry
and remap it, and this is incorrect for CONT-PTE or CONT-PMD size hugetlb
page, which will cause potential data consistent issue. This patch set
will
> On 11-May-2022, at 2:56 PM, Sachin Sant wrote:
>
> While running xfstests (specifically ext4/032) w/ext4 on a POWER9 LPAR running
> linux-next version 5.18.0-rc6-next-20220510 following crash is seen:
>
> [ 472.486440] EXT4-fs (loop0): resized filesystem to 41943040
> [ 472.760888] BUG:
CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:
Hi Bjorn,
On 4/18/22 8:02 AM, Kuppuswamy Sathyanarayanan wrote:
Currently the aer_irq() handler returns IRQ_NONE for cases without bits
PCI_ERR_ROOT_UNCOR_RCV or PCI_ERR_ROOT_COR_RCV are set. But this
assumption is incorrect.
Consider a scenario where aer_irq() is triggered for a correctable
While running xfstests (specifically ext4/032) w/ext4 on a POWER9 LPAR running
linux-next version 5.18.0-rc6-next-20220510 following crash is seen:
[ 472.486440] EXT4-fs (loop0): resized filesystem to 41943040
[ 472.760888] BUG: Kernel NULL pointer dereference at 0x002c
[ 472.760891]
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #18 from Erhard F. (erhar...@mailbox.org) ---
Ok, and another problem during building via distcc on the G4, still
LOWMEM_SIZE=0x2800 (kernel v5.17.6).
[...]
Oops: Kernel stack overflow, sig: 11 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP
On Mon, May 09, 2022 at 09:13:03AM -0700, Luis Chamberlain wrote:
> On Mon, May 09, 2022 at 09:23:39PM +1000, Michael Ellerman wrote:
> > Herbert Xu writes:
> > > Hi:
> > >
> > > There are some code paths in the kernel where you can reliably
> > > trigger a request_module of a non-existant
On 11.05.22 14:04, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When migrating a hugetlb page,
When linking vdso{32,64}.so.dbg with ld.lld, there is a warning about
not finding _start for the starting address:
ld.lld: warning: cannot find entry symbol _start; not setting start address
ld.lld: warning: cannot find entry symbol _start; not setting start address
Looking at GCC + GNU ld,
Hi all,
This series is an alternative to the one proposed by Nick before the
PowerPC vDSO unification in commit fd1feade75fb ("powerpc/vdso: Merge
vdso64 and vdso32 into a single directory"):
https://lore.kernel.org/20200901222523.1941988-1-ndesaulni...@google.com/
Normally, we try to make
On 10/05/2022 14:40, Steven Rostedt wrote:
> On Wed, 27 Apr 2022 19:49:17 -0300
> "Guilherme G. Piccoli" wrote:
>
>> Currently we don't have a way to check if there are dumpers set,
>> except counting the list members maybe. This patch introduces a very
>> simple helper to provide this
On 10/05/2022 11:16, Petr Mladek wrote:
> [...]
> Yeah, it is pretty strange behavior.
>
> I looked into the history. This notifier was added into the alpha code
> in 2.4.0-test2pre2. In this historic code, the default panic() code
> either rebooted after a timeout or ended in a infinite loop.
On 10/05/2022 11:28, Petr Mladek wrote:
> [...]
> It is not clear to me why user mode linux should not care about
> the other notifiers. It might be because I do not know much
> about the user mode linux.
>
> Is the because they always create core dump or are never running
> in a hypervisor or
The PowerPC vDSO uses $(CC) to link, which differs from the rest of the
kernel, which uses $(LD) directly. As a result, the default linker of
the compiler is used, which may differ from the linker requested by the
builder. For example:
$ make ARCH=powerpc LLVM=1 mrproper defconfig
On 11.05.22 14:04, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When unmapping a hugetlb page,
On Mon, May 09, 2022 at 11:16:10AM -0300, Guilherme G. Piccoli wrote:
> On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> > Currently we have 3 notifier lists in the panic path, which will
> > be wired in a way to allow the notifier callbacks to run in
> > different moments at panic time, in a
On Thu, May 12, 2022 at 3:48 AM Nick Desaulniers
wrote:
>
> On Mon, May 9, 2022 at 11:57 PM Masahiro Yamada wrote:
> >
> > > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > > > index a78b75f0eeb0..e7e2c70a98f5 100644
> > > > --- a/scripts/mod/modpost.c
> > > > +++
On 11/05/2022 13:45, Heiko Carstens wrote:
> [...]
>>
>> Hey S390/SPARC folks, sorry for the ping!
>>
>> Any reviews on this V1 would be greatly appreciated, I'm working on V2
>> and seeking feedback in the non-reviewed patches.
>
> Sorry, missed that this is quite s390 specific. So, yes, this
On 5/11/2022 12:27 PM, Masahiro Yamada wrote:
On Thu, May 12, 2022 at 3:48 AM Nick Desaulniers
wrote:
On Mon, May 9, 2022 at 11:57 PM Masahiro Yamada wrote:
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index a78b75f0eeb0..e7e2c70a98f5 100644
--- a/scripts/mod/modpost.c
+++
45 matches
Mail list logo
