[PATCH v5 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch depends on patch 1/2 This patch was inspired from GRKERNSEC_HARDEN_TTY. This

[PATCH v5 1/2] security: tty: Add owner user namespace to tty_struct

This patch adds struct user_namespace *owner_user_ns to the tty_struct. Then it is set to current_user_ns() in the alloc_tty_struct function. This is done to facilitate capability checks against the original user namespace that allocated the tty. E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)

[PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH 2/2] arm64: Add workaround for Cavium Thunder erratum 30115

Some Cavium Thunder CPUs suffer a problem where a KVM guest may inadvertently cause the host kernel to quit receiving interrupts. The workaround is to toggle the group-1 interrupt enable on each exit from the guest. Signed-off-by: David Daney ---

[PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.

We have discovered in rare circumstances, guest execution may result in host not receiving one or more interrupts. This does not otherwise affect guest or host execution and/or isolation. David Daney (2): arm64: Add MIDR values for Cavium cn83XX SoCs arm64: Add workaround for Cavium Thunder

[PATCH 1/2] arm64: Add MIDR values for Cavium cn83XX SoCs

Signed-off-by: David Daney --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 0984d1b..235e77d 100644 --- a/arch/arm64/include/asm/cputype.h +++

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On 4/24/2017 10:57 AM, Dave Hansen wrote: On 04/24/2017 08:53 AM, Tom Lendacky wrote: On 4/21/2017 4:52 PM, Dave Hansen wrote: On 04/18/2017 02:17 PM, Tom Lendacky wrote: @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from, unsigned long vaddr,

Re: [PATCH v5 09/32] x86/mm: Provide general kernel support for memory encryption

On 4/21/2017 4:52 PM, Dave Hansen wrote: On 04/18/2017 02:17 PM, Tom Lendacky wrote: @@ -55,7 +57,7 @@ static inline void copy_user_page(void *to, void *from, unsigned long vaddr, __phys_addr_symbol(__phys_reloc_hide((unsigned long)(x))) #ifndef __va -#define __va(x)

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote: [...] > > How about an atomic use_count on the mux_control, a bool shared that is > > only set by the first consumer, and controls whether selecting locks? > > That has the drawback that it is hard to restore the mux-control in a safe > way so

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

error message when selecting the >>> mux input from userspace: >>> >>> $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]" >>> [ 66.258368] >>> [ 66.259919] = >>> [ 66.265369] [ BUG: media-ct

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

pace: > > > > $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]" > > [ 66.258368] > > [ 66.259919] = > > [ 66.265369] [ BUG: media-ctl/258 still has locks held! ] > > [ 66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainte

Re: [PATCH v4 2/2] tiocsti-restrict : make TIOCSTI ioctl require CAP_SYS_ADMIN

Quoting Matt Brown (m...@nmatt.com): > This introduces the tiocsti_restrict sysctl, whose default is controlled via > CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts > all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. > > This patch depends on patch 1/2 > > This

Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

Quoting Matt Brown (m...@nmatt.com): > This patch adds struct user_namespace *owner_user_ns to the tty_struct. > Then it is set to current_user_ns() in the alloc_tty_struct function. > > This is done to facilitate capability checks against the original user > namespace that allocated the tty. >

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

structure holds a pointer to the task, as well as the mutex that >> - the task is blocked on. It also has the plist node structures to >> - place the task in the waiter_list of a mutex as well as the >> - pi_list of a mutex owner task (described below). >>

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

On 04/21/2017 11:47 PM, Peter Zijlstra wrote: > On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote: >> diff --git a/Documentation/locking/rt-mutex-design.txt >> b/Documentation/locking/rt-mutex-design.txt >> index 8666070..11beb55 100644 >> --- a/Documentation/locking/rt-mutex-design.txt

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote: [...] > Ok, so the difference is probably that the rwsem locking primitive > don't have any lockdep checking hooked up. Because the rwsem was > definitely held in the same way in v13 as the mutex is now held in > v14, so there's no fundamental

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

==== > [ 66.265369] [ BUG: media-ctl/258 still has locks held! ] > [ 66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted > [ 66.275863] - > [ 66.282158] 1 lock held by media-ctl/258: > [ 66.286464] #0: (>lock){+.+.+.}, at: [<

Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

when selecting the mux input from userspace: $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]" [ 66.258368] [ 66.259919] = [ 66.265369] [ BUG: media-ctl/258 still has locks held! ] [ 66.270810] 4.11.0-

