RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)

Please post the acpidump for this machine so we can analyze the actual AML byte code. Thanks. > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, April 11, 2017 3:58 PM > To: Paul Menzel > Cc: Moore, Robert

RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)

Please post the acpidump for this machine so we can analyze the actual AML byte code. Thanks. > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, April 11, 2017 3:58 PM > To: Paul Menzel > Cc: Moore, Robert ; Maciej S. Szmigiero > ;

[PATCH RFC untested] ptr_ring: batched ring producer

A known weakness in ptr_ring design is that it does not handle well the situation when ring is almost empty: as entries are consumed they are immediately used again by the producer, so consumer and producer keep accessing/invalidating a shared cache line. Batching seems to help somewhat but only

[PATCH RFC untested] ptr_ring: batched ring producer

A known weakness in ptr_ring design is that it does not handle well the situation when ring is almost empty: as entries are consumed they are immediately used again by the producer, so consumer and producer keep accessing/invalidating a shared cache line. Batching seems to help somewhat but only

Re: [PATCH 6/6] regulator: anatop: set default voltage selector for pcie

On Thu, Apr 13, 2017 at 03:41:03PM +0800, Dong Aisheng wrote: > On Tue, Apr 11, 2017 at 09:40:03PM +0100, Mark Brown wrote: > > Why is this the only anatop regulator which can have this problem and > > how do we know this is a good value? > Anatop regulator has no separate gate bit. > e.g. >

Re: [PATCH 6/6] regulator: anatop: set default voltage selector for pcie

On Thu, Apr 13, 2017 at 03:41:03PM +0800, Dong Aisheng wrote: > On Tue, Apr 11, 2017 at 09:40:03PM +0100, Mark Brown wrote: > > Why is this the only anatop regulator which can have this problem and > > how do we know this is a good value? > Anatop regulator has no separate gate bit. > e.g. >

Re: [PATCH v4 0/5] perf report: Show branch type

On Wed, Apr 12, 2017 at 11:42:44PM +0800, Jin, Yao wrote: > > > On 4/12/2017 10:26 PM, Jiri Olsa wrote: > > On Wed, Apr 12, 2017 at 08:25:34PM +0800, Jin, Yao wrote: > > > > SNIP > > > > > > # Overhead Command Source Shared Object Source Symbol > > > > Target

Re: [PATCH v4 0/5] perf report: Show branch type

On Wed, Apr 12, 2017 at 11:42:44PM +0800, Jin, Yao wrote: > > > On 4/12/2017 10:26 PM, Jiri Olsa wrote: > > On Wed, Apr 12, 2017 at 08:25:34PM +0800, Jin, Yao wrote: > > > > SNIP > > > > > > # Overhead Command Source Shared Object Source Symbol > > > > Target

RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)

I'll try to look at it today Bob > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, April 11, 2017 3:58 PM > To: Paul Menzel > Cc: Moore, Robert ; Maciej S. Szmigiero >

RE: [Regression Linux 4.11] TPM module not loaded anymore (was: Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)

I'll try to look at it today Bob > -Original Message- > From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] > Sent: Tuesday, April 11, 2017 3:58 PM > To: Paul Menzel > Cc: Moore, Robert ; Maciej S. Szmigiero > ; linux-kernel@vger.kernel.org; Arthur > Heymans ;

Re: [PATCH v2] sched/fair: update scale invariance of PELT

On Wed, Apr 12, 2017 at 04:50:47PM +0200, Vincent Guittot wrote: > Le Wednesday 12 Apr 2017 à 13:28:58 (+0200), Peter Zijlstra a écrit : > > > > |-|-| (wall-time) > > - F=100% > > **--- F= 66% > > |--||

Re: [PATCH v2] sched/fair: update scale invariance of PELT

On Wed, Apr 12, 2017 at 04:50:47PM +0200, Vincent Guittot wrote: > Le Wednesday 12 Apr 2017 à 13:28:58 (+0200), Peter Zijlstra a écrit : > > > > |-|-| (wall-time) > > - F=100% > > **--- F= 66% > > |--||

Re: [PATCH] thermal: core: Add a back up thermal shutdown mechanism

Hello, On Wed, Apr 12, 2017 at 04:45:44PM +0800, Zhang Rui wrote: > > > > Zhang/Eduardo, > > > > > > > > OMAP5/DRA7 is one case. > > > > > > > > I believe i this is the root cause of this failure. > > > > > > > > thermal_zone_device_check --> thermal_zone_device_update --> > > > >

