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(), papr_s
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 ++--
Documentation/powerpc/kasan
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 =>
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.)
- Requ
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 around
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 *' i
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] Faulti
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 im
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 huge_p
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 t
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 huge_p
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 ch
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 NR
> 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: K
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:
https://docs.turris.cz/hw/turris-
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
er
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 module.
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, w
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, w
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 compi
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, t
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 arch/powerpc/k
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
> > > > +++ b/scripts/mod/m
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 informatio
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. The
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 ...
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 sub
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
+++ b/
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 loo
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 f
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 act
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 f
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 ass
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
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 sc
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. It
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 be
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 followin
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
>
> scripts/mod/modp
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 remaini
44 matches
Mail list logo