On Fri, 2019-08-16 at 19:50 +0300, Sergey Miroshnichenko wrote:
> A hotplugged bridge with many hotplug-capable ports may request
> reserving more IO space than the machine has. This could be overridden
> with the "hpiosize=" kernel argument though.
>
> But when BARs are movable, there are no
Hi Aneesh,
Thanks for the patch. Minor review comments below:
"Aneesh Kumar K.V" writes:
> This simplifies the error handling and also enable us to switch to
> H_SCM_QUERY hcall in a later patch on H_OVERLAP error.
>
> We also do some kernel print formatting fixup in this patch.
>
>
On Fri, 2019-08-16 at 19:50 +0300, Sergey Miroshnichenko wrote:
> Add pcibios_rescan_prepare()/_done() hooks for the powerpc platform. Now if
> the device's driver supports movable BARs, pcibios_rescan_prepare() will be
> called after the device is stopped, and pcibios_rescan_done() - before it
>
On Mon, 2019-09-02 at 09:28 +0200, David Hildenbrand wrote:
> On 02.09.19 01:54, Alastair D'Silva wrote:
> > On Tue, 2019-08-27 at 09:13 +0200, David Hildenbrand wrote:
> > > On 27.08.19 08:39, Alastair D'Silva wrote:
> > > > On Tue, 2019-08-27 at 08:28 +0200, Michal Hocko wrote:
> > > > > On Tue
Hi Michael,
On 09/03/2019 08:46 AM, Michael Ellerman wrote:
Michael Neuling writes:
From: Gustavo Romero
Add TM selftest to check if FP or VEC register values from one process
can leak into another process when both run on the same CPU.
This tests for CVE-2019-15030 and CVE-2019-15031.
From: Gustavo Romero
Add TM selftest to check if FP or VEC register values from one process
can leak into another process when both run on the same CPU.
Signed-off-by: Gustavo Romero
Signed-off-by: Michael Neuling
---
tools/testing/selftests/powerpc/tm/.gitignore | 1 +
From: Gustavo Romero
When in userspace and MSR FP=0 the hardware FP state is unrelated to
the current process. This is extended for transactions where if tbegin
is run with FP=0, the hardware checkpoint FP state will also be
unrelated to the current process. Due to this, we need to ensure this
From: Gustavo Romero
When we take an FP unavailable exception in a transaction we have to
account for the hardware FP TM checkpointed registers being
incorrect. In this case for this process we know the current and
checkpointed FP registers must be the same (since FP wasn't used
inside the
On Tue, 2019-09-03 at 08:51 +0200, Christophe Leroy wrote:
> > > This piece of code looks pretty similar to the one before. Can we
> > > refactor into a small helper ?
> > >
> >
> > Not much point, it's removed in a subsequent patch.
> >
>
> But you tell me that you leave to people the
On Tue, 2019-09-03 at 22:11 +0200, Gabriel Paubert wrote:
> On Tue, Sep 03, 2019 at 01:31:57PM -0500, Segher Boessenkool wrote:
> > On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote:
> > > Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
> > > > (Why are they separate though? It
On Tue, 2019-09-03 at 11:04 -0500, Segher Boessenkool wrote:
> On Tue, Sep 03, 2019 at 04:28:09PM +0200, Christophe Leroy wrote:
> > Le 03/09/2019 à 15:04, Segher Boessenkool a écrit :
> > > On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> > > > + asm volatile(
> > > > +
On Tue, 2019-09-03 at 08:08 +0200, Christophe Leroy wrote:
>
> Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > Similar to commit 22e9c88d486a
> > ("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
> > this patch converts the following ASM symbols
Thiago Jung Bauermann [bauer...@linux.ibm.com] wrote:
> [ Some people didn't receive all the patches in this series, even though
> the linuxppc-dev list did so trying to send again. This is exactly the
> same series I posted yesterday. Sorry for the clutter. ]
>
> This series contains
Hi Stephen,
On Wed, Sep 4, 2019 at 9:13 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the kbuild tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
>
>
> Presumably introduced by commit
>
> 1267f9d3047d ("kbuild: add $(BASH) to run scripts with
On Tue, Sep 03, 2019 at 02:31:28PM -0500, Segher Boessenkool wrote:
> On Mon, Sep 02, 2019 at 10:55:53PM -0700, Nathan Chancellor wrote:
> > On Thu, Aug 29, 2019 at 09:59:48AM +, David Laight wrote:
> > > From: Nathan Chancellor
> > > > Sent: 28 August 2019 19:45
> > > ...
> > > > However, I
Hi all,
After merging the kbuild tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
Presumably introduced by commit
1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension")
and presumably arch/powerpc/tools/unrel_branch_check.sh (which has no
#!
Andrey Konovalov writes:
> On Tue, Sep 3, 2019 at 4:56 PM Daniel Axtens wrote:
>>
>> Provide the current number of vmalloc shadow pages in
>> /sys/kernel/debug/kasan_vmalloc/shadow_pages.
>
> Maybe it makes sense to put this into /sys/kernel/debug/kasan/
> (without _vmalloc) and name e.g.
On Mon, 2019-08-26 at 09:23 -0400, Nayna Jain wrote:
> The keys used to verify the Host OS kernel are managed by firmware as
> secure variables. This patch loads the verification keys into the .platform
> keyring and revocation hashes into .blacklist keyring. This enables
> verification and
(Cc'ing Josh Boyer, David Howells)
On Mon, 2019-09-02 at 21:55 +1000, Michael Ellerman wrote:
> Nayna Jain writes:
>
> > The handlers to add the keys to the .platform keyring and blacklisted
> > hashes to the .blacklist keyring is common for both the uefi and powerpc
> > mechanisms of loading
For sizes lesser than 128 bytes, the code branches out early without saving
the stack frame, which when restored later drops frame of the caller.
Tested-by: Aneesh Kumar K.V
Signed-off-by: Santosh Sivaraj
---
arch/powerpc/lib/memcpy_mcsafe_64.S | 2 +-
1 file changed, 1 insertion(+), 1
Appropriate self tests for memcpy_mcsafe
Suggested-by: Michael Ellerman
Signed-off-by: Santosh Sivaraj
---
tools/testing/selftests/powerpc/copyloops/.gitignore | 1 +
tools/testing/selftests/powerpc/copyloops/Makefile | 7 ++-
On Tue, Sep 03, 2019 at 01:31:57PM -0500, Segher Boessenkool wrote:
> On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote:
> > Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
> > >(Why are they separate though? It could just be one loop var).
> >
> > Yes it could just be a
On Mon, Sep 02, 2019 at 10:55:53PM -0700, Nathan Chancellor wrote:
> On Thu, Aug 29, 2019 at 09:59:48AM +, David Laight wrote:
> > From: Nathan Chancellor
> > > Sent: 28 August 2019 19:45
> > ...
> > > However, I think that -fno-builtin-* would be appropriate here because
> > > we are
Michael Ellerman writes:
> On Tue, 2019-08-06 at 04:49:14 UTC, Thiago Jung Bauermann wrote:
>> powerpc is also going to use this feature, so put it in a generic location.
>>
>> Signed-off-by: Thiago Jung Bauermann
>> Reviewed-by: Thomas Gleixner
>> Reviewed-by: Christoph Hellwig
>
> Series
Michael Ellerman writes:
> On Tue, 2019-08-20 at 02:13:12 UTC, Thiago Jung Bauermann wrote:
>> Introduce CONFIG_PPC_SVM to control support for secure guests and include
>> Ultravisor-related helpers when it is selected
>>
>> Signed-off-by: Thiago Jung Bauermann
>
> Patch 2-14 & 16 applied to
On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote:
> Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
> >(Why are they separate though? It could just be one loop var).
>
> Yes it could just be a single loop var, but in that case it would have
> to be reset at the start of the
export_imc_mode_and_cmd() function which creates the debugfs interface for
imc-mode and imc-command, is invoked when each nest pmu units is
registered.
When the first nest pmu unit is registered, export_imc_mode_and_cmd()
creates 'imc' directory under `/debug/powerpc/`. In the subsequent
On 03/09/19 4:40 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>> Make RTAS calls to register and un-register for FADump. Also, update
>> how fadump_region contents are diplayed to provide more information.
>
> That sounds like two independent changes, so can this be split into two
>
Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
On Tue, Sep 03, 2019 at 04:28:09PM +0200, Christophe Leroy wrote:
Le 03/09/2019 à 15:04, Segher Boessenkool a écrit :
On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
+ asm volatile(
+ " mtctr %2;"
+
Neither pnv_npu_try_dma_set_bypass nor the pnv_npu_dma_set_32 and
pnv_npu_dma_set_bypass helpers called by it are used anywhere in the
kernel tree, so remove them.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/powernv/npu-dma.c | 99
1 file changed, 99
From: Suraj Jitindar Singh
[ Upstream commit da0ef93310e67ae6902efded60b6724dab27a5d1 ]
The virtual real mode addressing (VRMA) mechanism is used when a
partition is using HPT (Hash Page Table) translation and performs real
mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this mode
On 03/09/19 4:40 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>> Add basic callback functions for FADump on PowerNV platform.
>
> I assume this doesn't actually work yet?
>
> Does something block it from appearing to work at runtime?
With this patch, "fadump=on" would reserve memory
On 03/09/19 4:40 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>> diff --git a/arch/powerpc/include/asm/opal-api.h
>> b/arch/powerpc/include/asm/opal-api.h
>> index 383242e..c8a5665 100644
>> --- a/arch/powerpc/include/asm/opal-api.h
>> +++ b/arch/powerpc/include/asm/opal-api.h
>> @@
From: Michael Neuling
[ Upstream commit 3fefd1cd95df04da67c83c1cb93b663f04b3324f ]
When emulating tsr, treclaim and trechkpt, we incorrectly set CR0. The
code currently sets:
CR0 <- 00 || MSR[TS]
but according to the ISA it should be:
CR0 <- 0 || MSR[TS] || 0
This fixes the bit shift
From: Paul Mackerras
[ Upstream commit fd0944baad806dfb4c777124ec712c55b714ff51 ]
When the 'regs' field was added to struct kvm_vcpu_arch, the code
was changed to use several of the fields inside regs (e.g., gpr, lr,
etc.) but not the ccr field, because the ccr field in struct pt_regs
is 64
On 03/09/19 4:40 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>
>> Except for reserve dump area which is permanent reserved, all memory
> permanently
>
>> above boot memory size is released when the dump is invalidated. Make
>> this a bit more
From: Michael Ellerman
[ Upstream commit c3c7470c75566a077c8dc71dcf8f1948b8ddfab4 ]
When the hash MMU is active the AMR, IAMR and UAMOR are used for
pkeys. The AMR is directly writable by user space, and the UAMOR masks
those writes, meaning both registers are effectively user register
state.
From: Ram Pai
[ Upstream commit 2cd4bd192ee94848695c1c052d87913260e10f36 ]
Protection key tracking information is not copied over to the
mm_struct of the child during fork(). This can cause the child to
erroneously allocate keys that were already allocated. Any allocated
execute-only key is
From: Paul Mackerras
[ Upstream commit 234ff0b729ad882d20f7996591a964965647addf ]
Testing has revealed an occasional crash which appears to be caused
by a race between kvmppc_switch_mmu_to_hpt and kvm_unmap_hva_range_hv.
The symptom is a NULL pointer dereference in __find_linux_pte() called
On 03/09/19 4:40 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>> Introduce callback functions for platform specific operations like
>> register, unregister, invalidate & such. Also, define place-holders
>> for the same on pSeries platform.
>
> We already have an ops structure for
On 03/09/19 4:39 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>> Though asm/fadump.h is meant to be used by other components dealing
>> with FADump, it also has macros/definitions internal to FADump code.
>> Move them to a new header file used within FADump code. This also
>> makes way
On 03/09/19 4:39 PM, Michael Ellerman wrote:
> Hari Bathini writes:
>> Make way for refactoring platform specific FADump code by moving code
>> that could be referenced from multiple places to fadump-common.c file.
>>
>> Signed-off-by: Hari Bathini
>> ---
>> arch/powerpc/kernel/Makefile
On Tue, Sep 03, 2019 at 04:28:09PM +0200, Christophe Leroy wrote:
> Le 03/09/2019 à 15:04, Segher Boessenkool a écrit :
> >On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> >>+ asm volatile(
> >>+ " mtctr %2;"
> >>+ " mtmsr %3;"
> >>+ "
On Tue, Sep 3, 2019 at 4:56 PM Daniel Axtens wrote:
>
> Provide the current number of vmalloc shadow pages in
> /sys/kernel/debug/kasan_vmalloc/shadow_pages.
Maybe it makes sense to put this into /sys/kernel/debug/kasan/
(without _vmalloc) and name e.g. vmalloc_shadow_pages? In case we want
to
Provide the current number of vmalloc shadow pages in
/sys/kernel/debug/kasan_vmalloc/shadow_pages.
Signed-off-by: Daniel Axtens
---
Merging this is probably overkill, but I leave it to the discretion
of the broader community.
On v4 (no dynamic freeing), I saw the following approximate
In the case where KASAN directly allocates memory to back vmalloc
space, don't map the early shadow page over it.
We prepopulate pgds/p4ds for the range that would otherwise be empty.
This is required to get it synced to hardware on boot, allowing the
lower levels of the page tables to be filled
Supporting VMAP_STACK with KASAN_VMALLOC is straightforward:
- clear the shadow region of vmapped stacks when swapping them in
- tweak Kconfig to allow VMAP_STACK to be turned on with KASAN
Reviewed-by: Dmitry Vyukov
Signed-off-by: Daniel Axtens
---
arch/Kconfig | 9 +
Test kasan vmalloc support by adding a new test to the module.
Signed-off-by: Daniel Axtens
--
v5: split out per Christophe Leroy
---
lib/test_kasan.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index
Hook into vmalloc and vmap, and dynamically allocate real shadow
memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different
Currently, vmalloc space is backed by the early shadow page. This
means that kasan is incompatible with VMAP_STACK.
This series provides a mechanism to back vmalloc space with real,
dynamically allocated memory. I have only wired up x86, because that's
the only currently supported arch I can work
On Tue, Sep 03, 2019 at 12:15:24PM +, Salil Mehta wrote:
> > From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of Peter
> > Zijlstra
> > On Tue, Sep 03, 2019 at 02:19:04PM +0800, Yunsheng Lin wrote:
> > > Is it possible that the node id set by device_add() become invalid
> > > if
Le 03/09/2019 à 15:04, Segher Boessenkool a écrit :
Hi!
On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
+#if !defined(CONFIG_PPC_8xx) & !defined(CONFIG_PPC64)
Please write that as &&? That is more usual, and
Hi!
> > + /* Begin with first registered wakeup source */
> > + ws = wakeup_source_get_start();
>
> Since I have mad some change in this version, could you please take a look on
> this.
> If it's OK to you, I would re-add 'Acked-by: Pavel Machek '
I'm sorry, I'm a bit busy at the moment
On 3/9/19 8:15 pm, Oliver O'Halloran wrote:
Support for switching CAPI cards into and out of CAPI mode was removed a
while ago. Drop the comment since it's no longer relevant.
Cc: Andrew Donnellan
Signed-off-by: Oliver O'Halloran
Oliver looked... unimpressed with the hackiness of the design
On Tue, 2019-09-03 at 15:30 +0200, Christoph Hellwig wrote:
> On Tue, Sep 03, 2019 at 09:29:14AM -0400, Qian Cai wrote:
> > I saw Christ start to remove npu-dma.c code [1]
> >
> > [1] https://lore.kernel.org/linuxppc-dev/20190625145239.2759-4-...@lst.de/
> >
> > Should pnv_npu_dma_set_32() be
On Tue, Sep 03, 2019 at 09:29:14AM -0400, Qian Cai wrote:
> I saw Christ start to remove npu-dma.c code [1]
>
> [1] https://lore.kernel.org/linuxppc-dev/20190625145239.2759-4-...@lst.de/
>
> Should pnv_npu_dma_set_32() be removed too?
>
> It was only called by pnv_npu_try_dma_set_bypass() but
I saw Christ start to remove npu-dma.c code [1]
[1] https://lore.kernel.org/linuxppc-dev/20190625145239.2759-4-...@lst.de/
Should pnv_npu_dma_set_32() be removed too?
It was only called by pnv_npu_try_dma_set_bypass() but the later is not used
anywhere in the kernel tree. If that is a case, I
Hi!
On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> +#if !defined(CONFIG_PPC_8xx) & !defined(CONFIG_PPC64)
Please write that as &&? That is more usual, and thus, easier to read.
> +static void
With commit: 22a61c3c4f13 ("asm-generic/tlb: Track freeing of page-table
directories in struct mmu_gather") we now track whether we freed page
table in mmu_gather. Use that to decide whether to flush Page Walk Cache.
Signed-off-by: Aneesh Kumar K.V
---
With the previous patch, we should now not be using need_flush_all for powerpc.
But then make sure we force a PID tlbie flush with RIC=2 if we ever
find need_flush_all set. Also don't reset it after a mmu gather flush
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_tlb.c | 3
mm_tlb_flush_nested change was added in the mmu gather tlb flush to handle
the case of parallel pte invalidate happening with mmap_sem held in read
mode. This fix was done by commit: 02390f66bd23 ("powerpc/64s/radix: Fix
MADV_[FREE|DONTNEED] TLB flush miss problem with THP") and the problem is
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
> P9 box running mainline kernel 5.3.0-rc5
>
> BUG_ON was first introduced by below commit
Well, technically the bug_on was there already
Right now we force an unbind of SCM memory at drcindex on H_OVERLAP error.
This really slows down operations like kexec where we get the H_OVERLAP
error because we don't go through a full hypervisor re init.
H_OVERLAP error for a H_SCM_BIND_MEM hcall indicates that SCM memory at
drc index is
This simplifies the error handling and also enable us to switch to
H_SCM_QUERY hcall in a later patch on H_OVERLAP error.
We also do some kernel print formatting fixup in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/pseries/papr_scm.c | 26 ++-
1
> From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of Peter
> Zijlstra
> Sent: Tuesday, September 3, 2019 8:11 AM
>
> On Tue, Sep 03, 2019 at 02:19:04PM +0800, Yunsheng Lin wrote:
> > On 2019/9/2 20:56, Peter Zijlstra wrote:
> > > On Mon, Sep 02, 2019 at 08:25:24PM +0800, Yunsheng
Michael Neuling writes:
> From: Gustavo Romero
>
> Add TM selftest to check if FP or VEC register values from one process
> can leak into another process when both run on the same CPU.
>
> This tests for CVE-2019-15030 and CVE-2019-15031.
>
> Signed-off-by: Gustavo Romero
> Signed-off-by:
Christophe Leroy writes:
> Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
>> From: Alastair D'Silva
>>
>> Similar to commit 22e9c88d486a
>> ("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
>> this patch converts the following ASM symbols to C:
>> flush_icache_range()
>>
/Anshuman-Khandual/mm-debug-Add-tests-for-architecture-exported-page-table-helpers/20190903-162959
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin
Hari Bathini writes:
> Add basic callback functions for FADump on PowerNV platform.
I assume this doesn't actually work yet?
Does something block it from appearing to work at runtime?
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d8dcd88..fc4ecfe 100644
> ---
Hari Bathini writes:
> diff --git a/arch/powerpc/include/asm/opal-api.h
> b/arch/powerpc/include/asm/opal-api.h
> index 383242e..c8a5665 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -980,6 +983,50 @@ struct opal_sg_list {
> };
>
> /*
> +
Hari Bathini writes:
> Except for reserve dump area which is permanent reserved, all memory
permanently
> above boot memory size is released when the dump is invalidated. Make
> this a bit more explicit in the code.
I'm not clear on what you mean by
Hari Bathini writes:
> Make RTAS calls to register and un-register for FADump. Also, update
> how fadump_region contents are diplayed to provide more information.
That sounds like two independent changes, so can this be split into two
patches?
cheers
Hari Bathini writes:
> Introduce callback functions for platform specific operations like
> register, unregister, invalidate & such. Also, define place-holders
> for the same on pSeries platform.
We already have an ops structure for machine specific calls, it's
ppc_md. Is there a good reason why
Hari Bathini writes:
> Though asm/fadump.h is meant to be used by other components dealing
> with FADump, it also has macros/definitions internal to FADump code.
> Move them to a new header file used within FADump code. This also
> makes way for refactoring platform specific FADump code.
>
>
Hari Bathini writes:
> Make way for refactoring platform specific FADump code by moving code
> that could be referenced from multiple places to fadump-common.c file.
>
> Signed-off-by: Hari Bathini
> ---
> arch/powerpc/kernel/Makefile|2
> arch/powerpc/kernel/fadump-common.c | 140
On 3.09.19 г. 11:55 ч., Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
> P9 box running mainline kernel 5.3.0-rc5
>
> BUG_ON was first introduced by below commit
>
> commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
> Author:
Use the new eeh_dev_check and eeh_dev_break interfaces to test EEH
recovery. Historically this has been done manually using platform specific
EEH error injection facilities (e.g. via RTAS). However, documentation on
how to use these facilities is haphazard at best and non-existent at worst
so
Add an interface to debugfs for generating an EEH event on a given device.
This works by disabling memory accesses to and from the device by setting
the PCI_COMMAND register (or the VF Memory Space Enable on the parent PF).
This is a somewhat portable alternative to using the platform specific
Detecting an frozen EEH PE usually occurs when an MMIO load returns a 0xFFs
response. When performing EEH testing using the EEH error injection feature
available on some platforms there is no simple way to kick-off the kernel's
recovery process since any accesses from userspace (usually /dev/mem)
I am the RAS team. Hear me roar.
Roar.
On a more serious note, being able to locate failed devices can be helpful.
Set the attention indicator if the slot supports it once we've determined
the device is present and only clear it if the device is fully recovered.
Signed-off-by: Oliver O'Halloran
pnv_php is generally used with PCIe bridges which provide a native
interface for setting the attention and power indicator LEDs. Wire up
those interfaces even if firmware does not have support for them (yet...)
Signed-off-by: Oliver O'Halloran
---
drivers/pci/hotplug/pnv_php.c | 14
Currently we check that an IODA2 compatible PHB is upstream of this slot.
This is mainly to avoid pnv_php creating slots for the various "virtual
PHBs" that we create for NVLink. There's no real need for this restriction
so allow it on IODA3.
Signed-off-by: Oliver O'Halloran
---
When performing EEH recovery of devices in a hotplug slot we need to use
the slot driver's ->reset_slot() callback to prevent spurious hotplug
events due to spurious DLActive and PresDet change interrupts. Add a
reset_slot() callback to pnv_php so we can handle recovery of devices
in pnv_php
When we reset PCI devices managed by a hotplug driver the reset may
generate spurious hotplug events that cause the PCI device we're resetting
to be torn down accidently. This is a problem for EEH (when the driver is
EEH aware) since we want to leave the OS PCI device state intact so that
the
Support for switching CAPI cards into and out of CAPI mode was removed a
while ago. Drop the comment since it's no longer relevant.
Cc: Andrew Donnellan
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
Currently we print a stack trace in the event handler to help with
debugging EEH issues. In the case of suprise hot-unplug this is unneeded,
so we want to prevent printing the stack trace unless we know it's due to
an actual device error. To accomplish this, we can save a stack trace at
the point
When a device is surprise removed while undergoing IO we will probably
get an EEH PE freeze due to MMIO timeouts and other errors. When a freeze
is detected we send a recovery event to the EEH worker thread which will
notify drivers, and perform recovery as needed.
In the event of a hot-remove we
If a device is torn down by a hotplug slot driver it's marked as removed
and marked as permaantly failed. There's no point in trying to recover a
permernantly failed device so it should be considered un-actionable.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/eeh_driver.c | 12
When hot-adding devices we rely on the hotplug driver to create pci_dn's
for the devices under the hotplug slot. Converse, when hot-removing the
driver will remove the pci_dn's that it created. This is a problem because
the pci_dev is still live until it's refcount drops to zero. This can
happen
When the last device in an eeh_pe is removed the eeh_pe structure itself
(and any empty parents) are freed since they are no longer needed. This
results in a crash when a hotplug driver is involved since the following
may occur:
1. Device is suprise removed.
2. Driver performs an MMIO, which
Fixes various random crashes and other bad behaviour when hot
pluggable slots are used with EEH, namely:
1) Random crashes due to eeh_pe and pci_dn lifecycle mis-management
2) Hotplug slots tearing down devices you are trying to recover due
to the reset that occurs while recovering a PE / bus.
Greeting's
Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
P9 box running mainline kernel 5.3.0-rc5
BUG_ON was first introduced by below commit
commit 00801ae4bb2be5f5af46502ef239ac5f4b536094
Author: David Sterba
Date: Thu May 2 16:53:47 2019 +0200
btrfs:
On 2019/9/3 15:11, Peter Zijlstra wrote:
> On Tue, Sep 03, 2019 at 02:19:04PM +0800, Yunsheng Lin wrote:
>> On 2019/9/2 20:56, Peter Zijlstra wrote:
>>> On Mon, Sep 02, 2019 at 08:25:24PM +0800, Yunsheng Lin wrote:
On 2019/9/2 15:25, Peter Zijlstra wrote:
> On Mon, Sep 02, 2019 at
This adds a test module which will validate architecture page table helpers
and accessors regarding compliance with generic MM semantics expectations.
This will help various architectures in validating changes to the existing
page table helpers or addition of new ones.
Test page table and memory
This series adds a test validation for architecture exported page table
helpers. Patch in the series adds basic transformation tests at various
levels of the page table.
This test was originally suggested by Catalin during arm64 THP migration
RFC discussion earlier. Going forward it can include
On Mon, Sep 02, 2019 at 08:17:31PM +0200, Ingo Molnar wrote:
> Nitpicking: please also fix the kernel message to say ">=".
Full patch below.
---
Subject: x86/mm: Fix cpumask_of_node() error condition
When CONFIG_DEBUG_PER_CPU_MAPS we validate that the @node argument of
cpumask_of_node() is a
Le 03/09/2019 à 08:25, Alastair D'Silva a écrit :
On Tue, 2019-09-03 at 08:19 +0200, Christophe Leroy wrote:
Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
From: Alastair D'Silva
When presented with large amounts of memory being hotplugged
(in my test case, ~890GB), the call to
On Tue, Sep 03, 2019 at 02:19:04PM +0800, Yunsheng Lin wrote:
> On 2019/9/2 20:56, Peter Zijlstra wrote:
> > On Mon, Sep 02, 2019 at 08:25:24PM +0800, Yunsheng Lin wrote:
> >> On 2019/9/2 15:25, Peter Zijlstra wrote:
> >>> On Mon, Sep 02, 2019 at 01:46:51PM +0800, Yunsheng Lin wrote:
> On
On Tue, 2019-09-03 at 08:23 +0200, Christophe Leroy wrote:
>
> Le 03/09/2019 à 07:24, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > This operation takes a significant amount of time when hotplugging
> > large amounts of memory (~50 seconds with 890GB of persistent
> > memory).
>
On Tue, 2019-09-03 at 08:19 +0200, Christophe Leroy wrote:
>
> Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > When presented with large amounts of memory being hotplugged
> > (in my test case, ~890GB), the call to flush_dcache_range takes
> > a while (~50
1 - 100 of 105 matches
Mail list logo