Re: [PATCH 6/6] regulator: anatop: set default voltage selector for pcie

On Tue, Apr 11, 2017 at 09:40:03PM +0100, Mark Brown wrote: > On Wed, Apr 12, 2017 at 09:58:47AM +0800, Dong Aisheng wrote: > > Set the initial voltage selector for vddpcie in case it's disabled > > by default. > > Why is this the only anatop regulator which can have this problem and > how do we

Re: [PATCH] thermal: core: Add a back up thermal shutdown mechanism

Hello, On Wed, Apr 12, 2017 at 04:45:44PM +0800, Zhang Rui wrote: > > > > Zhang/Eduardo, > > > > > > > > OMAP5/DRA7 is one case. > > > > > > > > I believe i this is the root cause of this failure. > > > > > > > > thermal_zone_device_check --> thermal_zone_device_update --> > > > >

Re: [PATCH 6/6] regulator: anatop: set default voltage selector for pcie

On Tue, Apr 11, 2017 at 09:40:03PM +0100, Mark Brown wrote: > On Wed, Apr 12, 2017 at 09:58:47AM +0800, Dong Aisheng wrote: > > Set the initial voltage selector for vddpcie in case it's disabled > > by default. > > Why is this the only anatop regulator which can have this problem and > how do we

Re: [PATCH v4 0/5] perf report: Show branch type

On 4/12/2017 10:26 PM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 08:25:34PM +0800, Jin, Yao wrote: SNIP # Overhead Command Source Shared Object Source Symbol Target SymbolBasic Block Cycles # ...

Re: [PATCH v4 0/5] perf report: Show branch type

On 4/12/2017 10:26 PM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 08:25:34PM +0800, Jin, Yao wrote: SNIP # Overhead Command Source Shared Object Source Symbol Target SymbolBasic Block Cycles # ...

Re: [PATCH 3/3] input: touchscreen: ar1021_i2c: coding style fixes

On Tue, Apr 11, 2017 at 12:27:59PM +0200, Martin Kepplinger wrote: > Use the common kernel coding style and corrently align parameters with > open parenthesis. > > Signed-off-by: Martin Kepplinger Applied, thank you. > --- >

Re: [PATCH 3/3] input: touchscreen: ar1021_i2c: coding style fixes

On Tue, Apr 11, 2017 at 12:27:59PM +0200, Martin Kepplinger wrote: > Use the common kernel coding style and corrently align parameters with > open parenthesis. > > Signed-off-by: Martin Kepplinger Applied, thank you. > --- > drivers/input/touchscreen/ar1021_i2c.c | 4 ++-- > 1 file changed, 2

Re: [PATCH 1/3] input: touchscreen: ar1021_i2c: add support for AR1020

Hi Martin, On Tue, Apr 11, 2017 at 12:27:57PM +0200, Martin Kepplinger wrote: > ar1021_i2c simply also supports the ar1020 device we use. This is tested. > They also share the same datasheet: > >http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf > > We differentiate not only to

Re: [PATCH 1/3] input: touchscreen: ar1021_i2c: add support for AR1020

Hi Martin, On Tue, Apr 11, 2017 at 12:27:57PM +0200, Martin Kepplinger wrote: > ar1021_i2c simply also supports the ar1020 device we use. This is tested. > They also share the same datasheet: > >http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf > > We differentiate not only to

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

=== > BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg > net/ipv4/ip_sockglue.c:500 [inline] at addr 880059be0128 Thanks for the report. This is accessing skb->dev from within recvmsg() at line info->ipi_ifindex = skb->dev->ifindex; Introduced in 829ae9d61165

Re: net/ipv4: use-after-free in ipv4_datagram_support_cmsg

=== > BUG: KASAN: use-after-free in ipv4_datagram_support_cmsg > net/ipv4/ip_sockglue.c:500 [inline] at addr 880059be0128 Thanks for the report. This is accessing skb->dev from within recvmsg() at line info->ipi_ifindex = skb->dev->ifindex; Introduced in 829ae9d61165

[PATCH v2 2/2] [media] cec: Handle RC capability more elegantly

If a user specifies the use of RC as a capability, they should really be enabling RC Core code. If they do not we WARN() them of this and disable the capability for them. Once we know RC Core code has not been enabled, we can update the user's capabilities and use them as a term of reference for

