Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Mon, 02 Apr 2018, Davidlohr Bueso wrote: The case for the rt task throttling (which this workload also hits) can be ignored in that the skip_update call is actually bogus and quite the contrary (the request bits are removed/reverted). While at it, how about this trivial patch? 8

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Mon, 02 Apr 2018, Davidlohr Bueso wrote: The case for the rt task throttling (which this workload also hits) can be ignored in that the skip_update call is actually bogus and quite the contrary (the request bits are removed/reverted). While at it, how about this trivial patch? 8

[PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

the assert_clock_updated() check happy. Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- kernel/sched/rt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 86b77987435e..ad13e6242481 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c

[PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

the assert_clock_updated() check happy. Signed-off-by: Davidlohr Bueso --- kernel/sched/rt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 86b77987435e..ad13e6242481 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -8

Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

On Fri, 30 Mar 2018, Eric W. Biederman wrote: Davidlohr Bueso <d...@stgolabs.net> writes: I ran this on a 40-core (no ht) Westmere with two benchmarks. The first is Manfred's sysvsem lockunlock[1] program which uses _processes_ to, well, lock and unlock the semaphore. The options are a

Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

On Fri, 30 Mar 2018, Eric W. Biederman wrote: Davidlohr Bueso writes: I ran this on a 40-core (no ht) Westmere with two benchmarks. The first is Manfred's sysvsem lockunlock[1] program which uses _processes_ to, well, lock and unlock the semaphore. The options are a little unconventional

Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

On Wed, 28 Mar 2018, Davidlohr Bueso wrote: On Fri, 23 Mar 2018, Eric W. Biederman wrote: Today the last process to update a semaphore is remembered and reported in the pid namespace of that process. If there are processes in any other pid namespace querying that process id with GETPID

Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

On Wed, 28 Mar 2018, Davidlohr Bueso wrote: On Fri, 23 Mar 2018, Eric W. Biederman wrote: Today the last process to update a semaphore is remembered and reported in the pid namespace of that process. If there are processes in any other pid namespace querying that process id with GETPID

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

iirc. No objections from me. Acked-by: Davidlohr Bueso <d...@stgolabs.net>

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

iirc. No objections from me. Acked-by: Davidlohr Bueso

Re: [RFC][PATCH] ipc: Remove IPCMNI

Cc'ing mtk, Manfred and linux-api. See below. On Thu, 15 Mar 2018, Waiman Long wrote: On 03/15/2018 03:00 PM, Eric W. Biederman wrote: Waiman Long writes: On 03/14/2018 08:49 PM, Eric W. Biederman wrote: The define IPCMNI was originally the size of a statically sized

Re: [RFC][PATCH] ipc: Remove IPCMNI

Cc'ing mtk, Manfred and linux-api. See below. On Thu, 15 Mar 2018, Waiman Long wrote: On 03/15/2018 03:00 PM, Eric W. Biederman wrote: Waiman Long writes: On 03/14/2018 08:49 PM, Eric W. Biederman wrote: The define IPCMNI was originally the size of a statically sized array in the kernel

Re: [PATCH v4 2/2] locking/debug: Restructure the lock debugging menu

of the lock debugging menu. The DEBUG_WW_MUTEX_SLOWPATH option is also added to the PROVE_LOCKING umbrella. Signed-off-by: Waiman Long <long...@redhat.com> Acked-by: Davidlohr Bueso <d...@stgolabs.net>

Re: [PATCH v4 2/2] locking/debug: Restructure the lock debugging menu

of the lock debugging menu. The DEBUG_WW_MUTEX_SLOWPATH option is also added to the PROVE_LOCKING umbrella. Signed-off-by: Waiman Long Acked-by: Davidlohr Bueso

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On Wed, 28 Mar 2018, Waiman Long wrote: +config DEBUG_RWSEMS + bool "RW Semaphore debugging: basic checks" + depends on DEBUG_KERNEL && RWSEM_SPIN_ON_OWNER Why depend on RWSEM_SPIN_ON_OWNER? Doesn't everyone benefit from this? For example, DEBUG_MUTEXES does not need it. Thanks,

Re: [PATCH v4 1/2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On Wed, 28 Mar 2018, Waiman Long wrote: +config DEBUG_RWSEMS + bool "RW Semaphore debugging: basic checks" + depends on DEBUG_KERNEL && RWSEM_SPIN_ON_OWNER Why depend on RWSEM_SPIN_ON_OWNER? Doesn't everyone benefit from this? For example, DEBUG_MUTEXES does not need it. Thanks,

Re: [REVIEW][PATCH 00/11] ipc: Fixing the pid namespace support

On Fri, 23 Mar 2018, Eric W. Biederman wrote: Still I would like to see this fixed and I plan on merging this code. Yes, it needs fixed, but 1) there are pending issues (such as the extra atomics) and 2) its late in the -rc cycle. Plus this issue has existed for 11 years without the world

Re: [REVIEW][PATCH 00/11] ipc: Fixing the pid namespace support

On Fri, 23 Mar 2018, Eric W. Biederman wrote: Still I would like to see this fixed and I plan on merging this code. Yes, it needs fixed, but 1) there are pending issues (such as the extra atomics) and 2) its late in the -rc cycle. Plus this issue has existed for 11 years without the world

Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

