Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

, it is there https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/powerpc/mm/slice.c?h=next-20180309=326691ad4f179e6edc7eb1271e618dd673e4736d The id seems to be exactly the same. Christophe thanks, greg k-h --- L'absence de virus dans ce courrier électronique a été vérifiée par

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:55 PM, Ram Pai wrote: > On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: >> On 03/09/2018 12:12 AM, Ram Pai wrote: >>> Once an address range is associated with an allocated pkey, it cannot be >>> reverted back to key-0. There is no valid reason for the above behavior.

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 02:40:32PM -0800, Dave Hansen wrote: > On 03/09/2018 12:12 AM, Ram Pai wrote: > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications need the

Re: [PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

On Fri, Mar 09, 2018 at 04:48:59PM +0100, Christophe Leroy wrote: > Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d There is no such git commit id in Linus's tree :( Please fix up and resend the series. thanks, greg k-h

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 12:12 AM, Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. Why don't we just set pkey 0 to be allocated in

[PATCH v2] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

Re: [RFC PATCH 0/6] arm64: untag user pointers passed to the kernel

On Fri, Mar 9, 2018 at 3:15 PM, Robin Murphy wrote: > Hi Andrey, > > On 09/03/18 14:01, Andrey Konovalov wrote: >> >> arm64 has a feature called Top Byte Ignore, which allows to embed pointer >> tags into the top byte of each pointer. Userspace programs (such as >> HWASan, a

Re: [RFC PATCH 6/6] arch: add untagged_addr definition for other arches

On Fri, Mar 9, 2018 at 3:16 PM, Robin Murphy wrote: > On 09/03/18 14:02, Andrey Konovalov wrote: >> >> To allow arm64 syscalls accept tagged pointers from userspace, we must >> untag them when they are passed to the kernel. Since untagging is done in >> generic parts of the

Re: [RFC PATCH 6/6] arch: add untagged_addr definition for other arches

On 09/03/18 14:02, Andrey Konovalov wrote: To allow arm64 syscalls accept tagged pointers from userspace, we must untag them when they are passed to the kernel. Since untagging is done in generic parts of the kernel (like the mm subsystem), the untagged_addr macro should be defined for all

Re: [RFC PATCH 0/6] arm64: untag user pointers passed to the kernel

Hi Andrey, On 09/03/18 14:01, Andrey Konovalov wrote: arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the

Re: [RFC PATCH 6/6] arch: add untagged_addr definition for other arches

On Fri, Mar 9, 2018 at 3:02 PM, Andrey Konovalov wrote: > To allow arm64 syscalls accept tagged pointers from userspace, we must > untag them when they are passed to the kernel. Since untagging is done in > generic parts of the kernel (like the mm subsystem), the

[RFC PATCH 6/6] arch: add untagged_addr definition for other arches

To allow arm64 syscalls accept tagged pointers from userspace, we must untag them when they are passed to the kernel. Since untagging is done in generic parts of the kernel (like the mm subsystem), the untagged_addr macro should be defined for all architectures. Define it as a noop for all other

[RFC PATCH 5/6] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user

strncpy_from_user and strnlen_user accept user addresses as arguments, and do not go through the same path as copy_from_user and others, so here we need to separately handle the case of tagged user addresses as well. Untag user pointers passed to these functions. Signed-off-by: Andrey Konovalov

[RFC PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

mm/gup.c provides a kernel interface that accepts user addresses and manipulates user pages directly (for example get_user_pages, that is used by the futex syscall). Here we also need to handle the case of tagged user pointers. Untag addresses passed to this interface. Signed-off-by: Andrey

[RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls

Memory subsystem syscalls accept user addresses as arguments, but don't use copy_from_user and other similar functions, so we need to handle this case separately. Untag user pointers passed to madvise, mbind, get_mempolicy, mincore, mlock, mlock2, brk, mmap_pgoff, old_mmap, munmap,

[RFC PATCH 1/6] arm64: add type casts to untagged_addr macro

This patch makes the untagged_addr macro accept all kinds of address types (void *, unsigned long, etc.) and allows not to specify type casts in each place where it is used. This is done by using __typeof__. Signed-off-by: Andrey Konovalov ---

[RFC PATCH 0/6] arm64: untag user pointers passed to the kernel

arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces. This patch

[RFC PATCH 2/6] arm64: untag user addresses in copy_from_user and others

copy_from_user (and a few other similar functions) are used to copy data from user memory into the kernel memory or vice versa. Since a user can provided a tagged pointer to one of the syscalls that use copy_from_user, we need to correctly handle such pointers. Do this by untagging user pointers

[PATCH] powerpc/mm: Fix section mismatch warning in stop_machine_change_mapping()

Fix the warning messages for stop_machine_change_mapping(), and a number of other affected functions in its call chain. All modified functions are under CONFIG_MEMORY_HOTPLUG, so __meminit is okay (keeps them / does not discard them). Boot-tested on powernv/power9/radix-mmu and

[PATCH] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 09:43:32AM +0100, Ingo Molnar wrote: > > * Ram Pai wrote: > > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 09:19:53PM +1100, Michael Ellerman wrote: > Ram Pai writes: > > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the contrary applications

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: > On 03/09/2018 09:12 AM, Ram Pai wrote: > >Once an address range is associated with an allocated pkey, it cannot be > >reverted back to key-0. There is no valid reason for the above behavior. > > mprotect without a key does not

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 09, 2018 at 07:37:04PM +1100, Balbir Singh wrote: > On Fri, Mar 9, 2018 at 7:12 PM, Ram Pai wrote: > > Once an address range is associated with an allocated pkey, it cannot be > > reverted back to key-0. There is no valid reason for the above behavior. On > > the

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

On 09/03/18 18:29, Nipun Gupta wrote: -Original Message- From: Christoph Hellwig [mailto:h...@lst.de] Sent: Thursday, March 08, 2018 13:11 On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote: Sorry for asking a trivial question - looking into dma_configure() I see that PCI

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Thursday, March 08, 2018 13:11 > > On Tue, Mar 06, 2018 at 04:41:56AM +, Nipun Gupta wrote: > > Sorry for asking a trivial question - looking into dma_configure() I see > > that > > PCI is used in the start

Re: [PATCH v2] On ppc64le we HAVE_RELIABLE_STACKTRACE

On Thu, 8 Mar 2018 10:26:16 -0600 Josh Poimboeuf wrote: > This doesn't seem to address some of my previous concerns: You're right. That discussion quickly headed towards objtool and I forgot about this one paragraph with the remarks. > - Bailing on interrupt/exception

Re: [PATCH 2/2] ppc64le save_stack_trace_tsk_reliable (Was: HAVE_RELIABLE_STACKTRACE)

On Fri, 9 Mar 2018 08:43:33 +1100 Balbir Singh wrote: > On Tue, 27 Feb 2018 17:09:24 +0100 > Torsten Duwe wrote: > > +save_stack_trace_tsk_reliable(struct task_struct *tsk, > > + struct stack_trace *trace) > > Just double

[PATCH 4.14 4/4] powerpc/mm/slice: Fix hugepage allocation at hint address on 8xx

Upstream aa0ab02ba992eb956934b21373e0138211486ddd On the 8xx, the page size is set in the PMD entry and applies to all pages of the page table pointed by the said PMD entry. When an app has some regular pages allocated (e.g. see below) and tries to mmap() a huge page at a hint address covered by

[PATCH 4.14 3/4] powerpc/mm/slice: Enhance for supporting PPC32

Upstream db3a528db41caaa6dfd4c64e9f5efb1c81a80467 In preparation for the following patch which will fix an issue on the 8xx by re-using the 'slices', this patch enhances the 'slices' implementation to support 32 bits CPUs. On PPC32, the address space is limited to 4Gbytes, hence only the low

[PATCH 4.14 2/4] powerpc/mm/slice: create header files dedicated to slices

Upstream a3286f05bc5a5bc7fc73a9783ec89de78fcd07f8 In preparation for the following patch which will enhance 'slices' for supporting PPC32 in order to fix an issue on hugepages on 8xx, this patch takes out of page*.h all bits related to 'slices' and put them into newly created slice.h header

[PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

Upstream 326691ad4f179e6edc7eb1271e618dd673e4736d bitmap_or() and bitmap_andnot() can work properly with dst identical to src1 or src2. There is no need of an intermediate result bitmap that is copied back to dst in a second step. Signed-off-by: Christophe Leroy

Re: [PATCH 1/2] crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf

On Mon, Feb 26, 2018 at 05:40:04PM +0100, Christophe Leroy wrote: > Commit 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping > outside the requests") introduced a persistent dma mapping of > req_ctx->hw_context > Commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash >

Re: [PATCH 2/2] crypto: talitos - do not perform unnecessary dma synchronisation

On Mon, Feb 26, 2018 at 05:40:06PM +0100, Christophe Leroy wrote: > req_ctx->hw_context is mainly used only by the HW. So it is not needed > to sync the HW and the CPU each time hw_context in DMA mapped. > This patch modifies the DMA mapping in order to limit synchronisation > to necessary

Re: [RFC PATCH 1/1] powerpc/ftrace: Exclude real mode code from

Michael Ellerman wrote: "Naveen N. Rao" writes: My earlier assumption was that we have other scenarios when we are in realmode (specifically with MSR_RI unset) where we won't be able to recover from a trap, during function tracing (*). I did a set of

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior. mprotect without a key does not necessarily use key 0, e.g. if protection keys are used to emulate page

[GIT PULL] Please pull powerpc/linux.git powerpc-4.16-5 tag

Hi Linus, Please pull some more powerpc fixes for 4.16: The following changes since commit eb0a2d2620ae431c543963c8c7f08f597366fc60: powerpc/powernv: Support firmware disable of RFI flush (2018-02-23 16:55:42 +1100) are available in the git repository at:

Re: [RFC PATCH 1/1] powerpc/ftrace: Exclude real mode code from

"Naveen N. Rao" writes: > Michael Ellerman wrote: >> "Naveen N. Rao" writes: >> >>> We can't take a trap in most parts of real mode code. Instead of adding >>> the 'notrace' annotation to all C functions that can be invoked from

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

Ram Pai writes: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. Please explain this in much more detail. Is it an

Re: [PATCH 00/27] cpufreq: Stop validating cpufreq table in drivers

On 26-02-18, 10:38, Viresh Kumar wrote: > Hi, > > A patchset [1] sent last week already updated the cpufreq core to start > validating cpufreq table if the policy contains a valid > "policy->freq_table" pointer. > > This series updates all such drivers to stop validating the cpufreq > table

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

* Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. > > The patch relaxes the restriction. > >

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On Fri, Mar 9, 2018 at 7:12 PM, Ram Pai wrote: > Once an address range is associated with an allocated pkey, it cannot be > reverted back to key-0. There is no valid reason for the above behavior. On > the contrary applications need the ability to do so. > > The patch

Re: [RFC PATCH 1/1] powerpc/ftrace: Exclude real mode code from

Steven Rostedt wrote: On Thu, 08 Mar 2018 00:07:07 +0530 "Naveen N. Rao" wrote: Yes, that's negligible. Though, to be honest, I will have to introduce a 'mfmsr' for the older -pg variant. I still think that the improved reliability far outweighs the minor

Re: [RFC PATCH 1/1] powerpc/ftrace: Exclude real mode code from

Michael Ellerman wrote: "Naveen N. Rao" writes: We can't take a trap in most parts of real mode code. Instead of adding the 'notrace' annotation to all C functions that can be invoked from real mode, detect that we are in real mode on ftrace entry and return

[PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior. On the contrary applications need the ability to do so. The patch relaxes the restriction. Tested on powerpc and x86_64. cc: Dave Hansen