[PATCH v2 1/2] [media] rc-core: Add inlined stubs for core rc_* functions

Currently users have to use all sorts of ugly #ifery within their drivers in order to avoid linking issues at build time. This patch allows users to safely call these functions when !CONFIG_RC_CORE and make decisions based on the return value instead. This is a much more common and clean way of

[PATCH v2 2/2] [media] cec: Handle RC capability more elegantly

If a user specifies the use of RC as a capability, they should really be enabling RC Core code. If they do not we WARN() them of this and disable the capability for them. Once we know RC Core code has not been enabled, we can update the user's capabilities and use them as a term of reference for

[PATCH v2 1/2] [media] rc-core: Add inlined stubs for core rc_* functions

Currently users have to use all sorts of ugly #ifery within their drivers in order to avoid linking issues at build time. This patch allows users to safely call these functions when !CONFIG_RC_CORE and make decisions based on the return value instead. This is a much more common and clean way of

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote: > Hi Jerome, > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse wrote: > > On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote: > >> Hi Jerome, > >> > >> On Thu, Apr 06, 2017 at 04:27:00PM -0400,

Re: [PATCH 00/16] Intel FPGA Device Drivers

On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote: > Hi Jerome, > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse wrote: > > On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote: > >> Hi Jerome, > >> > >> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote: > >>

Re: [RFC v3 0/5] Add capacity capping support to the CPU controller

On Wed, Apr 12, 2017 at 02:55:38PM +0100, Patrick Bellasi wrote: > On 12-Apr 14:10, Peter Zijlstra wrote: > > Even for the cgroup interface, I think they should set a per-task > > property, not a group property. > > Ok, right now using CGroups ans primary (and unique) interface, these > values

Re: [RFC v3 0/5] Add capacity capping support to the CPU controller

On Wed, Apr 12, 2017 at 02:55:38PM +0100, Patrick Bellasi wrote: > On 12-Apr 14:10, Peter Zijlstra wrote: > > Even for the cgroup interface, I think they should set a per-task > > property, not a group property. > > Ok, right now using CGroups ans primary (and unique) interface, these > values

[PATCH v2 2/2] pidns: Expose task pid_ns_for_children to userspace

pid_ns_for_children set by a task is known only to the task itself, and it's impossible to identify it from outside. It's a big problem for checkpoint/restore software like CRIU, because it can't correctly handle tasks, that do setns(CLONE_NEWPID) in proccess of their work. This patch solves the

[PATCH v2 2/2] pidns: Expose task pid_ns_for_children to userspace

pid_ns_for_children set by a task is known only to the task itself, and it's impossible to identify it from outside. It's a big problem for checkpoint/restore software like CRIU, because it can't correctly handle tasks, that do setns(CLONE_NEWPID) in proccess of their work. This patch solves the

Re: [PATCH 5/6] regulator: anatop-regulator: make regulator-name using optionally

On Tue, Apr 11, 2017 at 09:38:18PM +0100, Mark Brown wrote: > On Wed, Apr 12, 2017 at 09:58:46AM +0800, Dong Aisheng wrote: > > rdesc->name/regulator-name is optional according to standard regulator > > binding doc. Use it conditionally to avoid a kernel NULL point crash. > > It is optional in

Re: [PATCH 5/6] regulator: anatop-regulator: make regulator-name using optionally

On Tue, Apr 11, 2017 at 09:38:18PM +0100, Mark Brown wrote: > On Wed, Apr 12, 2017 at 09:58:46AM +0800, Dong Aisheng wrote: > > rdesc->name/regulator-name is optional according to standard regulator > > binding doc. Use it conditionally to avoid a kernel NULL point crash. > > It is optional in

[PATCH v2 1/2] ns: Allow ns_entries to have custom symlink content

Patch series "Expose task pid_ns_for_children to userspace". pid_ns_for_children set by a task is known only to the task itself, and it's impossible to identify it from outside. It's a big problem for checkpoint/restore software like CRIU, because it can't correctly handle tasks, that do

[PATCH v2 1/2] ns: Allow ns_entries to have custom symlink content

Patch series "Expose task pid_ns_for_children to userspace". pid_ns_for_children set by a task is known only to the task itself, and it's impossible to identify it from outside. It's a big problem for checkpoint/restore software like CRIU, because it can't correctly handle tasks, that do