Re: [PATCH] KVM: Documentation: remove VM mmap documentation

On 24.04.2017 11:16, Jann Horn wrote: > as no virtual cpus and no memory. An mmap() of a VM fd > -will access the virtual machine's physical address space; offset zero > -corresponds to guest physical address zero. Use of mmap() on a VM fd > -is discouraged if userspace memory allocation

[PATCH v14 06/11] dt-bindings: iio: io-channel-mux: document io-channel-mux bindings

Describe how a multiplexer can be used to select which signal is fed to an io-channel. Acked-by: Jonathan Cameron Acked-by: Rob Herring Signed-off-by: Peter Rosin --- .../bindings/iio/multiplexer/io-channel-mux.txt| 39

[PATCH v14 08/11] dt-bindings: i2c: i2c-mux: document general purpose i2c-mux bindings

Describe how a general purpose multiplexer controller is used to mux an i2c bus. Acked-by: Jonathan Cameron Reviewed-by: Rob Herring Signed-off-by: Peter Rosin --- .../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 99

[PATCH v14 10/11] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux

Analog Devices ADG792A/G is a triple 4:1 mux. Acked-by: Jonathan Cameron Reviewed-by: Rob Herring Signed-off-by: Peter Rosin --- .../devicetree/bindings/mux/adi,adg792a.txt| 75 ++ 1 file changed, 75 insertions(+)

[PATCH v14 09/11] i2c: i2c-mux-gpmux: new driver

This is a general purpose i2c mux that uses a multiplexer controlled by the multiplexer subsystem to do the muxing. The user can select if the mux is to be mux-locked and parent-locked as described in Documentation/i2c/i2c-topology. Acked-by: Jonathan Cameron Acked-by: Wolfram

[PATCH v14 11/11] mux: adg792a: add mux controller driver for ADG792A/G

Analog Devices ADG792A/G is a triple 4:1 mux. Reviewed-by: Jonathan Cameron Signed-off-by: Peter Rosin --- drivers/mux/Kconfig | 12 drivers/mux/Makefile | 1 + drivers/mux/mux-adg792a.c | 157 ++

[PATCH v14 07/11] iio: multiplexer: new iio category and iio-mux driver

When a multiplexer changes how an iio device behaves (for example by feeding different signals to an ADC), this driver can be used to create one virtual iio channel for each multiplexer state. Depends on the generic multiplexer subsystem. Cache any ext_info values from the parent iio channel,

[PATCH v14 05/11] iio: inkern: api for manipulating ext_info of iio channels

Extend the inkern api with functions for reading and writing ext_info of iio channels. Acked-by: Jonathan Cameron Signed-off-by: Peter Rosin --- drivers/iio/inkern.c | 60 include/linux/iio/consumer.h | 37

[PATCH v14 04/11] mux: gpio: add mux controller driver for gpio based multiplexers

The driver builds a single multiplexer controller using a number of gpio pins. For N pins, there will be 2^N possible multiplexer states. The GPIO pins can be connected (by the hardware) to several multiplexers, which in that case will be operated in parallel. Reviewed-by: Jonathan Cameron

[PATCH v14 03/11] mux: minimal mux subsystem

Add a new minimalistic subsystem that handles multiplexer controllers. When multiplexers are used in various places in the kernel, and the same multiplexer controller can be used for several independent things, there should be one place to implement support for said multiplexer controller. A

[PATCH v14 01/11] devres: trivial whitespace fix

Everything else is indented with two spaces, so fix the odd one out. Acked-by: Jonathan Cameron Signed-off-by: Peter Rosin --- Documentation/driver-model/devres.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v14 00/11] mux controller abstraction and iio/i2c muxes

Hi! The big change since v13 is that the mux state is now locked with a mutex instead of an rwsem. Other that that, it is mostly restructuring and doc changes. There are a few other "real" changes as well, but those changes feel kind of minor. I guess what I'm trying to say is that although the

Re: [PATCH v2 3/3] Documentation/kernel-parameters.txt: Update 'memmap=' option description

On 04/24/17 at 11:53am, Dou Liyang wrote: > > > At 04/24/2017 10:40 AM, Baoquan He wrote: > > In commit: > > > > 9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time") > > > > ... 'memmap=' was changed to adopt multiple, comma delimited values in a > > single entry, so update the