Re: [PATCH Documentation/memory-barriers.txt] Clarify limited control-dependency scope

On Fri, Jun 17, 2016 at 09:53:50AM +0200, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > Nothing in the control-dependencies section of memory-barriers.txt > > says that control dependencies don't extend beyond the end of the > > if-statement containing the

[RFC nowrap: PATCH v7 00/19] ILP32 for ARM64

This series enables aarch64 with ilp32 mode, and as supporting work, introduces ARCH_32BIT_OFF_T configuration option that is enabled for existing 32-bit architectures but disabled for new arches (so 64-bit off_t is is used by new userspace). This version is based on kernel v4.7-rc3. It works

[PATCH 02/19] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option

All new 32-bit architectures should have 64-bit off_t type, but existing architectures has 32-bit ones. To handle it, new config option is added to arch/Kconfig that defaults ARCH_32BIT_OFF_T to be disabled for non-64 bit architectures. All existing 32-bit architectures enable it explicitly here.

[PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

From: Andrew Pinski In this patchset ILP32 ABI support is added. Additionally to AARCH32, which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible. >From now, AARCH32_EL0 (former COMPAT) config option means the support of AARCH32 userspace, ARM64_ILP32 -

[PATCH 07/19] thread: move thread bits accessors to separated file

They may be accessed from low-level code, so isolating is a measure to avoid circular dependencies in header files. The exact reason for circular dependency is WARN_ON() macro added by Al Viro in patch [edd63a27] "set_restore_sigmask() is never called without SIGPENDING (and never should be)"

[PATCH 04/19] arm64: ensure the kernel is compiled for LP64

From: Andrew Pinski The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Andrew Pinski

[PATCH 09/19] arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64

ILP32 tasks are needed to be distinguished from lp64 and aarch32. This patch adds helper functions is_ilp32_compat_{task,thread} and thread flag TIF_32BIT_AARCH64 to address it. This is a preparation for following patches in ilp32 patchset. For consistency, SET_PERSONALITY is changed here

[PATCH 08/19] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)

Based on patch of Andrew Pinski. This patch introduces is_a32_compat_task and is_a32_thread so it is easier to say this is a a32 specific thread or a generic compat thread/task. Corresponding functions are located in to avoid mess in headers. Some files include both and , and this is wrong

[PATCH 13/19] arm64: ilp32: share aarch32 syscall handlers

off_t is passed in register pair just like in aarch32. In this patch corresponding aarch32 handlers are shared to ilp32 code. Signed-off-by: Yury Norov --- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/entry32.S| 65 --

[PATCH 12/19] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

Here new aarch32 ptrace syscall handler is introsuced to avoid run-time detection of the task type. Signed-off-by: Yury Norov --- arch/arm64/include/asm/unistd32.h | 2 +- arch/arm64/kernel/ptrace.c| 50 ++-

[PATCH 10/19] arm64: introduce binfmt_elf32.c

As we support more than one compat formats, it looks more reasonable to not use fs/compat_binfmt.c. Custom binfmt_elf32.c allows to move aarch32 specific definitions there and make code more maintainable and readable. Signed-off-by: Yury Norov --- arch/arm64/Kconfig

[PATCH 11/19] arm64: ilp32: introduce binfmt_ilp32.c

to handle ILP32 binaries Signed-off-by: Yury Norov --- arch/arm64/include/asm/elf.h | 6 +++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/binfmt_ilp32.c | 96 3 files changed, 103 insertions(+) create mode

[PATCH 15/19] arm64: signal: share lp64 signal routines to ilp32

After that, it will be possible to reuse it in ilp32. Signed-off-by: Yury Norov --- arch/arm64/include/asm/signal_common.h | 33 arch/arm64/kernel/signal.c | 93 +- 2 files changed, 92 insertions(+), 34

[PATCH 17/19] arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext

From: Andrew Pinski ILP32 uses AARCH32 compat structures and syscall handlers for signals. But ILP32 struct rt_sigframe and ucontext differs from both LP64 and AARCH32. So some specific mechanism is needed to take care of it. Signed-off-by: Andrew Pinski

[PATCH 03/19] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

Based on Andrew Pinski's patch-series. Signed-off-by: Yury Norov --- Documentation/arm64/ilp32.txt | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/arm64/ilp32.txt diff --git

[PATCH 01/19] compat ABI: use non-compat openat and open_by_handle_at variants

The only difference is that non-compat version forces O_LARGEFILE, and it should be the default behaviour for all architectures, as we don't support 32-bit off_t. The only exception is tile32, that continues with compat version of syscalls. Signed-off-by: Yury Norov

Re: [PATCH v5 1/1] hwmon: Add support for INA3221 Triple Current/Voltage Monitors

On 06/10/2016 11:44 AM, Guenter Roeck wrote: > On Fri, Jun 10, 2016 at 10:32:33AM -0500, Andrew F. Davis wrote: >> Add support for the the INA3221 26v capable, Triple channel, >> Bi-Directional, Zero-Drift, Low-/High-Side, Current/Voltage Monitor >> with I2C interface. >> >> Signed-off-by: Andrew

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