[PATCH v2 0/2] Expose task pid_ns_for_children to userspace

pid_ns_for_children set by a task is known only to the task itself, and it's impossible to identify it from outside. It's a big problem for checkpoint/restore software like CRIU, because it can't correctly handle tasks, that do setns(CLONE_NEWPID) in proccess of their work. If they have a custom

[PATCH v2 0/2] Expose task pid_ns_for_children to userspace

pid_ns_for_children set by a task is known only to the task itself, and it's impossible to identify it from outside. It's a big problem for checkpoint/restore software like CRIU, because it can't correctly handle tasks, that do setns(CLONE_NEWPID) in proccess of their work. If they have a custom

RE: [PATCH] regulator: core: Allow dummy regulators for supplies

Hi Mark, > -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Wednesday, April 12, 2017 4:37 AM > To: A.S. Dong > Cc: Liam Girdwood; linux-kernel@vger.kernel.org; shawn...@kernel.org; > Robin Gong > Subject: Re: [PATCH] regulator: core: Allow dummy regulators for

RE: [PATCH] regulator: core: Allow dummy regulators for supplies

Hi Mark, > -Original Message- > From: Mark Brown [mailto:broo...@kernel.org] > Sent: Wednesday, April 12, 2017 4:37 AM > To: A.S. Dong > Cc: Liam Girdwood; linux-kernel@vger.kernel.org; shawn...@kernel.org; > Robin Gong > Subject: Re: [PATCH] regulator: core: Allow dummy regulators for

Re: [PATCH V3 00/16] Introduce the BFQ I/O scheduler

On Wed, 2017-04-12 at 08:01 +0200, Paolo Valente wrote: > Where is my mistake? I think in the Makefile. How about the patch below? Please note that I'm no Kbuild expert. diff --git a/block/Makefile b/block/Makefile index 546066ee7fa6..b3711af6b637 100644 --- a/block/Makefile +++ b/block/Makefile

Re: [PATCH V3 00/16] Introduce the BFQ I/O scheduler

On Wed, 2017-04-12 at 08:01 +0200, Paolo Valente wrote: > Where is my mistake? I think in the Makefile. How about the patch below? Please note that I'm no Kbuild expert. diff --git a/block/Makefile b/block/Makefile index 546066ee7fa6..b3711af6b637 100644 --- a/block/Makefile +++ b/block/Makefile

RE: [PATCH] ACPICA: Export mutex functions

The ACPICA mutex functions are based on the host OS functions, so they don't really buy you anything. You should just use the native Linux functions. > -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Wednesday, April 12, 2017 8:13 AM > To: Moore, Robert

RE: [PATCH] ACPICA: Export mutex functions

The ACPICA mutex functions are based on the host OS functions, so they don't really buy you anything. You should just use the native Linux functions. > -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Wednesday, April 12, 2017 8:13 AM > To: Moore, Robert ;

Re: [PATCH] x86/mm: fix dump pagetables for 4 levels of page tables

On Wed, Apr 12, 2017 at 04:36:34PM +0200, Juergen Gross wrote: > Commit fdd3d8ce0ea62 ("x86/dump_pagetables: Add support for 5-level > paging") introduced an error for dumping with only 4 levels by setting > PGD_LEVEL_MULT to a wrong value. > > This is leading to e.g. addresses printed as

Re: [PATCH] x86/mm: fix dump pagetables for 4 levels of page tables

On Wed, Apr 12, 2017 at 04:36:34PM +0200, Juergen Gross wrote: > Commit fdd3d8ce0ea62 ("x86/dump_pagetables: Add support for 5-level > paging") introduced an error for dumping with only 4 levels by setting > PGD_LEVEL_MULT to a wrong value. > > This is leading to e.g. addresses printed as

Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111

On 04/12/2017 09:40 AM, Linus Walleij wrote: > On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt wrote: > >> Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL, >> which seems to be necessary on this platform. My understanding is that >> this means that the

Re: On the unlikely off-chance that this is new news

Hi Paul, On 12/04/17 08:15, Paul E. McKenney wrote: > Hello! > > On the unlikely off-chance that this is new news... > It is actually new news for me (it might be still unlikely for Peter, Luca and Tommaso, that I Cc-ed). > A Hannes Weisbach of TU Dresden published this masters thesis on >

Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111

