Re: [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL

On 03/26/2018 08:39 PM, Nicholas Piggin wrote: xmon can be entered via sreset NMI (from a management sreset, or an NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc or sp are within OPAL memory, and if so, then use OPAL_DEBUG to print the opal stack and return the Linux stack,

[PATCH v13 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the

Re: RFC on writel and writel_relaxed

[+ locking/ordering/docs people] On Tue, Mar 27, 2018 at 07:56:59PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote: > > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: > > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote: > On 03/26/2018 01:28 PM, Joe Perches wrote: > > drivers/hwmon is the most frequent user of symbolic permissions > > like S_IRUGO in the kernel tree. [] > I have something similar using coccinelle, Please post the script. I expect it doesn't

Re: [PATCH v3 3/6] powerpc/kexec: Disable ftrace before switching to the new kernel

Michael Ellerman wrote: Michael Ellerman writes: "Naveen N. Rao" writes: If function_graph tracer is enabled during kexec, we see the below exception in the simulator: root@(none):/# kexec -e kvm: exiting hardware

Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

On 03/26/2018 08:32 PM, Nicholas Piggin wrote: opal_nvram_write currently just assumes success if it encounters an error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO on other errors instead. Signed-off-by: Nicholas Piggin ---

Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

On Tue, 27 Mar 2018 12:47:31 +0530 Vasant Hegde wrote: > On 03/26/2018 08:32 PM, Nicholas Piggin wrote: > > opal_nvram_write currently just assumes success if it encounters an > > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO > > on other

[bug report] powerpc/4xx: Adding PCIe MSI support

[ This is really really ancient code. - dan ] Hello Rupjyoti Sarmah, The patch 3fb7933850fa: "powerpc/4xx: Adding PCIe MSI support" from Mar 29, 2011, leads to the following static checker warning: arch/powerpc/platforms/4xx/msi.c:100 ppc4xx_setup_msi_irqs() warn: 'int_no >= 0'

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote: > Since the hwmon subsystem has been labeled as both "obsolete" and "obscure", fyi: It's marked Maintained in MAINTAINERS HARDWARE MONITORING M: Jean Delvare M: Guenter Roeck L:

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe wrote: > Mathieu Malaterre a écrit : > > >> On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy >> wrote: >>> >>> >>> >>> Le 22/03/2018 à 21:20, Mathieu Malaterre a

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Mon 26-03-18 22:45:31, Ilya Smith wrote: > > > On 26 Mar 2018, at 11:46, Michal Hocko wrote: > > > > On Fri 23-03-18 20:55:49, Ilya Smith wrote: > >> > >>> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote: > >>> > >>> On Thu, Mar 22, 2018 at

[PATCH v13 2/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

Currently only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient for x86. PowerPC supports 32 keys, which needs 5bits. This patch allocates an additional bit. cc: Dave Hansen cc: Michael Ellermen cc: Benjamin Herrenschmidt

Re: [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL

On Tue, 27 Mar 2018 12:42:32 +0530 Vasant Hegde wrote: > On 03/26/2018 08:39 PM, Nicholas Piggin wrote: > > xmon can be entered via sreset NMI (from a management sreset, or an > > NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc > > or sp are

Re: [PATCH 01/10] powerpc: Add security feature flags for Spectre/Meltdown

/commits/Michael-Ellerman/powerpc-Add-security-feature-flags-for-Spectre-Meltdown/20180327-041008 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: powerpc-g5_defconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 11:44:22AM +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 10:56 AM, Benjamin Herrenschmidt > wrote: > > On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote: > >> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: >

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: >> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > > I even see patches adding wmb() based on actual observed memory > corruption during testing

Re: [PATCH 17/21] powerpc: Add missing prototype for sys_debug_setcontext

Hi Mathieu, Mathieu Malaterre writes: > On Thu, Mar 8, 2018 at 11:36 AM, Michael Ellerman wrote: >> Mathieu Malaterre writes: >>> On Sun, Mar 4, 2018 at 11:54 AM, Michael Ellerman >>> wrote: Mathieu Malaterre

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 10:56 AM, Benjamin Herrenschmidt wrote: > On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote: >> On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: >> >> I'm pretty sure I've never seen >> any bug reports pointing to a

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > > > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > > > > I even see patches

[PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

This patch series provides arch-neutral enhancements to enable memory-keys on new architecutes, and the corresponding changes in x86 and powerpc specific code to support that. a) Provides ability to support upto 32 keys. PowerPC can handle 32 keys and hence needs this. b) Arch-neutral

[PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is enabled. Powerpc also needs these bits. Hence lets define the VM_PKEY_BITx bits for any architecture that enables CONFIG_ARCH_HAS_PKEYS. cc: Michael Ellermen cc: Benjamin Herrenschmidt

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > >> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > > > > I even see patches

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On 03/26/2018 01:28 PM, Joe Perches wrote: drivers/hwmon is the most frequent user of symbolic permissions like S_IRUGO in the kernel tree. $ git grep -w -P "S_[A-Z]{5,5}" | \ cut -f1 -d: | cut -f1-2 -d"/" | sed -r 's/[A-Za-z0-9_-]+\.[ch]$//' | \ sort | uniq -c | sort -rn | head 3862

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 11:57 AM, Will Deacon wrote: > > From db0daeaf94f0f6232f8206fc07a74211324b11d9 Mon Sep 17 00:00:00 2001 > From: Will Deacon > Date: Tue, 27 Mar 2018 10:49:58 +0100 > Subject: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 11:57 AM, Will Deacon wrote: > > > > > From db0daeaf94f0f6232f8206fc07a74211324b11d9 Mon Sep 17 00:00:00 2001 > > From: Will Deacon > > Date: Tue, 27 Mar 2018

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 10:20:02PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2018-03-27 at 10:42 +0100, Will Deacon wrote: > > > > > > This example adds a wmb() between two writes to a coherent DMA > > > area, it is definitely required there. I'm pretty sure I've never seen > > > any bug

[PATCH v2 03/10] powerpc/pseries: Set or clear security feature flags

Now that we have feature flags for security related things, set or clear them based on what we receive from the hypercall. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/pseries/setup.c | 43 ++ 1 file changed, 43 insertions(+)

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On 03/27/2018 12:35 AM, Joe Perches wrote: On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote: Since the hwmon subsystem has been labeled as both "obsolete" and "obscure", fyi: It's marked Maintained in MAINTAINERS I did not say that it was not maintained, and I am aware of the

[PATCH v2 01/10] powerpc: Add security feature flags for Spectre/Meltdown

This commit adds security feature flags to reflect the settings we receive from firmware regarding Spectre/Meltdown mitigations. The feature names reflect the names we are given by firmware on bare metal machines. See the hostboot source for details. Arguably these could be firmware features,

Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

On Tue, 27 Mar 2018 23:13:00 +1100 Michael Ellerman wrote: > Nicholas Piggin writes: > > > opal_nvram_write currently just assumes success if it encounters an > > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO > > on other errors

Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync()

On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote: > kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI. > If CPU is in extended quiescent state (idle task or nohz_full userspace), this > work may be done at the exit of this state. Delaying synchronization helps

[PATCH v2 06/10] powerpc/64s: Enhance the information in cpu_show_meltdown()

Now that we have the security feature flags we can make the information displayed in the "meltdown" file more informative. Signed-off-by: Michael Ellerman --- arch/powerpc/include/asm/security_features.h | 1 + arch/powerpc/kernel/security.c | 30

[PATCH v2 07/10] powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()

Now that we have the security flags we can significantly simplify the code in pnv_setup_rfi_flush(), because we can use the flags instead of checking device tree properties and because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman ---

Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

Nicholas Piggin writes: > opal_nvram_write currently just assumes success if it encounters an > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO > on other errors instead. Does that ever happen with current skiboot? Even if it doesn't I think I'm inclined

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 10:42 +0100, Will Deacon wrote: > > > > This example adds a wmb() between two writes to a coherent DMA > > area, it is definitely required there. I'm pretty sure I've never seen > > any bug reports pointing to a missing wmb() between memory > > and MMIO write accesses, but

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 12:02 +0100, Will Deacon wrote: > can see it now has ownership. Note that, when using writel(), a prior > > wmb() is not needed to guarantee that the cache coherent memory writes > > have completed before writing to the cache incoherent MMIO region. > >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 10:57 +0100, Will Deacon wrote: > > > > The interesting thing is that we do seem to have a whole LOT of these > > spurrious wmb before writel all over the tree, I suspect because of > > that incorrect recommendation in memory-barriers.txt. > > > > We should fix that. > >

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 12:09 PM, Will Deacon wrote: > On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote: >> > - >> > - See Documentation/DMA-API.txt for more information on consistent >> > memory. >> > + can see it now has ownership. Note that, when

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 12:53:49PM +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 12:09 PM, Will Deacon wrote: > > On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote: > >> > - > >> > - See Documentation/DMA-API.txt for more information on consistent >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote: > > The interesting thing is that we do seem to have a whole LOT of these > > spurrious wmb before writel all over the tree, I suspect because of > > that incorrect recommendation in memory-barriers.txt. > > > > We should fix that. > >

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote: > On 03/27/2018 12:35 AM, Joe Perches wrote: > > On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote: > > > Since the hwmon subsystem has been labeled as both "obsolete" and > > > "obscure", > > > > fyi: It's marked Maintained in

[PATCH v2 02/10] powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags

Add some additional values which have been defined for the H_GET_CPU_CHARACTERISTICS hypercall. Signed-off-by: Michael Ellerman --- arch/powerpc/include/asm/hvcall.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/include/asm/hvcall.h

[PATCH v2 08/10] powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()

Now that we have the security flags we can simplify the code in pseries_setup_rfi_flush() because the security flags have pessimistic defaults. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/pseries/setup.c | 27 --- 1 file changed, 12

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 1:02 PM, Will Deacon wrote: > On Tue, Mar 27, 2018 at 12:53:49PM +0200, Arnd Bergmann wrote: >> On Tue, Mar 27, 2018 at 12:09 PM, Will Deacon wrote: >> > On Tue, Mar 27, 2018 at 12:05:06PM +0200, Arnd Bergmann wrote: > diff --git

[PATCH v2 04/10] powerpc/powernv: Set or clear security feature flags

Now that we have feature flags for security related things, set or clear them based on what we see in the device tree provided by firmware. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/powernv/setup.c | 56 ++ 1 file changed, 56

[PATCH v2 05/10] powerpc/64s: Move cpu_show_meltdown()

This landed in setup_64.c for no good reason other than we had nowhere else to put it. Now that we have a security-related file, that is a better place for it so move it. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/security.c | 11 +++

[PATCH v2 09/10] powerpc/64s: Wire up cpu_show_spectre_v1()

Add a definition for cpu_show_spectre_v1() to override the generic version. Currently this just prints "Not affected" or "Vulnerable" based on the firmware flag. Although the kernel does have array_index_nospec() in a few places, we haven't yet audited all the powerpc code to see where it's

RE: RFC on writel and writel_relaxed

> Fair enough. I'd rather people used _relaxed by default, but I have to admit > that it will probably just result in them getting things wrong... Certainly requiring the driver writes use explicit barriers should make them understand when and why they are needed - and then put in the correct

[PATCH v2 10/10] powerpc/64s: Wire up cpu_show_spectre_v2()

Add a definition for cpu_show_spectre_v2() to override the generic version. This has several permuations, though in practice some may not occur we cater for any combination. The most verbose is: Mitigation: Indirect branch serialisation (kernel only), Indirect branch cache disabled, ori31

Re: RFC on writel and writel_relaxed

On 2018-03-27 07:23, Benjamin Herrenschmidt wrote: On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote: > The interesting thing is that we do seem to have a whole LOT of these > spurrious wmb before writel all over the tree, I suspect because of > that incorrect recommendation in

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 3:03 PM, Benjamin Herrenschmidt wrote: > > The discussion at hand is about > > dma_buffer->foo = 1;/* WB */ > writel(KICK, DMA_KICK_REGISTER);/* UC */ Yes. That certainly is ordered on x86. In fact,

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On 03/23/2018 02:06 PM, Matthew Wilcox wrote: > On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote: >> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote: >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote: Current implementation doesn't randomize address

Re: [PATCH] powerpc/powernv: Fix sparse data type warnings in pci-ioda.c

Paul Mackerras writes: > From: Gavin Shan > > The value passed to __raw_rm_writeq() and __raw_writeq() should be "u64" > and "unsigned long". This fixes warning reported by sparse: > > gwshan@gwshan:~/sandbox/l$ make C=2 CF=-D__CHECK_ENDIAN__ \ >

Re: [PATCH] powerpc: Clear branch trap (MSR.BE) before delivering SIGTRAP

Matt Evans writes: > When using SIG_DBG_BRANCH_TRACING, MSR.BE is left enabled in the > user context when single_step_exception() prepares the SIGTRAP > delivery. The resulting branch-trap-within-the-SIGTRAP-handler > isn't healthy. > > Commit

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 16:51 -1000, Linus Torvalds wrote: > On Tue, Mar 27, 2018 at 3:03 PM, Benjamin Herrenschmidt > wrote: > > > > The discussion at hand is about > > > > dma_buffer->foo = 1;/* WB */ > > writel(KICK,

Re: RFC on writel and writel_relaxed

On 3/27/2018 10:51 PM, Linus Torvalds wrote: >> The discussion at hand is about >> >> dma_buffer->foo = 1;/* WB */ >> writel(KICK, DMA_KICK_REGISTER);/* UC */ > Yes. That certainly is ordered on x86. In fact, afaik it's ordered > even if that writel()

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 23:24 -0400, Sinan Kaya wrote: > On 3/27/2018 10:51 PM, Linus Torvalds wrote: > > > The discussion at hand is about > > > > > > dma_buffer->foo = 1;/* WB */ > > > writel(KICK, DMA_KICK_REGISTER);/* UC */ > > > > Yes. That

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote: > > /dev/[u]random is not sufficient? > > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a > performance > issue. You may want to take a look at the getrandom(2) system call, which is the recommended way getting

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote: > On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote: > > > /dev/[u]random is not sufficient? > > > > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a > > performance > > issue. > > You may want to

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: >> I agree: pushing this off to libc leaves a lot of things unprotected. >> I think this should live in the kernel. The question I have is about >> making it

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 14:54 -0700, Alexander Duyck wrote: > On Tue, Mar 27, 2018 at 2:35 PM, Benjamin Herrenschmidt > wrote: > > On Tue, 2018-03-27 at 10:46 -0400, Sinan Kaya wrote: > > > combined buffers. > > > > > > Alex: > > > "Don't bother. I can tell you right now

[PATCH v2 5/5] powerpc/mm/32: Remove the reserved memory hack

This hack, introduced in commit c5df7f775148 ("powerpc: allow ioremap within reserved memory regions") is now unnecessary. Signed-off-by: Jonathan Neuschäfer --- v2: no changes --- arch/powerpc/mm/init_32.c| 5 - arch/powerpc/mm/mmu_decl.h | 1 -

Re: [PATCH] powerpc/powernv: Fix sparse data type warnings in pci-ioda.c

On 28/3/18 11:44 am, Paul Mackerras wrote: > From: Gavin Shan > > The value passed to __raw_rm_writeq() and __raw_writeq() should be "u64" > and "unsigned long". This fixes warning reported by sparse: > > gwshan@gwshan:~/sandbox/l$ make C=2 CF=-D__CHECK_ENDIAN__ \ >

Re: RFC on writel and writel_relaxed

On 3/27/2018 5:54 PM, Alexander Duyck wrote: > I view the wmb() + writel_relaxed() as more of a driver owning and > handling this itself. Besides in the Intel Ethernet driver case it is > better performance as our wmb() placement for us also provides a > secondary barrier so we don't need to add a

[PATCH v2 1/5] powerpc: mm: Simplify page_is_ram by using memblock_is_memory

Instead of open-coding the search in page_is_ram, call memblock_is_memory. Signed-off-by: Jonathan Neuschäfer --- v2: no changes --- arch/powerpc/mm/mem.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/powerpc/mm/mem.c

[PATCH] powerpc/powernv: Fix sparse data type warnings in pci-ioda.c

From: Gavin Shan The value passed to __raw_rm_writeq() and __raw_writeq() should be "u64" and "unsigned long". This fixes warning reported by sparse: gwshan@gwshan:~/sandbox/l$ make C=2 CF=-D__CHECK_ENDIAN__ \

[PATCH v2 4/5] powerpc: wii: Don't rely on the reserved memory hack

Because the two memory blocks (usually called MEM1 and MEM2) are not merged anymore, __request_region in kernel/resource.c will correctly allow reserving regions in the physical address space between MEM1 and MEM2, where many important peripherals are (GPIO, MMC, USB, ...). A previous change to

[PATCH] powerpc/mm: Fix printing of process table address

New changes to %p cause the information printed at boot about radix-mmu partition and process table opaque, if we really want to protect those values, we should make dmesg more secure using CONFIG_SECURITY_DMESG_RESTRICT Before the patches: radix-mmu: Partition table (ptrval) radix-mmu:

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: > I agree: pushing this off to libc leaves a lot of things unprotected. > I think this should live in the kernel. The question I have is about > making it maintainable/readable/etc. > > The state-of-the-art for ASLR is moving to finer

[PATCH v2 3/5] powerpc/mm/32: Use page_is_ram to check for RAM

On systems where there is MMIO space between different blocks of RAM in the physical address space, __ioremap_caller did not allow mapping these MMIO areas, because they were below the end RAM and thus considered RAM as well. Use the memblock-based page_is_ram function, which returns false for

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 16:10 +0100, Will Deacon wrote: > To clarify: are you saying that on x86 you need a wmb() prior to a writel > if you want that writel to be ordered after prior writes to memory? Is this > specific to WC memory or some other non-standard attribute? > > The only reason we have

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 6:51 AM, Ilya Smith wrote: > >> On 27 Mar 2018, at 10:24, Michal Hocko wrote: >> >> On Mon 26-03-18 22:45:31, Ilya Smith wrote: >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote: On Fri 23-03-18

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 11:33 AM, Benjamin Herrenschmidt wrote: > > Well, we need to clarify that once and for all, because as I wrote > earlier, it was decreed by Linus more than a decade ago that writel > would be fully ordered by itself vs. previous memory stores (at

[PATCH v2 0/5] PPC32/ioremap: Use memblock API to check for RAM

v1: https://www.spinics.net/lists/linux-mm/msg145939.html This patchset makes it possible to allocate MMIO ranges that are between the two RAM chunks on the Wii, MEM1 and MEM2, not only with ioremap (which previously worked through a hack) but also with kernel/resource.c. Changes in v2: - I

[PATCH v2 2/5] powerpc: mm: Use memblock API for PPC32 page_is_ram

To support accurate checking for different blocks of memory on PPC32, use the same memblock-based approach that's already used on PPC64 also on PPC32. Signed-off-by: Jonathan Neuschäfer --- v2: no changes --- arch/powerpc/mm/mem.c | 4 1 file changed, 4 deletions(-)

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 14:39 -1000, Linus Torvalds wrote: > On Tue, Mar 27, 2018 at 11:33 AM, Benjamin Herrenschmidt > wrote: > > > > Well, we need to clarify that once and for all, because as I wrote > > earlier, it was decreed by Linus more than a decade ago that

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote: > > I agree: pushing this off to libc leaves a lot of things unprotected. > > I think this should live in the kernel. The question I have is about > > making it

Re: RFC on writel and writel_relaxed

On 3/27/2018 7:02 AM, Will Deacon wrote: > - See Documentation/DMA-API.txt for more information on consistent memory. > + can see it now has ownership. Note that, when using writel(), a prior > + wmb() is not needed to guarantee that the cache coherent memory writes > + have

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 10:42:00AM +0100, Will Deacon wrote: > On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote: > > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: > > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > > >> On Mon,

Re: [PATCH 6/6] doc/devicetree: NVDIMM region documentation

On Tue, Mar 27, 2018 at 9:24 AM, Rob Herring wrote: > On Fri, Mar 23, 2018 at 07:12:09PM +1100, Oliver O'Halloran wrote: >> Add device-tree binding documentation for the nvdimm region driver. >> >> Cc: devicet...@vger.kernel.org >> Signed-off-by: Oliver O'Halloran

Re: RFC on writel and writel_relaxed

Hi Alex, On Tue, Mar 27, 2018 at 10:46:58AM -0400, Sinan Kaya wrote: > +netdev, +Alex > > On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote: > >> Most of the drivers have a unwound loop with writeq() or something to > >>> do it. > >>

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 08:22:55AM -0400, ok...@codeaurora.org wrote: > On 2018-03-27 07:23, Benjamin Herrenschmidt wrote: > >On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote: > >>> The interesting thing is that we do seem to have a whole LOT of these > >>> spurrious wmb before writel all

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 09:46:51AM -0400, Sinan Kaya wrote: > On 3/27/2018 7:02 AM, Will Deacon wrote: > > - See Documentation/DMA-API.txt for more information on consistent > > memory. > > + can see it now has ownership. Note that, when using writel(), a prior > > + wmb() is not

Re: [PATCH] powerpc/64: Fix checksum folding in csum_add

Shile Zhang a écrit : fix the missed point in Paul's patch: "powerpc/64: Fix checksum folding in csum_tcpudp_nofold and ip_fast_csum_nofold" Signed-off-by: Shile Zhang --- arch/powerpc/include/asm/checksum.h | 2 +- 1 file changed, 1

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On 03/27/2018 04:48 AM, Joe Perches wrote: On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote: On 03/27/2018 12:35 AM, Joe Perches wrote: On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote: Since the hwmon subsystem has been labeled as both "obsolete" and "obscure", fyi: It's marked

Re: [PATCH v2 01/10] powerpc: Add security feature flags for Spectre/Meltdown

On Tue, Mar 27, 2018 at 11:01:44PM +1100, Michael Ellerman wrote: > This commit adds security feature flags to reflect the settings we > receive from firmware regarding Spectre/Meltdown mitigations. > > The feature names reflect the names we are given by firmware on bare > metal machines. See the

Re: RFC on writel and writel_relaxed

On Tue, Mar 27, 2018 at 09:56:47AM +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe wrote: > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > >> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > > > > I even see patches

Re: RFC on writel and writel_relaxed

+netdev, +Alex On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote: > On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote: >> Most of the drivers have a unwound loop with writeq() or something to >>> do it. >> >> But isn't the writeq() barrier much more expensive than anything you'd >> do in

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Tue 27-03-18 16:51:08, Ilya Smith wrote: > > > On 27 Mar 2018, at 10:24, Michal Hocko wrote: > > > > On Mon 26-03-18 22:45:31, Ilya Smith wrote: > >> > >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote: > >>> > >>> On Fri 23-03-18 20:55:49, Ilya Smith

Re: [PATCH 1/2] selftests/powerpc: Add ptrace tests for Protection Key registers

Ram Pai writes: > On Fri, Feb 23, 2018 at 03:33:43PM -0300, Thiago Jung Bauermann wrote: >> This test exercises read and write access to the AMR, IAMR and UAMOR. >> > > Tested-by: Ram Pai > Acked-by: Ram Pai Ping? Can this and

[RFC PATCH for 4.17 08/21] powerpc: Wire up restartable sequences system call

From: Boqun Feng Wire up the rseq system call on powerpc. This provides an ABI improving the speed of a user-space getcpu operation on powerpc by skipping the getcpu system call on the fast path, as well as improving the speed of user-space operations on per-cpu data

Re: [PATCH script] hwmon: Use octal not symbolic permissions

On Tue, 2018-03-27 at 08:44 -0700, Guenter Roeck wrote: > On 03/27/2018 04:48 AM, Joe Perches wrote: > > On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote: > > > On 03/27/2018 12:35 AM, Joe Perches wrote: > > > > On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote: > > > > > Since the

Re: RFC on writel and writel_relaxed

Hi, On 27-03-2018 15:46, Sinan Kaya wrote: > > Sinan > "We are being told that if you use writel(), then you don't need a wmb() on > all architectures." > > Alex: > "I'm not sure who told you that but that is incorrect, at least for > x86. If you attempt to use writel() without the wmb() we will

[RFC PATCH for 4.17 12/21] powerpc: Wire up cpu_opv system call

Signed-off-by: Mathieu Desnoyers CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Michael Ellerman CC: Boqun Feng CC: Peter Zijlstra CC: "Paul E.

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

> On 27 Mar 2018, at 10:24, Michal Hocko wrote: > > On Mon 26-03-18 22:45:31, Ilya Smith wrote: >> >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote: >>> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote: > On 23 Mar 2018, at 15:48, Matthew Wilcox

Re: [PATCH v2 10/10] powerpc/64s: Wire up cpu_show_spectre_v2()

unscribed me  On ‎Tuesday‎, ‎March‎ ‎27‎, ‎2018‎ ‎05‎:‎31‎:‎31‎ ‎AM‎ ‎PDT, Michael Ellerman wrote: Add a definition for cpu_show_spectre_v2() to override the generic version. This has several permuations, though in practice some may not occur we cater for any

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

LEROY Christophe a écrit : Mathieu Malaterre a écrit : Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe wrote: Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe

Re: [PATCH 14/19] powerpc/altivec: Add missing prototypes for altivec

Mathieu Malaterre a écrit : Christophe, On Sat, Mar 24, 2018 at 9:10 PM, LEROY Christophe wrote: Mathieu Malaterre a écrit : On Fri, Mar 23, 2018 at 1:19 PM, christophe leroy wrote: Le 22/03/2018

Re: [PATCH] cxl: remove a dead branch

Le 22/03/2018 à 22:05, Mathieu Malaterre a écrit : In commit 14baf4d9c739 ("cxl: Add guest-specific code") the following code was added: if (afu->crs_len < 0) { dev_err(>dev, "Unexpected configuration record size value\n"); return -EINVAL; }

Re: [PATCH] powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

unscribed me  On ‎Tuesday‎, ‎March‎ ‎27‎, ‎2018‎ ‎05‎:‎34‎:‎30‎ ‎AM‎ ‎PDT, Michael Ellerman wrote: Nicholas Piggin writes: > opal_nvram_write currently just assumes success if it encounters an > error other than OPAL_BUSY or OPAL_BUSY_EVENT.

  1   2   >