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 2019
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 flush_d
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 va
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 mo
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 p
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 01:46:51
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: s
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.
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 fails
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 if
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 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
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 o
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 a/ar
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 devic
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 manage
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
---
arch/powerpc/pla
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 +
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
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) w
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
err
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 it's
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:
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
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.
>
> Signe
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:
> 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:
> 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 "boot
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:
> 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
> --- a/arch/powerpc
/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
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()
>>
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: Michae
> 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 Li
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 fi
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 alrea
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
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
expl
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 +
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
---
arch/powerpc/include/asm/book3s/64/pgalloc.
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 flush_dcache_icache_
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 do
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 th
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 rem
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
Hi!
> > + /* Begin with first registered wakeup source */
> > + ws = wakeup_source_get_start(&idx);
>
> 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 momen
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 t
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
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
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 mapp
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 49cc4d570a40..328d33b
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 +
kernel/fork.c
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 d
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 figures
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 ex
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;"
> >>+ " isync;
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 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 fo
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 machine
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
from
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 lost
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. Th
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 exp
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 bits
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 t
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
>> @@ -980
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 fo
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
effe
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 dele
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;"
+
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
> patc
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
invocation
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 s
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
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
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 providing
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 single
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 ++-
tools/testing/selftests/powerpc/copyloops/asm/expo
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 deletion
(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 th
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 loading
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. vmallo
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
#!
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 th
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 bash-e
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 prelimin
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
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 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 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 opport
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 transa
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
ha
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 +
tools/testing/selfte
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.
Sig
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 2
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
> r
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.
>
> Signed-off-
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 need
us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/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
On Wed, Sep 4, 2019 at 10:00 AM Masahiro Yamada
wrote:
>
> Hi Stephen,
>
> On Wed, Sep 4, 2019 at 9:13 AM Stephen Rothwell wrote:
> >
For today's linux-next, please squash the following too.
(This is my fault, since scripts/mkuboot.sh is a bash script)
diff --git a/scripts/Makefile.lib b/scri
1 - 100 of 101 matches
Mail list logo