On 04/12/2017 09:40 AM, Linus Walleij wrote: > On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt wrote: > >> Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL, >> which seems to be necessary on this platform. My understanding is that >> this means that the pixel clock is

Re: On the unlikely off-chance that this is new news

Hi Paul, On 12/04/17 08:15, Paul E. McKenney wrote: > Hello! > > On the unlikely off-chance that this is new news... > It is actually new news for me (it might be still unlikely for Peter, Luca and Tommaso, that I Cc-ed). > A Hannes Weisbach of TU Dresden published this masters thesis on >

[GIT PULL] EFI urgent fix

Folks, please pull the single below fix from Omar which fixes a kexec boot regression. I've based the pull on tip/efi/urgent since the EFI urgent queue hasn't reached Linus' tree yet. The following changes since commit 55d728a40d368ba80443be85c02e641fc9082a3f: efi/fb: Avoid reconfiguration of

[GIT PULL] EFI urgent fix

Folks, please pull the single below fix from Omar which fixes a kexec boot regression. I've based the pull on tip/efi/urgent since the EFI urgent queue hasn't reached Linus' tree yet. The following changes since commit 55d728a40d368ba80443be85c02e641fc9082a3f: efi/fb: Avoid reconfiguration of

[PATCH] x86/efi: Don't try to reserve runtime regions

From: Omar Sandoval Reserving a runtime region results in splitting the efi memory descriptors for the runtime region. This results in runtime region descriptors with bogus memory mappings, leading to interesting crashes like the following during a kexec: [0.001000] general

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

On Tue, Apr 11, 2017 at 6:23 AM, Kees Cook wrote: > On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni wrote: [...] >> A userspace request to use a kernel feature that is implemented by modules >> that are not loaded may trigger the module auto-load feature

[PATCH] x86/efi: Don't try to reserve runtime regions

From: Omar Sandoval Reserving a runtime region results in splitting the efi memory descriptors for the runtime region. This results in runtime region descriptors with bogus memory mappings, leading to interesting crashes like the following during a kexec: [0.001000] general protection

Re: [PATCH RFC v2 0/3] security: Add ModAutoRestrict LSM

On Tue, Apr 11, 2017 at 6:23 AM, Kees Cook wrote: > On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni wrote: [...] >> A userspace request to use a kernel feature that is implemented by modules >> that are not loaded may trigger the module auto-load feature to load >> these modules in order to

Re: iov_iter_pipe warning.

