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

2018-03-27 Thread Ram Pai
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 cc: Andrew Morton Reviewed-by: Ingo Molnar

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

2018-03-27 Thread Ram Pai
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 co

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

2018-03-27 Thread Ram Pai
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 archite

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

2018-03-27 Thread Ram Pai
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 cc: Andrew Morton Reviewed-by: Dav

[PATCH] Documentation/process: update FUSE project website

2018-03-27 Thread Martin Kepplinger
According to the old project site, https://sourceforge.net/projects/fuse/ the project has moved to https://github.com/libfuse/ so we update the link to point to the latest libfuse release. Signed-off-by: Martin Kepplinger --- Documentation/process/changes.rst | 2 +- 1 file changed, 1 insertion(

[PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example

2018-03-27 Thread Will Deacon
The section of memory-barriers.txt that describes the dma_Xmb() barriers has an incorrect example claiming that a wmb() is required after writing to coherent memory in order for those writes to be visible to a device before a subsequent MMIO access using writel() can reach the device. In fact, thi

Re: [PATCH v6 2/2] cpuset: Add cpuset.sched_load_balance to v2

2018-03-27 Thread Tejun Heo
Hello, On Mon, Mar 26, 2018 at 04:28:49PM -0400, Waiman Long wrote: > Maybe we can have a different root level flag, say, > sched_partition_domain that is equivalent to !sched_load_balnace. > However, I am still not sure if we should enforce that no task should be > in the root cgroup when the fla

Re: [PATCH v6 2/2] cpuset: Add cpuset.sched_load_balance to v2

2018-03-27 Thread Waiman Long
On 03/27/2018 10:02 AM, Tejun Heo wrote: > Hello, > > On Mon, Mar 26, 2018 at 04:28:49PM -0400, Waiman Long wrote: >> Maybe we can have a different root level flag, say, >> sched_partition_domain that is equivalent to !sched_load_balnace. >> However, I am still not sure if we should enforce that no

Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers

2018-03-27 Thread Rob Herring
On Sun, Mar 18, 2018 at 12:28:57AM +0100, Paul Cercueil wrote: > Add documentation about how to properly use the Ingenic TCU > (Timer/Counter Unit) drivers from devicetree. > > Signed-off-by: Paul Cercueil > --- > .../bindings/clock/ingenic,tcu-clocks.txt | 42 > .../bi

Re: [PATCH V2 3/9] dt-bindings: Tegra186 tachometer device tree bindings

2018-03-27 Thread Rob Herring
On Wed, Mar 21, 2018 at 10:10:38AM +0530, Rajkumar Rampelli wrote: > Supply Device tree binding documentation for the NVIDIA > Tegra186 SoC's Tachometer Controller > > Signed-off-by: Rajkumar Rampelli > --- > > V2: Renamed compatible string to "nvidia,tegra186-pwm-tachometer" > Renamed dt pr

Re: [PATCH V2 3/9] dt-bindings: Tegra186 tachometer device tree bindings

2018-03-27 Thread Rob Herring
On Tue, Mar 27, 2018 at 09:52:49AM -0500, Rob Herring wrote: > On Wed, Mar 21, 2018 at 10:10:38AM +0530, Rajkumar Rampelli wrote: > > Supply Device tree binding documentation for the NVIDIA > > Tegra186 SoC's Tachometer Controller > > > > Signed-off-by: Rajkumar Rampelli > > --- > > > > V2: Rena

Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example

2018-03-27 Thread Paul E. McKenney
On Tue, Mar 27, 2018 at 02:11:27PM +0100, Will Deacon wrote: > The section of memory-barriers.txt that describes the dma_Xmb() barriers > has an incorrect example claiming that a wmb() is required after writing > to coherent memory in order for those writes to be visible to a device > before a subs

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

2018-03-27 Thread Andrey Konovalov
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 v2 2/6] uaccess: add untagged_addr definition for other arches

2018-03-27 Thread Andrey Konovalov
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 other archi

[RFC PATCH v2 6/6] arm64: update Documentation/arm64/tagged-pointers.txt

2018-03-27 Thread Andrey Konovalov
Add a note that work on passing tagged user pointers to the kernel via syscalls has started, but might not be complete yet. Signed-off-by: Andrey Konovalov --- Documentation/arm64/tagged-pointers.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/arm64/tag

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

2018-03-27 Thread Andrey Konovalov
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 --- arch/arm64/include/asm/uaccess.h | 3 ++- 1 file cha

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

2018-03-27 Thread Andrey Konovalov
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 i

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

2018-03-27 Thread Andrey Konovalov
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 Konov

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

2018-03-27 Thread Andrey Konovalov
Hi! 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 patc

HI

2018-03-27 Thread Lucy Boston
-- Greeting, once again is me Lucy Boston this is twice am contacting you please is very urgent respond to me for more details through my. Email: dr.lucybos...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org M

Re: [PATCH v6 2/2] cpuset: Add cpuset.sched_load_balance to v2

2018-03-27 Thread Mike Galbraith
On Tue, 2018-03-27 at 10:23 -0400, Waiman Long wrote: > On 03/27/2018 10:02 AM, Tejun Heo wrote: > > Hello, > > > > On Mon, Mar 26, 2018 at 04:28:49PM -0400, Waiman Long wrote: > >> Maybe we can have a different root level flag, say, > >> sched_partition_domain that is equivalent to !sched_load_bal