Em Fri, Jun 17, 2016 at 12:16:47PM -0400, Daniel Micay escreveu: > On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote: > > This Changelog is completely devoid of information. _WHY_ are you > > doing this? > Attack surface reduction. It's possible to use seccomp-bpf for some > limited cases,

Re: [PATCHv3 5/7] EDAC, altera: Add Arria10 ECC memory init functions

On 06/17/2016 12:21 PM, Borislav Petkov wrote: On Mon, Jun 13, 2016 at 04:19:10PM -0500, ttha...@opensource.altera.com wrote: From: Thor Thayer In preparation for additional memory module ECCs, add the memory initialization functions and helper functions used

Re: [PATCHv3 6/7] EDAC, altera: Add Arria10 Ethernet EDAC support

On Mon, Jun 13, 2016 at 04:19:11PM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add Altera Arria10 Ethernet FIFO memory EDAC support. Update > to support a common compatibility string for all ethernet > FIFOs in the DT. > > Signed-off-by:

Re: [PATCHv3 3/7] EDAC, altera: Share Arria10 check_deps & IRQ functions

On Fri, Jun 17, 2016 at 12:09:59PM -0500, Thor Thayer wrote: > Since each peripheral's EDAC can be individually selected, the build > generates a warning of an unused function if just L2 cache was selected. > > The ifdeffery is ugly but it removes that warning in the L2 only case. You could add

Re: [PATCHv3 2/7] EDAC, altera: Add panic flag check to A10 IRQ

On Fri, Jun 17, 2016 at 12:05:41PM -0500, Thor Thayer wrote: > That is a good question. We have 2 important uses for OCRAM 1) to hold our > power-down/sleep and resume functions and 2) to hold our FPGA contents > during sleep. If either of these is corrupted, it is better to panic than to > load

Re: [PATCHv3 2/7] EDAC, altera: Add panic flag check to A10 IRQ

Hi Boris, On 06/17/2016 11:51 AM, Borislav Petkov wrote: On Mon, Jun 13, 2016 at 04:19:07PM -0500, ttha...@opensource.altera.com wrote: From: Thor Thayer In preparation for additional memory module ECCs, the IRQ function will check a panic flag before doing a

Re: [PATCHv3 1/7] EDAC, altera: Check parent status for Arria10 EDAC block

On Fri, Jun 17, 2016 at 11:54:04AM -0500, Thor Thayer wrote: > Yes. Thanks! I will make the change. No need, already did and applied. You can drop this patch from your queue. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list:

Re: [PATCHv3 2/7] EDAC, altera: Add panic flag check to A10 IRQ

On Mon, Jun 13, 2016 at 04:19:07PM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > In preparation for additional memory module ECCs, the > IRQ function will check a panic flag before doing a > kernel panic on double bit errors. ECCs on buffers >

Re: [PATCHv3 1/7] EDAC, altera: Check parent status for Arria10 EDAC block

On 06/17/2016 11:46 AM, Borislav Petkov wrote: On Mon, Jun 13, 2016 at 04:19:06PM -0500, ttha...@opensource.altera.com wrote: From: Thor Thayer In preparation for the Arria10 ECC modules, check the status of the parent in the device tree to ensure the block is

Re: [PATCHv3 1/7] EDAC, altera: Check parent status for Arria10 EDAC block

On Mon, Jun 13, 2016 at 04:19:06PM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > In preparation for the Arria10 ECC modules, check the status > of the parent in the device tree to ensure the block is enabled. > Skip if no parent phandle is set

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote: > On Thu, Jun 16, 2016 at 03:27:55PM -0700, Kees Cook wrote: > > Hi guys, > > > > This patch wasn't originally CCed to you (I'm fixing that now). > > Would > > you consider taking this into the perf tree?  > > No. > > > It's been in

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Thu, 16 Jun, at 09:38:31AM, Tom Lendacky wrote: > > Ok, I think this was happening before the commit to build our own > EFI page table structures: > > commit 67a9108ed ("x86/efi: Build our own page table structures") > > Before this commit the boot services ended up mapped into the kernel >

[RFC PATCH-tip/locking/core v3 03/10] locking/rwsem: Make rwsem_spin_on_owner() return a tri-state value

This patch modifies rwsem_spin_on_owner() to return a tri-state value to better reflect the state of lock holder which enables us to make a better decision of what to do next. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 14 +- 1 files changed,

[RFC PATCH-tip/locking/core v3 04/10] locking/rwsem: Enable count-based spinning on reader

When the rwsem is owned by reader, writers stop optimistic spinning simply because there is no easy way to figure out if all the readers are actively running or not. However, there are scenarios where the readers are unlikely to sleep and optimistic spinning can help performance. This patch

[RFC PATCH-tip/locking/core v3 06/10] locking/rwsem: Move common rwsem macros to asm-generic/rwsem_types.h

Almost all the macro definitions in the various architecture specific rwsem.h header files are essentially the same. This patch moves all of them into a common header asm-generic/rwsem_types.h to eliminate the duplication. Suggested-by: Peter Zijlstra (Intel) Signed-off-by:

[RFC PATCH-tip/locking/core v3 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers are provided when osq_lock() is successful or when osq_unlock() is called. The change on the unlock side is more for documentation

[RFC PATCH-tip/locking/core v3 02/10] locking/rwsem: Stop active read lock ASAP

Currently, when down_read() fails, the active read locking isn't undone until the rwsem_down_read_failed() function grabs the wait_lock. If the wait_lock is contended, it may takes a while to get the lock. During that period, writer lock stealing will be disabled because of the active read lock.

[RFC PATCH-tip/locking/core v3 07/10] locking/rwsem: Change RWSEM_WAITING_BIAS for better disambiguation

When the count value is in between 0 and RWSEM_WAITING_BIAS, there are 2 possibilities. Either a writer is present and there is no waiter or there are waiters and readers. There is no easy way to know which is true unless the wait_lock is taken. This patch changes the RWSEM_WAITING_BIAS from

[RFC PATCH-tip/locking/core v3 05/10] locking/rwsem: move down rwsem_down_read_failed function

Move the rwsem_down_read_failed() function down to below the optimistic spinning section before enabling optimistic spinning for the readers. It is because the rwsem_down_read_failed() function will call rwsem_optimistic_spin() in later patch. There is no change in code. Signed-off-by: Waiman

[RFC PATCH-tip/locking/core v3 08/10] locking/rwsem: Enable spinning readers

This patch enables readers to optimistically spin when the rspin_threshold is non-zero. That threshold value should only be set when the lock owners of the rwsem are unlikely to go to sleep. Otherwise enabling reader spinning may make the performance worse in some cases. On a 4-socket Haswell

[RFC PATCH-tip/locking/core v3 10/10] locking/rwsem: Add a boot parameter to reader spinning threshold

The default reader spining threshold is current set to 4096. However, the right reader spinning threshold may vary from one system to another and among the different architectures. This patch adds a new kernel boot parameter to modify the threshold value. This enables better tailoring to the needs

Re: [kernel-hardening] Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

> As a debian user, is this a good place to complain? Because it does > get > it the way. It would be relevant to whether or not it should be set to 3 by default in the kernel without explicit configuration, but there's no proposal to do that. Debian has to pick a trade-off beyond security and a

Re: [PATCH V3 1/2] i2c: core: add devm apis for i2c_new_dummy()

Hi, [auto build test WARNING on wsa/i2c/for-next] [also build test WARNING on next-20160617] [cannot apply to v4.7-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Laxman-Dewangan/i2c-core

[PATCH V3 2/2] i2c: Add devm_i2c_new_dummy() in managed list

i2c_new_dummy() gained their devm_ wrappers. Add the devm_i2c_new_dummy() in managed APIs list. Signed-off-by: Laxman Dewangan --- Changes form V2: - Drop the devm_i2c_unregister_device() Documentation/driver-model/devres.txt | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH V3 1/2] i2c: core: add devm apis for i2c_new_dummy()

Add resource managed version of i2c_new_dummy(). This helps in: 1. reducing the code size in error path to explicitly unregister the new dummy client. 2. Sometime, need of the remove callback on client driver to just unregister the new i2c dummy client. Signed-off-by: Laxman Dewangan

Re: [PATCH v8 1/4] i2c: add a protocol parameter to the alert callback

On Thu, Jun 09, 2016 at 04:53:47PM +0200, Benjamin Tissoires wrote: > .alert() is meant to be generic, but there is currently no way > for the device driver to know which protocol generated the alert. > Add a parameter in .alert() to help the device driver to understand > what is given in data. >

Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support

On Thu, Jun 09, 2016 at 04:53:48PM +0200, Benjamin Tissoires wrote: > SMBus Host Notify allows a slave device to act as a master on a bus to > notify the host of an interrupt. On Intel chipsets, the functionality > is directly implemented in the firmware. We just need to export a > function to

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Ingo Molnar wrote: > > * Thomas Garnier wrote: > > > arch/x86/include/asm/kaslr.h| 12 +++ > > Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or > in the > x86 tree. So the problem is that this file gets

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Ingo Molnar wrote: > > * Thomas Garnier wrote: > > > arch/x86/include/asm/kaslr.h| 12 +++ > > Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or > in the > x86 tree. Ah, never mind, introduced by the first

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Thomas Garnier wrote: > arch/x86/include/asm/kaslr.h| 12 +++ Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or in the x86 tree. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the

Re: [PATCH Documentation/memory-barriers.txt] Clarify limited control-dependency scope

* Paul E. McKenney wrote: > Nothing in the control-dependencies section of memory-barriers.txt > says that control dependencies don't extend beyond the end of the > if-statement containing the control dependency. Worse yet, in many > situations, they do extend

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

On Thu, Jun 16, 2016 at 03:27:55PM -0700, Kees Cook wrote: > Hi guys, > > This patch wasn't originally CCed to you (I'm fixing that now). Would > you consider taking this into the perf tree? No. > It's been in active use > in both Debian and Android for a while now. Very nice of you all to