On Wed, Apr 12, 2017 at 10:35:19AM -0400, Dave Jones wrote: > [ 4140.040002] asked to read 8, claims to have read 4 > [ 4140.051634] actual size of data in pipe 8 > [ 4140.063234] [0:8 > [ 4140.342955] ---[ end trace d074a8823fe244d4 ]--- > [ 4140.353868] in->f_op = a02dc980,

Re: iov_iter_pipe warning.

On Wed, Apr 12, 2017 at 10:35:19AM -0400, Dave Jones wrote: > [ 4140.040002] asked to read 8, claims to have read 4 > [ 4140.051634] actual size of data in pipe 8 > [ 4140.063234] [0:8 > [ 4140.342955] ---[ end trace d074a8823fe244d4 ]--- > [ 4140.353868] in->f_op = a02dc980,

Re: [v2] PCI: Add an option to control probing of VFs before enabling SR-IOV

On Wed, Apr 12, 2017 at 09:37:22AM -0500, Bodong Wang wrote: > On 4/11/2017 4:12 PM, Bjorn Helgaas wrote: > >Hi Bodong, > > > >On Wed, Mar 22, 2017 at 05:53:58PM +0200, bod...@mellanox.com wrote: > >>From: Bodong Wang > >> > >>Sometimes it is not desirable to probe the

Re: [v2] PCI: Add an option to control probing of VFs before enabling SR-IOV

On Wed, Apr 12, 2017 at 09:37:22AM -0500, Bodong Wang wrote: > On 4/11/2017 4:12 PM, Bjorn Helgaas wrote: > >Hi Bodong, > > > >On Wed, Mar 22, 2017 at 05:53:58PM +0200, bod...@mellanox.com wrote: > >>From: Bodong Wang > >> > >>Sometimes it is not desirable to probe the virtual functions after >

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf wrote: > > > On 12.04.17 16:34, Jim Mattson wrote: >> >> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate >> monitor and mwait instructions as nop"), so when we intercept >> MONITOR/MWAIT, we synthesize #UD.

Re: [PATCH v6] kvm: better MWAIT emulation for guests

On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf wrote: > > > On 12.04.17 16:34, Jim Mattson wrote: >> >> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate >> monitor and mwait instructions as nop"), so when we intercept >> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this

Re: [PATCH] selinux: add selinux_is_enforced() function

2017-04-12 15:58 GMT+02:00 Stephen Smalley : > Even your usage of selinux_is_enabled() looks suspect; that should > probably go away. Only other user of it seems to be some cred validity > checking that could be dropped as well. Well the main reason for calling

Re: [PATCH] selinux: add selinux_is_enforced() function

2017-04-12 15:58 GMT+02:00 Stephen Smalley : > Even your usage of selinux_is_enabled() looks suspect; that should > probably go away. Only other user of it seems to be some cred validity > checking that could be dropped as well. Well the main reason for calling selinux_is_enabled() is

Re: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support

On Wed, Apr 12, 2017 at 04:31:28PM +0200, Thomas Petazzoni wrote: > Hello, > > Sorry for the late feedback about this. > > On Sun, 9 Apr 2017 20:09:27 +0200, Ralph Sennhauser wrote: > > > + gpio1: gpio@18140 { > > + compatible = "marvell,armada-370-xp-gpio"; > > +

Re: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support

On Wed, Apr 12, 2017 at 04:31:28PM +0200, Thomas Petazzoni wrote: > Hello, > > Sorry for the late feedback about this. > > On Sun, 9 Apr 2017 20:09:27 +0200, Ralph Sennhauser wrote: > > > + gpio1: gpio@18140 { > > + compatible = "marvell,armada-370-xp-gpio"; > > +

Re: There is a Tasks RCU stall warning

On Wed, Apr 12, 2017 at 10:42:55AM -0400, Steven Rostedt wrote: > On Wed, 12 Apr 2017 07:19:36 -0700 > "Paul E. McKenney" wrote: > > > On Wed, Apr 12, 2017 at 09:18:21AM -0400, Steven Rostedt wrote: > > > On Tue, 11 Apr 2017 20:23:07 -0700 > > > "Paul E. McKenney"

Re: There is a Tasks RCU stall warning

On Wed, Apr 12, 2017 at 10:42:55AM -0400, Steven Rostedt wrote: > On Wed, 12 Apr 2017 07:19:36 -0700 > "Paul E. McKenney" wrote: > > > On Wed, Apr 12, 2017 at 09:18:21AM -0400, Steven Rostedt wrote: > > > On Tue, 11 Apr 2017 20:23:07 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > But

[PATCH] pidns: Disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid()

alloc_pidmap() advances pid_namespace::last_pid. When first pid allocation fails, then next created process will have pid 2 and pid_ns_prepare_proc() won't be called. So, pid_namespace::proc_mnt will never be initialized (not to mention that there won't be a child reaper). I saw crash stack of

[PATCH] pidns: Disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid()

alloc_pidmap() advances pid_namespace::last_pid. When first pid allocation fails, then next created process will have pid 2 and pid_ns_prepare_proc() won't be called. So, pid_namespace::proc_mnt will never be initialized (not to mention that there won't be a child reaper). I saw crash stack of

Re: [PATCH v3] xen,input: add xen-kbdfront module parameter for setting resolution

Hi Juergen, On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote: > Add a parameter for setting the resolution of xen-kbdfront in order to > be able to cope with a (virtual) frame buffer of arbitrary resolution. > > While at it remove the pointless second reading of parameters from >

Re: [PATCH v3] xen,input: add xen-kbdfront module parameter for setting resolution

Hi Juergen, On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote: > Add a parameter for setting the resolution of xen-kbdfront in order to > be able to cope with a (virtual) frame buffer of arbitrary resolution. > > While at it remove the pointless second reading of parameters from >

[PATCH v3 1/1] pwm: pca9685: fix gpio-only operation.

gpio-only driver operation never clears the SLEEP bit, which can cause the gpios to become unusable. Example: 1. user requests first pwm -> driver clears SLEEP bit 2. user frees last pwm -> driver sets SLEEP bit 3. user requests gpio 4. user switches gpio on-> output does

[PATCH v3 0/1] pwm: pca9685: fix gpio-only operation.

Mika, I investigated what's required to suspend the device on remove, by compiling as a module and running insmod/rmmod in various circumstances. As you suspected, pm_runtime_suspend() is unneccessary. I removed it, and the chip is suspended ok when the module unloads. But this could be because

[PATCH v3 1/1] pwm: pca9685: fix gpio-only operation.

gpio-only driver operation never clears the SLEEP bit, which can cause the gpios to become unusable. Example: 1. user requests first pwm -> driver clears SLEEP bit 2. user frees last pwm -> driver sets SLEEP bit 3. user requests gpio 4. user switches gpio on-> output does

[PATCH v3 0/1] pwm: pca9685: fix gpio-only operation.

Mika, I investigated what's required to suspend the device on remove, by compiling as a module and running insmod/rmmod in various circumstances. As you suspected, pm_runtime_suspend() is unneccessary. I removed it, and the chip is suspended ok when the module unloads. But this could be because

On the unlikely off-chance that this is new news

Hello! On the unlikely off-chance that this is new news... A Hannes Weisbach of TU Dresden published this masters thesis on quasi-real-time scheduling: http://os.inf.tu-dresden.de/papers_ps/weisbach-master.pdf If you have come across this, I would be interested in your thoughts.

On the unlikely off-chance that this is new news

Hello! On the unlikely off-chance that this is new news... A Hannes Weisbach of TU Dresden published this masters thesis on quasi-real-time scheduling: http://os.inf.tu-dresden.de/papers_ps/weisbach-master.pdf If you have come across this, I would be interested in your thoughts.

Re: [BUG nohz]: wrong user and system time accounting

On Wed, Apr 12, 2017 at 04:57:58PM +0200, Thomas Gleixner wrote: > On Wed, 12 Apr 2017, Frederic Weisbecker wrote: > > On Tue, Apr 11, 2017 at 04:22:48PM +0200, Thomas Gleixner wrote: > > > It's not different from the current jiffies based stuff at all. Same > > > failure mode. > > > > Yes you're

Re: [BUG nohz]: wrong user and system time accounting

On Wed, Apr 12, 2017 at 04:57:58PM +0200, Thomas Gleixner wrote: > On Wed, 12 Apr 2017, Frederic Weisbecker wrote: > > On Tue, Apr 11, 2017 at 04:22:48PM +0200, Thomas Gleixner wrote: > > > It's not different from the current jiffies based stuff at all. Same > > > failure mode. > > > > Yes you're

Re: [PATCH 1/2] clk: cs2000: use existing priv_to_dev() to getting struct device

On 04/11, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Signed-off-by: Kuninori Morimoto > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation

Re: [PATCH 1/2] clk: cs2000: use existing priv_to_dev() to getting struct device

On 04/11, Kuninori Morimoto wrote: > From: Kuninori Morimoto > > Signed-off-by: Kuninori Morimoto > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH 2/6] regulator: anatop: only set supply regulator when it actually exists

Hi Mark, On Tue, Apr 11, 2017 at 09:31:24PM +0100, Mark Brown wrote: > On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote: > > Mandatorily set the initdata->supply_regulator while it actually not > > exist will cause regulator core to resolve supply each time whenever > > a new

Re: [PATCH 2/6] regulator: anatop: only set supply regulator when it actually exists

Hi Mark, On Tue, Apr 11, 2017 at 09:31:24PM +0100, Mark Brown wrote: > On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote: > > Mandatorily set the initdata->supply_regulator while it actually not > > exist will cause regulator core to resolve supply each time whenever > > a new

Re: [PATCH v2 01/17] mm: drop "wait" parameter from write_one_page

On 04/12/2017 09:27 AM, Matthew Wilcox wrote: > On Wed, Apr 12, 2017 at 08:05:58AM -0400, Jeff Layton wrote: >> The callers all set it to 1. Also, make it clear that this function will >> not set any sort of AS_* error, and that the caller must do so if >> necessary. No existing caller uses this

[PATCH] ACPICA: Export mutex functions

Mutex functions may be needed by drivers. Examples are accesses to Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO environmental monitor registers, both which may also be accessed through DSDT. Signed-off-by: Guenter Roeck --- drivers/acpi/acpica/utxfmutex.c | 2

Re: [PATCH v2 01/17] mm: drop "wait" parameter from write_one_page

On 04/12/2017 09:27 AM, Matthew Wilcox wrote: > On Wed, Apr 12, 2017 at 08:05:58AM -0400, Jeff Layton wrote: >> The callers all set it to 1. Also, make it clear that this function will >> not set any sort of AS_* error, and that the caller must do so if >> necessary. No existing caller uses this

[PATCH] ACPICA: Export mutex functions

Mutex functions may be needed by drivers. Examples are accesses to Super-IO SIO registers (0x2e/0x2f or 0x4e/0x4f) or Super-IO environmental monitor registers, both which may also be accessed through DSDT. Signed-off-by: Guenter Roeck --- drivers/acpi/acpica/utxfmutex.c | 2 ++ 1 file changed,

Re: [PATCH 8/8] statx: Include a mask for stx_attributes in struct statx

On Tue, Apr 04, 2017 at 12:12:52AM -0700, Christoph Hellwig wrote: > On Fri, Mar 31, 2017 at 06:32:17PM +0100, David Howells wrote: > > Include a mask in struct stat to indicate which bits of stx_attributes the > > filesystem actually supports. > > What's the use case for this? ping!

Re: [PATCH 8/8] statx: Include a mask for stx_attributes in struct statx

On Tue, Apr 04, 2017 at 12:12:52AM -0700, Christoph Hellwig wrote: > On Fri, Mar 31, 2017 at 06:32:17PM +0100, David Howells wrote: > > Include a mask in struct stat to indicate which bits of stx_attributes the > > filesystem actually supports. > > What's the use case for this? ping!

Re: [PATCH] selinux: add selinux_is_enforced() function

2017-04-12 16:35 GMT+02:00 Stephen Smalley : > How are you using this SELinux information in the kernel and/or in > userspace? What's the purpose of it? What are you comparing it > against? Why do you care if it changes? Enforcement status and policy version are compared to

Re: [PATCH] selinux: add selinux_is_enforced() function

2017-04-12 16:35 GMT+02:00 Stephen Smalley : > How are you using this SELinux information in the kernel and/or in > userspace? What's the purpose of it? What are you comparing it > against? Why do you care if it changes? Enforcement status and policy version are compared to their previously

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote: > > > > > > ...1d.7: PCI fixup... pass 2 > > > > > > ...1d.7: PCI fixup... pass 3 > > > > > > ...1d.7: PCI fixup... pass 3 done > > > > > > > > > > > > ...followed by hang. So yes, it looks USB related. > > > > > > > > > > > >

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Mon, Apr 03, 2017 at 08:20:50PM +0200, Pavel Machek wrote: > > > > > > ...1d.7: PCI fixup... pass 2 > > > > > > ...1d.7: PCI fixup... pass 3 > > > > > > ...1d.7: PCI fixup... pass 3 done > > > > > > > > > > > > ...followed by hang. So yes, it looks USB related. > > > > > > > > > > > >

Re: [PATCH v9] drm: Unplug drm device when unregistering it

On Wed, Apr 12, 2017 at 04:56:21PM +0800, Jeffy Chen wrote: > After unbinding drm, the user space may still owns the drm dev fd, and > may still be able to call drm ioctl. > > We're using an unplugged state to prevent something like that, so let's > reuse it here. > > Also drop drm_unplug_dev,

Re: [PATCH 1/1] fs: Allows for xattr support to be compiled out

2017-04-12 0:47 GMT+02:00 Brian Ashworth : > Allows for xattr syscalls and related functions to be compiled out. > These are not needed on machines that do not utilize filesystems that > support xattrs or userspaces that require extended attributes. This will > aid in the

Re: [PATCH v9] drm: Unplug drm device when unregistering it

On Wed, Apr 12, 2017 at 04:56:21PM +0800, Jeffy Chen wrote: > After unbinding drm, the user space may still owns the drm dev fd, and > may still be able to call drm ioctl. > > We're using an unplugged state to prevent something like that, so let's > reuse it here. > > Also drop drm_unplug_dev,

Re: [PATCH 1/1] fs: Allows for xattr support to be compiled out

2017-04-12 0:47 GMT+02:00 Brian Ashworth : > Allows for xattr syscalls and related functions to be compiled out. > These are not needed on machines that do not utilize filesystems that > support xattrs or userspaces that require extended attributes. This will > aid in the tinification efforts.

<    6   7   8   9   10   11   12   13   14   15   >