On Fri, 23 Mar 2018, Eric W. Biederman wrote: Today the last process to update a semaphore is remembered and reported in the pid namespace of that process. If there are processes in any other pid namespace querying that process id with GETPID the result will be unusable nonsense as it does not

Re: [REVIEW][PATCH 11/11] ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

On Fri, 23 Mar 2018, Eric W. Biederman wrote: Today the last process to update a semaphore is remembered and reported in the pid namespace of that process. If there are processes in any other pid namespace querying that process id with GETPID the result will be unusable nonsense as it does not

Re: [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks

On Sat, 24 Mar 2018, Eric W. Biederman wrote: /** - * smack_of_shm - the smack pointer for the shm - * @shp: the object + * smack_of_ipc - the smack pointer for the ipc + * @isp: the object Nit, but while at it the @isp description does need some love: "@isp: the pointer for the ipc perm

Re: [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks

On Sat, 24 Mar 2018, Eric W. Biederman wrote: /** - * smack_of_shm - the smack pointer for the shm - * @shp: the object + * smack_of_ipc - the smack pointer for the ipc + * @isp: the object Nit, but while at it the @isp description does need some love: "@isp: the pointer for the ipc perm

Re: [REVIEW][PATCH 12/11] ipc: Directly call the security hook in ipc_ops.associate

On Sat, 24 Mar 2018, Eric W. Biederman wrote: After the last round of cleanups the shm, sem, and msg associate operations just became trivial wrappers around the appropriate security method. Simplify things further by just calling the security method directly. Signed-off-by: "Eric W.

Re: [REVIEW][PATCH 12/11] ipc: Directly call the security hook in ipc_ops.associate

On Sat, 24 Mar 2018, Eric W. Biederman wrote: After the last round of cleanups the shm, sem, and msg associate operations just became trivial wrappers around the appropriate security method. Simplify things further by just calling the security method directly. Signed-off-by: "Eric W.

Re: [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks

On Sat, 24 Mar 2018, Casey Schaufler wrote: On 3/23/2018 10:42 PM, Eric W. Biederman wrote: Rename the variables shp, sma, msq to isp. As that is how the code already refers to those variables. Thanks. It's important to keep the code readable. Ah great, ignore my last email then.

Re: [REVIEW][PATCH 13/11] ipc/smack: Tidy up from the change in type of the ipc security hooks

On Sat, 24 Mar 2018, Casey Schaufler wrote: On 3/23/2018 10:42 PM, Eric W. Biederman wrote: Rename the variables shp, sma, msq to isp. As that is how the code already refers to those variables. Thanks. It's important to keep the code readable. Ah great, ignore my last email then.

Re: [REVIEW][PATCH 01/11] sem/security: Pass kern_ipc_perm not sem_array into the sem security hooks

On Fri, 23 Mar 2018, Casey Schaufler wrote: A kern_ipc_perm pointer is conventionally named isp in this code. So the ideal name would be ipcp, used in core ipc, but I have no strong preference over isp, ipp or whatever other name is used in LSMs. The important thing is that kern_ipc_perm

Re: [REVIEW][PATCH 01/11] sem/security: Pass kern_ipc_perm not sem_array into the sem security hooks

On Fri, 23 Mar 2018, Casey Schaufler wrote: A kern_ipc_perm pointer is conventionally named isp in this code. So the ideal name would be ipcp, used in core ipc, but I have no strong preference over isp, ipp or whatever other name is used in LSMs. The important thing is that kern_ipc_perm

Re: [PATCH 2/6] drivers/irqchip: Update supports_deactivate static key to modern api

On Wed, 28 Mar 2018, Marc Zyngier wrote: Looks good to me. How do you want to get this patch merged? Either you deal with it as part of this series, (and in which case please add my Ack on it), or I can take it via the irqchip tree. Considering Ingo picked up the patches in his jurisdiction,

Re: [PATCH 2/6] drivers/irqchip: Update supports_deactivate static key to modern api

On Wed, 28 Mar 2018, Marc Zyngier wrote: Looks good to me. How do you want to get this patch merged? Either you deal with it as part of this series, (and in which case please add my Ack on it), or I can take it via the irqchip tree. Considering Ingo picked up the patches in his jurisdiction,

Re: [PATCH v3 2/2] locking/debug: Add a master lock debugging switch

On Tue, 27 Mar 2018, Waiman Long wrote: Add a new master LOCK_DEBUGGING Kconfig option to turn on all the lock debugging options except the selftests and the torture tests. For what purpose? I'm not sure we want yet another config debug option. These are all expert level configuration and

Re: [PATCH v3 2/2] locking/debug: Add a master lock debugging switch

On Tue, 27 Mar 2018, Waiman Long wrote: Add a new master LOCK_DEBUGGING Kconfig option to turn on all the lock debugging options except the selftests and the torture tests. For what purpose? I'm not sure we want yet another config debug option. These are all expert level configuration and

Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

On Tue, 27 Mar 2018, Wanpeng Li wrote: The host admin can control it by qemu command-line, -cpu ...+kvm-hint-dedicated So this requires qemu code modification, no?

Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

On Tue, 27 Mar 2018, Wanpeng Li wrote: The host admin can control it by qemu command-line, -cpu ...+kvm-hint-dedicated So this requires qemu code modification, no?

Re: [PATCH v2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On Tue, 27 Mar 2018, Waiman Long wrote: I can add a patch to rework lock debugging configuration code. D Please in the same patch, just a v3. Thanks Davidlohr

Re: [PATCH v2] locking/rwsem: Add DEBUG_RWSEMS to look for lock/unlock mismatches

On Tue, 27 Mar 2018, Waiman Long wrote: I can add a patch to rework lock debugging configuration code. D Please in the same patch, just a v3. Thanks Davidlohr

Re: [PATCH 5/6] net/ipv4: Update ip_tunnel_metadata_cnt static key to modern api

On Tue, 27 Mar 2018, David Miller wrote: From: Davidlohr Bueso <d...@stgolabs.net> Date: Mon, 26 Mar 2018 14:09:28 -0700 No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key

Re: [PATCH 5/6] net/ipv4: Update ip_tunnel_metadata_cnt static key to modern api

On Tue, 27 Mar 2018, David Miller wrote: From: Davidlohr Bueso Date: Mon, 26 Mar 2018 14:09:28 -0700 No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Added a '_key

[tip:sched/core] sched/core: Update preempt_notifier_key to modern API

Commit-ID: b720342849fe685310fca01748a32730a6eca5aa Gitweb: https://git.kernel.org/tip/b720342849fe685310fca01748a32730a6eca5aa Author: Davidlohr Bueso <d...@stgolabs.net> AuthorDate: Mon, 26 Mar 2018 14:09:26 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:sched/core] sched/core: Update preempt_notifier_key to modern API

Commit-ID: b720342849fe685310fca01748a32730a6eca5aa Gitweb: https://git.kernel.org/tip/b720342849fe685310fca01748a32730a6eca5aa Author: Davidlohr Bueso AuthorDate: Mon, 26 Mar 2018 14:09:26 -0700 Committer: Ingo Molnar CommitDate: Tue, 27 Mar 2018 07:51:45 +0200 sched/core: Update

[tip:perf/core] perf/x86: Update rdpmc_always_available static key to the modern API

Commit-ID: 631fe154edb0a37308d0116a0f9b7bba9dca6218 Gitweb: https://git.kernel.org/tip/631fe154edb0a37308d0116a0f9b7bba9dca6218 Author: Davidlohr Bueso <d...@stgolabs.net> AuthorDate: Mon, 26 Mar 2018 14:09:27 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:perf/core] perf/x86: Update rdpmc_always_available static key to the modern API

Commit-ID: 631fe154edb0a37308d0116a0f9b7bba9dca6218 Gitweb: https://git.kernel.org/tip/631fe154edb0a37308d0116a0f9b7bba9dca6218 Author: Davidlohr Bueso AuthorDate: Mon, 26 Mar 2018 14:09:27 -0700 Committer: Ingo Molnar CommitDate: Tue, 27 Mar 2018 07:53:00 +0200 perf/x86: Update

Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

On Mon, 26 Mar 2018, Wanpeng Li wrote: I didn't see any issue when testing this patch, could you elaborate what's the bulky mechanism and how it conflicts with early smp bootup stages? In addition, do you mean the xen fix is also not suitable? I have nothing against your patch (or the xen one

Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

On Mon, 26 Mar 2018, Wanpeng Li wrote: I didn't see any issue when testing this patch, could you elaborate what's the bulky mechanism and how it conflicts with early smp bootup stages? In addition, do you mean the xen fix is also not suitable? I have nothing against your patch (or the xen one

[PATCH 4/6] perf,x86: Update rdpmc_always_available static key to modern api

No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Added a '_key' suffix to rdpmc_always_available, for better self documentation. Signed-off-by: Davidlohr Bueso <

[PATCH 4/6] perf,x86: Update rdpmc_always_available static key to modern api

No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Added a '_key' suffix to rdpmc_always_available, for better self documentation. Signed-off-by: Davidlohr Bueso --- arch

[PATCH 2/6] drivers/irqchip: Update supports_deactivate static key to modern api

the more proper static_branch_disable() construct. Also added a '_key' suffix to supports_deactivate, for better self documentation. Cc: Thomas Gleixner <t...@linutronix.de> Cc: Jason Cooper <ja...@lakedaemon.net> Cc: Marc Zyngier <marc.zyng...@arm.com> Signed-off-by: Davidlohr Bue

[PATCH 2/6] drivers/irqchip: Update supports_deactivate static key to modern api

the more proper static_branch_disable() construct. Also added a '_key' suffix to supports_deactivate, for better self documentation. Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Signed-off-by: Davidlohr Bueso --- drivers/irqchip/irq-gic-v3.c | 20 ++-- drivers/irqchip/irq

[PATCH 5/6] net/ipv4: Update ip_tunnel_metadata_cnt static key to modern api

c: net...@vger.kernel.org Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- include/net/ip_tunnels.h | 4 ++-- net/ipv4/ip_tunnel_core.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h index 540a4b4417bf..fc494b4

[PATCH 5/6] net/ipv4: Update ip_tunnel_metadata_cnt static key to modern api

Signed-off-by: Davidlohr Bueso --- include/net/ip_tunnels.h | 4 ++-- net/ipv4/ip_tunnel_core.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h index 540a4b4417bf..fc494b48a64a 100644 --- a/include/net/ip_tunnels.h +++ b

[PATCH 6/6] net/sock: Update memalloc_socks static key to modern api

c: net...@vger.kernel.org Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- include/net/sock.h | 4 ++-- net/core/sock.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/net/sock.h b/include/net/sock.h index 8c428c6847af..15d676365743 100644 --- a

[PATCH 6/6] net/sock: Update memalloc_socks static key to modern api

Signed-off-by: Davidlohr Bueso --- include/net/sock.h | 4 ++-- net/core/sock.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/net/sock.h b/include/net/sock.h index 8c428c6847af..15d676365743 100644 --- a/include/net/sock.h +++ b/include/net/sock.h

[PATCH v2 -next 0/6] update static key users to modern api

that the irqchip was also changed to not use refcounting functions as it only 'disables' the feature. Applies on today's -next. Compile-tested. Thanks! Davidlohr Bueso (6): drivers/i2c: Update i2c_trace_msg static key to modern api drivers/irqchip: Update supports_deactivate static key to modern api

[PATCH v2 -next 0/6] update static key users to modern api

that the irqchip was also changed to not use refcounting functions as it only 'disables' the feature. Applies on today's -next. Compile-tested. Thanks! Davidlohr Bueso (6): drivers/i2c: Update i2c_trace_msg static key to modern api drivers/irqchip: Update supports_deactivate static key to modern api

[PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

linux-...@vger.kernel.org Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- drivers/i2c/i2c-core-base.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 16a3b73375a6..bfcff2a6f0a3 100644 --- a/dri

[PATCH 1/6] drivers/i2c: Update i2c_trace_msg static key to modern api

Signed-off-by: Davidlohr Bueso --- drivers/i2c/i2c-core-base.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 16a3b73375a6..bfcff2a6f0a3 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c

[PATCH 3/6] sched/core: Update preempt_notifier_key to modern api

No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- kernel/sched/core.c | 12 ++-- 1 file changed, 6 inse

[PATCH 3/6] sched/core: Update preempt_notifier_key to modern api

No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Signed-off-by: Davidlohr Bueso --- kernel/sched/core.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions

Re: [PATCH 2/3] drivers/irqchip: update supports_deactivate static key to modern api

On Mon, 26 Mar 2018, Marc Zyngier wrote: Odd. I don't see how you can avoid this failure at link time... yeah, I must have only compiled drivers/ or drivers/irqchip/. Had I done a full build, I would have realized that I left out all the static definitions Peter pointed out. Sending a v2.

Re: [PATCH 2/3] drivers/irqchip: update supports_deactivate static key to modern api

On Mon, 26 Mar 2018, Marc Zyngier wrote: Odd. I don't see how you can avoid this failure at link time... yeah, I must have only compiled drivers/ or drivers/irqchip/. Had I done a full build, I would have realized that I left out all the static definitions Peter pointed out. Sending a v2.

Re: [PATCH 2/3] drivers/irqchip: update supports_deactivate static key to modern api

On Mon, 26 Mar 2018, Marc Zyngier wrote: static struct gic_chip_data gic_data __read_mostly; -static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE; +DEFINE_STATIC_KEY_TRUE(supports_deactivate_key); When you combine this... [...] diff --git a/drivers/irqchip/irq-gic.c

Re: [PATCH 2/3] drivers/irqchip: update supports_deactivate static key to modern api

On Mon, 26 Mar 2018, Marc Zyngier wrote: static struct gic_chip_data gic_data __read_mostly; -static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE; +DEFINE_STATIC_KEY_TRUE(supports_deactivate_key); When you combine this... [...] diff --git a/drivers/irqchip/irq-gic.c

Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

On Sat, 24 Mar 2018, Wanpeng Li wrote: Note: Peterz pointed out in the IRC we have to audit all the architectures that implement smp_prepare_boot_cpu() to see what they depend on if we want to move jump_label_init() before smp_prepare_boot_cpu(). So what this patch does is similar to the issue

Re: [PATCH 1/2] KVM: X86: Fix setup the virt_spin_lock_key before static key get initialized

On Sat, 24 Mar 2018, Wanpeng Li wrote: Note: Peterz pointed out in the IRC we have to audit all the architectures that implement smp_prepare_boot_cpu() to see what they depend on if we want to move jump_label_init() before smp_prepare_boot_cpu(). So what this patch does is similar to the issue

[PATCH 1/3] i2c: update i2c_trace_msg static key to modern api

linux-...@vger.kernel.org Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- drivers/i2c/i2c-core-base.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 16a3b73375a6..c8461fb26c0d 100644 --- a/dri

[PATCH 1/3] i2c: update i2c_trace_msg static key to modern api

Signed-off-by: Davidlohr Bueso --- drivers/i2c/i2c-core-base.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 16a3b73375a6..c8461fb26c0d 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c

[PATCH 3/3] sched/core: update preempt_notifier_key to modern api

No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- kernel/sched/core.c | 12 ++-- 1 file changed, 6 inse

[PATCH 3/3] sched/core: update preempt_notifier_key to modern api

No changes in refcount semantics -- key init is false; replace static_key_slow_inc|dec with static_branch_inc|dec static_key_false with static_branch_unlikely Signed-off-by: Davidlohr Bueso --- kernel/sched/core.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions

[PATCH 2/3] drivers/irqchip: update supports_deactivate static key to modern api

the more proper static_branch_disable() construct. Also added a '_key' suffix to supports_deactivate, for better self documentation. Cc: Thomas Gleixner <t...@linutronix.de> Cc: Jason Cooper <ja...@lakedaemon.net> Cc: Marc Zyngier <marc.zyng...@arm.com> Signed-off-by: Da

[PATCH 2/3] drivers/irqchip: update supports_deactivate static key to modern api

the more proper static_branch_disable() construct. Also added a '_key' suffix to supports_deactivate, for better self documentation. Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Signed-off-by: Davidlohr Bueso --- drivers/irqchip/irq-gic-v3.c | 20 ++-- drivers/irqchip

[PATCH -next 0/3] update some static key users to modern api

Hi, I noticed a few users in the kernel calling stale static key api. Patches are straightforward; note that the irqchip was also changed to not use refcounting functions as it only 'disables' the feature. Thanks! Davidlohr Bueso (3): i2c: update i2c_trace_msg static key to modern api

[PATCH -next 0/3] update some static key users to modern api

Hi, I noticed a few users in the kernel calling stale static key api. Patches are straightforward; note that the irqchip was also changed to not use refcounting functions as it only 'disables' the feature. Thanks! Davidlohr Bueso (3): i2c: update i2c_trace_msg static key to modern api

Re: [PATCH] proc: move /proc/sysvipc creation to where it belongs

On Fri, 16 Feb 2018, Alexey Dobriyan wrote: Signed-off-by: Alexey Dobriyan Acked. However, a small redundant description might be nice. " Move the proc_mkdir() call within the sysvipc subsystem such that we avoid polluting proc_root_init() with petty cpp. " Thanks,

Re: [PATCH] proc: move /proc/sysvipc creation to where it belongs

On Fri, 16 Feb 2018, Alexey Dobriyan wrote: Signed-off-by: Alexey Dobriyan Acked. However, a small redundant description might be nice. " Move the proc_mkdir() call within the sysvipc subsystem such that we avoid polluting proc_root_init() with petty cpp. " Thanks, Davidlohr

Re: [PATCH -next v2 0/3] sysvipc: introduce STAT_ANY commands

On Thu, 15 Feb 2018, Davidlohr Bueso wrote: Once (if) merged, I will submit the necesary manpage updates. But I'm thinking something like: Hi Michael, here are the updated manpage entries. As always, please feel free to modify the descriptions as you see fit. Thanks, Davidlohr

Re: [PATCH -next v2 0/3] sysvipc: introduce STAT_ANY commands

On Thu, 15 Feb 2018, Davidlohr Bueso wrote: Once (if) merged, I will submit the necesary manpage updates. But I'm thinking something like: Hi Michael, here are the updated manpage entries. As always, please feel free to modify the descriptions as you see fit. Thanks, Davidlohr

Re: [PATCH] ia64/err-inject: Use get_user_pages_fast()

Andrew, if you're ok with the patch below, could it be routed your way? Thanks, Davidlohr On Mon, 22 Jan 2018, Davidlohr Bueso wrote: At the point of sysfs callback, the call to gup is done without mmap_sem (or any lock for that matter). This is racy. As such, use the get_user_pages_fast

Re: [PATCH] ia64/err-inject: Use get_user_pages_fast()

Andrew, if you're ok with the patch below, could it be routed your way? Thanks, Davidlohr On Mon, 22 Jan 2018, Davidlohr Bueso wrote: At the point of sysfs callback, the call to gup is done without mmap_sem (or any lock for that matter). This is racy. As such, use the get_user_pages_fast

[PATCH 2/3] ipc/sem: introduce semctl(SEM_STAT_ANY)

ett...@outlook.com> Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- include/uapi/linux/sem.h | 1 + ipc/sem.c | 17 - security/selinux/hooks.c | 1 + security/smack/smack_lsm.c | 1 + 4 files changed, 15 insertions(+), 5 deletions(-) diff --git a/includ

[PATCH 2/3] ipc/sem: introduce semctl(SEM_STAT_ANY)

-by: Davidlohr Bueso --- include/uapi/linux/sem.h | 1 + ipc/sem.c | 17 - security/selinux/hooks.c | 1 + security/smack/smack_lsm.c | 1 + 4 files changed, 15 insertions(+), 5 deletions(-) diff --git a/include/uapi/linux/sem.h b/include/uapi/linux/sem.h index

[PATCH 3/3] ipc/msg: introduce msgctl(MSG_STAT_ANY)

ett...@outlook.com> Signed-off-by: Davidlohr Bueso <dbu...@suse.de> --- include/uapi/linux/msg.h | 1 + ipc/msg.c | 17 - security/selinux/hooks.c | 1 + security/smack/smack_lsm.c | 1 + 4 files changed, 15 insertions(+), 5 deletions(-) diff --git a/includ

[PATCH 3/3] ipc/msg: introduce msgctl(MSG_STAT_ANY)

-by: Davidlohr Bueso --- include/uapi/linux/msg.h | 1 + ipc/msg.c | 17 - security/selinux/hooks.c | 1 + security/smack/smack_lsm.c | 1 + 4 files changed, 15 insertions(+), 5 deletions(-) diff --git a/include/uapi/linux/msg.h b/include/uapi/linux/msg.h index

[PATCH -next v2 0/3] sysvipc: introduce STAT_ANY commands

.I shmid referred to an array slot that is currently unused. Thanks! [1] https://lkml.org/lkml/2017/12/19/220 *** BLURB HERE *** Davidlohr Bueso (3): ipc/shm: introduce shmctl(SHM_STAT_ANY) ipc/sem: introduce semctl(SEM_STAT_ANY) ipc/msg: introduce msgctl(MSG_STAT_ANY) include/uap

[PATCH -next v2 0/3] sysvipc: introduce STAT_ANY commands

.I shmid referred to an array slot that is currently unused. Thanks! [1] https://lkml.org/lkml/2017/12/19/220 *** BLURB HERE *** Davidlohr Bueso (3): ipc/shm: introduce shmctl(SHM_STAT_ANY) ipc/sem: introduce semctl(SEM_STAT_ANY) ipc/msg: introduce msgctl(MSG_STAT_ANY) include/uap

[PATCH 1/3] ipc/shm: introduce shmctl(SHM_STAT_ANY)

such that the shm ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso <dbu...@suse

[PATCH 1/3] ipc/shm: introduce shmctl(SHM_STAT_ANY)

such that the shm ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso --- include/uapi/linux

Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

On Tue, 13 Feb 2018, Andrew Morton wrote: On Tue, 13 Feb 2018 09:41:33 -0800 Davidlohr Bueso <d...@stgolabs.net> wrote: Hi, The following patches adds the discussed[1] new command for shm as well as for sems and msq as they are subject to the same discrepancies for ipc object perm

Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

On Tue, 13 Feb 2018, Andrew Morton wrote: On Tue, 13 Feb 2018 09:41:33 -0800 Davidlohr Bueso wrote: Hi, The following patches adds the discussed[1] new command for shm as well as for sems and msq as they are subject to the same discrepancies for ipc object permission checks between

Re: [PATCH] ia64/err-inject: Use get_user_pages_fast()

ping On Mon, 22 Jan 2018, Davidlohr Bueso wrote: At the point of sysfs callback, the call to gup is done without mmap_sem (or any lock for that matter). This is racy. As such, use the get_user_pages_fast() alternative and safely avoid taking the lock, if possible. Signed-off-by: Davidlohr

Re: [PATCH] ia64/err-inject: Use get_user_pages_fast()

ping On Mon, 22 Jan 2018, Davidlohr Bueso wrote: At the point of sysfs callback, the call to gup is done without mmap_sem (or any lock for that matter). This is racy. As such, use the get_user_pages_fast() alternative and safely avoid taking the lock, if possible. Signed-off-by: Davidlohr

Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

On Tue, 13 Feb 2018, Eric W. Biederman wrote: Davidlohr Bueso <d...@stgolabs.net> writes: Hi, The following patches adds the discussed[1] new command for shm as well as for sems and msq as they are subject to the same discrepancies for ipc object permission checks between the syscall a

Re: [PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

On Tue, 13 Feb 2018, Eric W. Biederman wrote: Davidlohr Bueso writes: Hi, The following patches adds the discussed[1] new command for shm as well as for sems and msq as they are subject to the same discrepancies for ipc object permission checks between the syscall and via procfs. These new

[PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

fP is not a valid command. Or: for a -.B SHM_STAT +.B SHM_STAT/SHM_STAT_ALL operation, the index value specified in .I shmid referred to an array slot that is currently unused. Thanks! [1] https://lkml.org/lkml/2017/12/19/220 Davidlohr Bueso (3): ipc/shm: introduce shmctl(SHM_STAT_A

[PATCH -next 0/3] sysvipc: introduce STAT_ALL commands

fP is not a valid command. Or: for a -.B SHM_STAT +.B SHM_STAT/SHM_STAT_ALL operation, the index value specified in .I shmid referred to an array slot that is currently unused. Thanks! [1] https://lkml.org/lkml/2017/12/19/220 Davidlohr Bueso (3): ipc/shm: introduce shmctl(SHM_STAT_A

[PATCH 3/3] ipc/msg: introduce shmctl(MSG_STAT_ALL)

such that the msq ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso <dbu...@suse

[PATCH 3/3] ipc/msg: introduce shmctl(MSG_STAT_ALL)

such that the msq ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso --- include/uapi

[PATCH 2/3] ipc/sem: introduce shmctl(SEM_STAT_ALL)

such that the sem ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso <dbu...@suse

[PATCH 2/3] ipc/sem: introduce shmctl(SEM_STAT_ALL)

such that the sem ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso --- include/uapi

[PATCH 1/3] ipc/shm: introduce shmctl(SHM_STAT_ALL)

such that the shm ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso <dbu...@suse

[PATCH 1/3] ipc/shm: introduce shmctl(SHM_STAT_ALL)

such that the shm ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Signed-off-by: Davidlohr Bueso --- include/uapi/linux

<    2   3   4   5   6   7   8   9   10   11   >