Hi Hillf,
Would you like to me to put you down as the author of this patch? If so, I'll
need a Signed-off-by from you.
David
---
commit df882ad6d4e24a3763719c1798ea58e87d56c2d7
Author: Hillf Danton
Date: Fri Aug 30 15:54:33 2019 +0100
keys: Fix missing null pointer check in request_key_a
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 27-08-19 15:20:46, Alastair D'Silva wrote:
> From: Alastair D'Silva
On Mon, Sep 02, 2019 at 01:46:51PM +0800, Yunsheng Lin wrote:
> On 2019/9/1 0:12, Peter Zijlstra wrote:
> > 1) because even it is not set, the device really does belong to a node.
> > It is impossible a device will have magic uniform access to memory when
> > CPUs cannot.
>
> So it means dev_to_n
On Fri, Aug 30, 2019 at 09:12:59AM +0530, Bharata B Rao wrote:
> On Thu, Aug 29, 2019 at 10:38:10AM +0200, Christoph Hellwig wrote:
> > On Thu, Aug 22, 2019 at 03:56:14PM +0530, Bharata B Rao wrote:
> > > +/*
> > > + * Bits 60:56 in the rmap entry will be used to identify the
> > > + * different us
On Mon, 02 Sep 2019 14:01:17 +1000
Michael Ellerman wrote:
> Michael Ellerman writes:
> > Michal Suchanek writes:
> ...
> >> @@ -295,6 +279,12 @@ static inline int current_is_64bit(void)
> >> }
> >>
> >> #else /* CONFIG_PPC64 */
> >> +static int read_user_stack_slow(void __user *ptr, voi
This reverts commit 6fbcdd59094ade30db63f32316e9502425d7b256.
Not needed. Data handled by raw_copy_in_user must be loaded through
copy_from_user to be used in the kernel which already has the barrier.
Signed-off-by: Michal Suchanek
---
arch/powerpc/include/asm/uaccess.h | 1 -
1 file changed,
On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> Stephen Rothwell writes:
> > Hi all,
> >
> > Today's linux-next merge of the powerpc tree got a conflict in:
> >
> > arch/Kconfig
> >
> > between commit:
> >
> > 5cf896fb6be3 ("arm64: Add support for relocating the kernel with
On Mon, 02 Sep 2019 12:03:12 +1000
Michael Ellerman wrote:
> Michal Suchanek writes:
> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
> > less so on littleendian.
>
> I think the toolchain people will tell you that there is no 32-bit
> little endian ABI defined at al
On Mon, Sep 02, 2019 at 10:08:46AM +0100, Catalin Marinas wrote:
> On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> > Stephen Rothwell writes:
> > > Hi all,
> > >
> > > Today's linux-next merge of the powerpc tree got a conflict in:
> > >
> > > arch/Kconfig
> > >
> > > between
Michal Suchánek writes:
> On Sat, 31 Aug 2019 02:48:26 +0800
> kbuild test robot wrote:
>
>> Hi Nicholas,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on linus/master]
>> [cannot apply to v5.3-rc6 next-20190830]
>> [if your patch is applied to the wrong git tr
Catalin Marinas writes:
> On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
>> Stephen Rothwell writes:
>> > Hi all,
>> >
>> > Today's linux-next merge of the powerpc tree got a conflict in:
>> >
>> > arch/Kconfig
>> >
>> > between commit:
>> >
>> > 5cf896fb6be3 ("arm64: Add s
On Mon, Sep 02, 2019 at 11:48:59AM +1000, Michael Ellerman wrote:
> "Alastair D'Silva" writes:
> > On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote:
> >> Can we be 100% sure that GCC won't add any code accessing some
> >> global data or stack while the Data MMU is OFF ?
> >
> > +mpe
> >
>
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
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
arch/powerpc/mm/dma-noncoherent.c: In function 'atomic_pool_init':
arch/powerpc/mm/dma-noncoherent.c:128:9: error: implicit declaration of
function 'dma_atomic_pool_init'; did you mean '
Hi Nayna,
Sorry I've taken so long to get to this series, there's just too many
patches that need reviewing :/
Nayna Jain writes:
> Secure boot on POWER defines different IMA policies based on the secure
> boot state of the system.
The terminology throughout is a bit vague, we have POWER, Power
Hi Nayna,
Some more comments below.
Nayna Jain writes:
> POWER secure boot relies on the kernel IMA security subsystem to
> perform the OS kernel image signature verification.
Again this is just a design choice we've made, it's not specified
anywhere or anything like that. And it only applies t
On Mon, Sep 02, 2019 at 09:40:11PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
Yes, this conflict is expected and we dicussed it before. I'll make
sure Linus is in the loop when sending the p
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 the keys/hashes from the firmware.
>
> This patch moves the common code from load_uefi.c to keyring_handler
On Mon, Sep 02, 2019 at 11:17:13AM +0800, Xiaowei Bao wrote:
> dw_pcie_ep_raise_msix_irq was never called in the exisitng driver
> before, because the ls1046a platform don't support the MSIX feature
> and msix_capable was always set to false.
> Now that add the ls1088a platform with MSIX support, b
>
> Hi Hillf,
>
> Would you like to me to put you down as the author of this patch? If so, I'll
> need a Signed-off-by from you.
>
Signed-off-by: Hillf Danton
On 2019/9/2 15:25, Peter Zijlstra wrote:
> On Mon, Sep 02, 2019 at 01:46:51PM +0800, Yunsheng Lin wrote:
>> On 2019/9/1 0:12, Peter Zijlstra wrote:
>
>>> 1) because even it is not set, the device really does belong to a node.
>>> It is impossible a device will have magic uniform access to memory w
On Mon, Sep 02, 2019 at 11:17:10AM +0800, Xiaowei Bao wrote:
> Add compatible strings for ls1088a and ls2088a.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - No change.
> v3:
> - Use one valid combination of compatible strings.
>
> Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4
On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> Add PCIe EP mode support for ls1088a and ls2088a, there are some
> difference between LS1 and LS2 platform, so refactor the code of
> the EP driver.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - This is a new patch for supporting t
On Mon, Sep 02, 2019 at 11:17:16AM +0800, Xiaowei Bao wrote:
> Add LS1088a in pci_device_id table so that pci-epf-test can be used
> for testing PCIe EP in LS1088a.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - No change.
> v3:
> - No change.
>
> drivers/misc/pci_endpoint_test.c | 1 +
> 1
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/9/1 0:12, Peter Zijlstra wrote:
> >
> >>> 1) because even it is not set, the device really does belong to a node.
On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote:
> Michal Suchanek writes:
> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
> > less so on littleendian.
>
> I think the toolchain people will tell you that there is no 32-bit
> little endian ABI defined at
On Mon, Sep 02, 2019 at 11:17:15AM +0800, Xiaowei Bao wrote:
> Add PCIe EP node for ls1088a to support EP mode.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - Remove the pf-offset proparty.
> v3:
> - No change.
>
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> ++
On Mon, Sep 02, 2019 at 09:20:24PM +1000, Daniel Axtens wrote:
> 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 mappin
On Fri, Aug 23, 2019 at 04:13:30AM +, Xiaowei Bao wrote:
>
>
> > -Original Message-
> > From: Kishon Vijay Abraham I
> > Sent: 2019年8月23日 11:40
> > To: Xiaowei Bao ; bhelg...@google.com;
> > robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> > ; lorenzo.pieral...
On Mon, Sep 02, 2019 at 11:17:12AM +0800, Xiaowei Bao wrote:
> The different PCIe controller in one board may be have different
> capability of MSI or MSIX, so change the way of getting the MSI
> capability, make it more flexible.
>
> Signed-off-by: Xiaowei Bao
Please see the comments I just mad
On 31. 07. 19 19:15, Mike Rapoport wrote:
> On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
>> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
>>> On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
I am sorry, but I still do not follow. Who is consuming that node i
Hi Mark,
>> +static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>> +void *unused)
>> +{
>> +unsigned long page;
>> +
>> +page = (unsigned long)__va(pte_pfn(*ptep) << PAGE_SHIFT);
>> +
>> +spin_lock(&init_mm.page_table_lock);
>>
On Tue, Sep 03, 2019 at 12:32:49AM +1000, Daniel Axtens wrote:
> Hi Mark,
>
> >> +static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
> >> + void *unused)
> >> +{
> >> + unsigned long page;
> >> +
> >> + page = (unsigned long)__va(pte_pfn(*pt
On Mon, Sep 02, 2019 at 11:17:09AM +0800, Xiaowei Bao wrote:
> Each PF of EP device should have it's own MSI or MSIX capabitily
> struct, so create a dw_pcie_ep_func struct and remover the msi_cap
remover?
> and msix_cap to this struce, and manage the PFs with a list.
struce?
>
> Signed-off-by
From: Yunsheng Lin
Date: Mon, 2 Sep 2019 14:08:31 +0800
> The NUMA node id in sparc64 system is defined by DT semantics?
Sometimes, and in other cases other methods are used to determine
the NUMA node id.
On Mon, Sep 02, 2019 at 03:51:25PM +0200, Michal Simek wrote:
> On 31. 07. 19 19:15, Mike Rapoport wrote:
> > On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
> >> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
> >>> On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
>
There should be no functional changes.
- Use calls to existing radix_tlb.c functions in flush_partition.
- Rename radix__flush_tlb_lpid to radix__flush_all_lpid and similar,
because they flush everything, matching flush_all_mm rather than
flush_tlb_mm for the lpid.
- Remove some unused radix
This callback is only required because the partition table init comes
before process table allocation on powernv (aka bare metal aka native).
Change the order to allocate the process table first, and remove the
callback.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/mmu.
No functional change.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/mmu.h | 2 +-
arch/powerpc/kvm/book3s_hv_nested.c | 2 +-
arch/powerpc/mm/book3s64/hash_utils.c| 2 +-
arch/powerpc/mm/book3s64/pgtable.c | 4 ++--
arch/powerpc/mm/book3s64/radix_pgtable.c
Radix guests are responsible for managing their own translation caches,
so make them match bare metal radix and hash, and make each CPU flush
all its translations right before enabling its MMU.
Radix guests may not flush partition scope translations, so in
tlbiel_all, make these flushes conditiona
The various translation structure invalidations performed in early boot
when the MMU is off are not required, because everything is invalidated
immediately before a CPU first enables its MMU (see early_init_mmu
and early_init_mmu_secondary).
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/boo
This is a rebase of the series against the the powerpc next branch
with ultravisor changes. Main improvements are implementing and
splitting out the precursor patches better.
KVM still requires tlbie to run radix guests. A naive implementation
of tlbiel + IPI for LPID flushes was crashing so requi
Introduce two options to control the use of the tlbie instruction. A
boot time option which completely disables the kernel using the
instruction, this is currently incompatible with HASH MMU, KVM, and
coherent accelerators.
And a debugfs option can be switched at runtime and avoids using tlbie
for
On Mon, Sep 02, 2019 at 11:17:06AM +0800, Xiaowei Bao wrote:
> Add multiple PFs support for DWC, different PF have different config space
> we use pf-offset property which get from the DTS to access the different pF
This needs to be updated as this no longer comes from the DT.
> config space.
>
* Peter Zijlstra wrote:
> Also note that the CONFIG_DEBUG_PER_CPU_MAPS version of
> cpumask_of_node() already does this (although it wants the below fix).
>
> ---
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index e6dad600614c..5f49c10201c7 100644
> --- a/arch/x86/mm/numa.c
> +++ b
* 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/9/1 0:12, Peter Zijlstra wrote:
> > >
> > >>> 1) because even it is not set, t
On Mon, Sep 02, 2019 at 08:22:52PM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index f0dd8e38fee3..2caf204966a0 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -2120,8 +2120,16 @@ int device_add(st
System call entry and particularly exit code is beyond the limit of what
is reasonable to implement in asm.
This conversion moves all conditional branches out of the asm code,
except for the case that all GPRs should be restored at exit.
Null syscall test is about 5% faster after this patch, beca
Michal Suchánek writes:
> On Mon, 02 Sep 2019 14:01:17 +1000
> Michael Ellerman wrote:
>> Michael Ellerman writes:
>> > Michal Suchanek writes:
>> ...
>> >> @@ -295,6 +279,12 @@ static inline int current_is_64bit(void)
>> >> }
>> >>
>> >> #else /* CONFIG_PPC64 */
>> >> +static int read_u
Segher Boessenkool writes:
> On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote:
>> Michal Suchanek writes:
>> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
>> > less so on littleendian.
>>
>> I think the toolchain people will tell you that there is no 32
Michal Suchánek writes:
> On Mon, 02 Sep 2019 12:03:12 +1000
> Michael Ellerman wrote:
>
>> Michal Suchanek writes:
>> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
>> > less so on littleendian.
>>
>> I think the toolchain people will tell you that there is no 32-bi
Nick,
On Tuesday, 3 September 2019 1:29:31 AM AEST Nicholas Piggin wrote:
> Introduce two options to control the use of the tlbie instruction. A
> boot time option which completely disables the kernel using the
> instruction, this is currently incompatible with HASH MMU, KVM, and
> coherent accele
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 20:32
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 20:46
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 20:55
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 21:06
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 21:37
> To: Xiaowei Bao
> Cc: Kishon Vijay Abraham I ; bhelg...@google.com;
> robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.co
> ; a...@arndb.de; gre...@linuxfoundation.org;
>
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 21:38
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月2日 23:07
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...
Alistair Popple's on September 3, 2019 10:32 am:
> Nick,
>
> On Tuesday, 3 September 2019 1:29:31 AM AEST Nicholas Piggin wrote:
>> Introduce two options to control the use of the tlbie instruction. A
>> boot time option which completely disables the kernel using the
>> instruction, this is curren
Greg Kroah-Hartman writes:
> This variant was missing from sysfs.h, I guess no one noticed it before.
>
> Turns out the powerpc secure variable code can use it, so add it to the
> tree for it, and potentially others to take advantage of, instead of
> open-coding it.
>
> Reported-by: Nayna Jain
>
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月3日 0:26
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@
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: Michael Neuling
---
tools/testing/selftests/
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
On 09/02/2019 11:53 PM, Michael Ellerman wrote:
Segher Boessenkool writes:
On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote:
Michal Suchanek writes:
On bigendian ppc64 it is common to have 32bit legacy binaries but much
less so on littleendian.
I think the toolchain peop
From: Alastair D'Silva
This series addresses a few issues discovered in how we flush caches:
1. Flushes were truncated at 4GB, so larger flushes were incorrect.
2. Flushing the dcache in arch_add_memory was unnecessary
This series also converts much of the cache assembler to C, with the
aim of m
From: Alastair D'Silva
When calling flush_icache_range with a size >4GB, we were masking
off the upper 32 bits, so we would incorrectly flush a range smaller
than intended.
This patch replaces the 32 bit shifts with 64 bit ones, so that
the full size is accounted for.
Signed-off-by: Alastair D'
From: Alastair D'Silva
This patch adds helpers to retrieve icache sizes, and renames the existing
helpers to make it clear that they are for dcache.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cache.h | 29 +++
arch/powerpc/include/asm/cacheflush.h
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()
__flush_dcache_icache()
__flush_dcache_icache_phys()
This was done as we discovered a long-sta
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 seconds), triggering RCU stalls.
This patch breaks up the call into 1GB chunks, calling
cond_resched() inbetween to allow the scheduler
From: Alastair D'Silva
The 'extern' keyword does not value-add for function prototypes.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cache.h | 8
arch/powerpc/include/asm/cacheflush.h | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/
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).
This was orignally in commit fb5924fddf9e
("powerpc/mm: Flush cache on memory hot(un)plug") to support memtrace,
but the flush on add i
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 our own setjmp implementation, meaning clang should not
> > be trying to do an
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()
__flush_dcache_icache()
__flush_dcach
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 seconds), triggering RCU stalls.
This patch breaks up the call into 1GB chunks,
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/9/1 0:12, Peter Zijlstra wrote:
>>>
> 1) because even it is not set
Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
From: Alastair D'Silva
The 'extern' keyword does not value-add for function prototypes.
Is it worth it ? That kind of change is nice cleanup but the drawback is
to kill automatic backports of fixes.
Signed-off-by: Alastair D'Silva
---
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).
This was orignally in commit fb5924fddf9e
("powerpc/mm: Flush cache on memory ho
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 se
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).
>
86 matches
Mail list logo
