[PATCH 2/3] sched/preempt: include asm/current.h

*)current) Signed-off-by: Heiko Carstens --- include/asm-generic/preempt.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/asm-generic/preempt.h b/include/asm-generic/preempt.h index c1cde3577551..66fcd6cd7fc6 100644 --- a/include/asm-generic/preempt.h +++ b/include/asm-generic/preempt.h

[PATCH 1/3] sched/core,x86: make struct thread_info arch specific again

Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- arch/x86/include/asm/thread_info.h | 9 + include/linux/thread_info.h| 11 --- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thr

[PATCH 1/3] sched/core,x86: make struct thread_info arch specific again

Signed-off-by: Heiko Carstens --- arch/x86/include/asm/thread_info.h | 9 + include/linux/thread_info.h| 11 --- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h index 2aaca53c0974..ad

[PATCH 0/3] THREAD_INFO_IN_TASK_STRUCT vs generic preemption code

The above is actually the same as the description of the first patch. The second patch is a simple compile fix and the third one the s390 conversion to THREAD_INFO_IN_TASK_STRUCT. Heiko Carstens (3): sched/core,x86: make struct thread_info arch specific again sched/preempt: include asm/current.h

[PATCH 0/3] THREAD_INFO_IN_TASK_STRUCT vs generic preemption code

The above is actually the same as the description of the first patch. The second patch is a simple compile fix and the third one the s390 conversion to THREAD_INFO_IN_TASK_STRUCT. Heiko Carstens (3): sched/core,x86: make struct thread_info arch specific again sched/preempt: include asm/current.h

Re: [PATCH] s390: cleanup with list_first_entry_or_null()

On Tue, Sep 13, 2016 at 03:10:39AM +0900, Masahiro Yamada wrote: > The combo of list_empty() check and return list_first_entry() > can be replaced with list_first_entry_or_null(). > > Signed-off-by: Masahiro Yamada > --- > > arch/s390/kernel/crash_dump.c | 5

Re: [PATCH] s390: cleanup with list_first_entry_or_null()

On Tue, Sep 13, 2016 at 03:10:39AM +0900, Masahiro Yamada wrote: > The combo of list_empty() check and return list_first_entry() > can be replaced with list_first_entry_or_null(). > > Signed-off-by: Masahiro Yamada > --- > > arch/s390/kernel/crash_dump.c | 5 ++--- > 1 file changed, 2

Re: [PATCH 1/2] ubsan: allow to disable the null sanitizer

On Mon, Sep 12, 2016 at 02:37:19PM +0200, Christian Borntraeger wrote: > Some architectures use a hardware defined struct at address zero. > Checking for a null pointer will result in many ubsan reports. > Let users disable the null sanitizer. > > Signed-off-by: Christian Borntraeger

Re: [PATCH 1/2] ubsan: allow to disable the null sanitizer

On Mon, Sep 12, 2016 at 02:37:19PM +0200, Christian Borntraeger wrote: > Some architectures use a hardware defined struct at address zero. > Checking for a null pointer will result in many ubsan reports. > Let users disable the null sanitizer. > > Signed-off-by: Christian Borntraeger > --- >

Re: [PATCH] uprobes: remove function declarations from arch/{mips,s390}

it this patch into two patches (mips/s390) so it can be applied to the different architecture trees, or send it as single patch to Andrew Morton, so he can pick it. In any case: Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com> > > diff --git a/arch/mips/include/asm/uprobes.h b

Re: [PATCH] uprobes: remove function declarations from arch/{mips,s390}

ips/s390) so it can be applied to the different architecture trees, or send it as single patch to Andrew Morton, so he can pick it. In any case: Acked-by: Heiko Carstens > > diff --git a/arch/mips/include/asm/uprobes.h b/arch/mips/include/asm/uprobes.h > index 34c325c..28ab364 100644 > ---

Re: [PATCH] s390: Remove deprecated create_singlethread_workqueue

On Wed, Aug 31, 2016 at 10:31:10AM -0400, Tejun Heo wrote: > On Wed, Aug 31, 2016 at 01:57:20AM +0530, Bhaktipriya Shridhar wrote: > > The workqueue "appldata_wq" has been replaced with an ordered dedicated > > workqueue. > > > > WQ_MEM_RECLAIM has not been set since the workqueue is not being

Re: [PATCH] s390: Remove deprecated create_singlethread_workqueue

On Wed, Aug 31, 2016 at 10:31:10AM -0400, Tejun Heo wrote: > On Wed, Aug 31, 2016 at 01:57:20AM +0530, Bhaktipriya Shridhar wrote: > > The workqueue "appldata_wq" has been replaced with an ordered dedicated > > workqueue. > > > > WQ_MEM_RECLAIM has not been set since the workqueue is not being

Re: [PATCH] s390/hypfs: Use kmalloc_array() in diag0c_store()

On Thu, Sep 01, 2016 at 11:38:15AM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 1 Sep 2016 11:30:58 +0200 > > A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. >

Re: [PATCH] s390/hypfs: Use kmalloc_array() in diag0c_store()

On Thu, Sep 01, 2016 at 11:38:15AM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 1 Sep 2016 11:30:58 +0200 > > A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote: > Hello, Peter. > > On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote: > > > As long as the mapping doesn't change after the first onlining of the > > > CPU, the

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

On Tue, Aug 16, 2016 at 11:42:05AM -0400, Tejun Heo wrote: > Hello, Peter. > > On Tue, Aug 16, 2016 at 05:29:49PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 16, 2016 at 11:20:27AM -0400, Tejun Heo wrote: > > > As long as the mapping doesn't change after the first onlining of the > > > CPU, the

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Hi Tejun, > On Mon, Aug 15, 2016 at 01:19:08PM +0200, Heiko Carstens wrote: > > I can imagine several ways to fix this for s390, but before doing that I'm > > wondering if the workqueue code is correct with > > > > a) assuming that the cpu_to_node() mapping is va

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Hi Tejun, > On Mon, Aug 15, 2016 at 01:19:08PM +0200, Heiko Carstens wrote: > > I can imagine several ways to fix this for s390, but before doing that I'm > > wondering if the workqueue code is correct with > > > > a) assuming that the cpu_to_node() mapping is va

Re: commit 444d13ff10f introduced boot failure on s390x

the page table anyway and ends up setting > a normally writable page to ro. Adding a simple numpages == 0 check > to set_memory_{ro,rw} and returning fixes the panic. > > Jessica All what you write is correct. The patch below is sitting in our "fixes" branch since a wee

Re: commit 444d13ff10f introduced boot failure on s390x

Adding a simple numpages == 0 check > to set_memory_{ro,rw} and returning fixes the panic. > > Jessica All what you write is correct. The patch below is sitting in our "fixes" branch since a week: https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/log/?h=fixes I assume there will be a pull requ

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

On Mon, Aug 08, 2016 at 03:45:05PM +0800, Ming Lei wrote: > On Sat, Jul 30, 2016 at 7:25 PM, Heiko Carstens > <heiko.carst...@de.ibm.com> wrote: > > On Wed, Jul 27, 2016 at 05:23:05PM +0200, Thomas Gleixner wrote: > >> On Wed, 27 Jul 2016, Heiko Carstens

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

On Mon, Aug 08, 2016 at 03:45:05PM +0800, Ming Lei wrote: > On Sat, Jul 30, 2016 at 7:25 PM, Heiko Carstens > wrote: > > On Wed, Jul 27, 2016 at 05:23:05PM +0200, Thomas Gleixner wrote: > >> On Wed, 27 Jul 2016, Heiko Carstens wrote: > >> > [3.162961] ([<00

Re: [PATCH 0875/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 07:54:12PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro,

Re: [PATCH 0875/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 07:54:12PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro,

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

On Wed, Jul 27, 2016 at 05:23:05PM +0200, Thomas Gleixner wrote: > On Wed, 27 Jul 2016, Heiko Carstens wrote: > > [3.162961] ([<00176c30>] select_task_rq+0xc0/0x1a8) > > [3.162963] ([<00177d64>] try_to_wake_up+0x2e4/0x478) > > [

Re: [bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

On Wed, Jul 27, 2016 at 05:23:05PM +0200, Thomas Gleixner wrote: > On Wed, 27 Jul 2016, Heiko Carstens wrote: > > [3.162961] ([<00176c30>] select_task_rq+0xc0/0x1a8) > > [3.162963] ([<00177d64>] try_to_wake_up+0x2e4/0x478) > > [

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Thu, Jul 28, 2016 at 07:55:48AM +0200, Heiko Carstens wrote: > On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote: > > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > > > it looks like your patch "random: make /dev/urandom scalable for silly &

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Thu, Jul 28, 2016 at 07:55:48AM +0200, Heiko Carstens wrote: > On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote: > > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > > > it looks like your patch "random: make /dev/urandom scalable for silly &

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote: > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > > it looks like your patch "random: make /dev/urandom scalable for silly > > userspace programs" within linux-next seems to be a bit b

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Wed, Jul 27, 2016 at 11:46:01PM -0400, Theodore Ts'o wrote: > On Wed, Jul 27, 2016 at 09:14:00AM +0200, Heiko Carstens wrote: > > it looks like your patch "random: make /dev/urandom scalable for silly > > userspace programs" within linux-next seems to be a bit b

[bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Hi Peter, I get the following warning on s390 when using fake NUMA beginning with your patch e9d867a67fd0 "sched: Allow per-cpu kernel threads to run on online && !active" [3.162909] WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:121 select_task_rq+0xe6/0x1a8 [3.162911] Modules

[bisected] "sched: Allow per-cpu kernel threads to run on online && !active" causes warning

Hi Peter, I get the following warning on s390 when using fake NUMA beginning with your patch e9d867a67fd0 "sched: Allow per-cpu kernel threads to run on online && !active" [3.162909] WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:121 select_task_rq+0xe6/0x1a8 [3.162911] Modules

[BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

Hi Ted, it looks like your patch "random: make /dev/urandom scalable for silly userspace programs" within linux-next seems to be a bit broken: It causes this allocation failure and subsequent crash on s390 with fake NUMA enabled: [0.533195] SLUB: Unable to allocate memory on node 1,

[BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

Hi Ted, it looks like your patch "random: make /dev/urandom scalable for silly userspace programs" within linux-next seems to be a bit broken: It causes this allocation failure and subsequent crash on s390 with fake NUMA enabled: [0.533195] SLUB: Unable to allocate memory on node 1,

Re: Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

On Tue, Jul 19, 2016 at 10:25:42AM +0200, Christian Borntraeger wrote: > On 07/19/2016 01:47 AM, Andy Lutomirski wrote: > > Hi all- > > > > There are four core patches needed for the THREAD_INFO_IN_TASK thing, > > and they apply cleanly to -mm now. The x86 patch to flip the feature > > on does

Re: Is THREAD_INFO_IN_TASK appropriate for -mm for 4.8?

On Tue, Jul 19, 2016 at 10:25:42AM +0200, Christian Borntraeger wrote: > On 07/19/2016 01:47 AM, Andy Lutomirski wrote: > > Hi all- > > > > There are four core patches needed for the THREAD_INFO_IN_TASK thing, > > and they apply cleanly to -mm now. The x86 patch to flip the feature > > on does

Re: linux-next: manual merge of the kvm tree with the s390 tree

On Wed, Jun 29, 2016 at 02:36:58PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvm tree got a conflict in: > > arch/s390/hypfs/hypfs_diag.c > > between commit: > > e030c1125eab ("s390/hypfs: use basic block for diag inline assembly") > > from the s390 tree

Re: linux-next: manual merge of the kvm tree with the s390 tree

On Wed, Jun 29, 2016 at 02:36:58PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvm tree got a conflict in: > > arch/s390/hypfs/hypfs_diag.c > > between commit: > > e030c1125eab ("s390/hypfs: use basic block for diag inline assembly") > > from the s390 tree

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote: > On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: > > +++ b/include/linux/sched.h > > @@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct > > *p, unsigned int cpu) > > > > #endif /* CONFIG_SMP */

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote: > On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: > > +++ b/include/linux/sched.h > > @@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct > > *p, unsigned int cpu) > > > > #endif /* CONFIG_SMP */

Re: linux-next: manual merge of the audit tree with the security tree

On Fri, Jun 24, 2016 at 12:20:52PM -0400, Paul Moore wrote: > > I'm a bit concerned about user space pointers passed as argument for compat > > tasks. These need to mask out 33 instead of 32 bits. This is of course > > system call specific and I don't know enough about audit to tell if it > >

Re: linux-next: manual merge of the audit tree with the security tree

On Fri, Jun 24, 2016 at 12:20:52PM -0400, Paul Moore wrote: > > I'm a bit concerned about user space pointers passed as argument for compat > > tasks. These need to mask out 33 instead of 32 bits. This is of course > > system call specific and I don't know enough about audit to tell if it > >

Re: linux-next: manual merge of the audit tree with the security tree

On Fri, Jun 24, 2016 at 11:05:33AM -0400, Paul Moore wrote: > >> >> + audit_syscall_entry(regs->gprs[2], regs->orig_gpr2 & mask, > >> >> + regs->gprs[3] & mask, regs->gprs[4] & mask, > >> >> + regs->gprs[5] & mask); > >> > > >> > With these masks

Re: linux-next: manual merge of the audit tree with the security tree

On Fri, Jun 24, 2016 at 11:05:33AM -0400, Paul Moore wrote: > >> >> + audit_syscall_entry(regs->gprs[2], regs->orig_gpr2 & mask, > >> >> + regs->gprs[3] & mask, regs->gprs[4] & mask, > >> >> + regs->gprs[5] & mask); > >> > > >> > With these masks

Re: linux-next: manual merge of the audit tree with the security tree

On Thu, Jun 23, 2016 at 12:14:11PM -0400, Paul Moore wrote: > On Thu, Jun 23, 2016 at 2:01 AM, Heiko Carstens > <heiko.carst...@de.ibm.com> wrote: > > On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote: > >> Hi Paul, > >> > >> Today's linu

Re: linux-next: manual merge of the audit tree with the security tree

On Thu, Jun 23, 2016 at 12:14:11PM -0400, Paul Moore wrote: > On Thu, Jun 23, 2016 at 2:01 AM, Heiko Carstens > wrote: > > On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote: > >> Hi Paul, > >> > >> Today's linux-next merge of the audit tree g

Re: linux-next: manual merge of the audit tree with the security tree

On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote: > Hi Paul, > > Today's linux-next merge of the audit tree got a conflict in: > > arch/s390/kernel/ptrace.c > > between commit: > > 0208b9445bc0 ("s390/ptrace: run seccomp after ptrace") > > from the security tree and

Re: linux-next: manual merge of the audit tree with the security tree

On Thu, Jun 23, 2016 at 02:18:14PM +1000, Stephen Rothwell wrote: > Hi Paul, > > Today's linux-next merge of the audit tree got a conflict in: > > arch/s390/kernel/ptrace.c > > between commit: > > 0208b9445bc0 ("s390/ptrace: run seccomp after ptrace") > > from the security tree and

Re: [PATCH] scripts/bloat-o-meter: fix percent change output

On Tue, Jun 21, 2016 at 08:00:05AM +, Vineet Gupta wrote: > Hi Heiko, > > On Tuesday 21 June 2016 01:10 PM, Heiko Carstens wrote: > > commit b21e91c305bc "scripts/bloat-o-meter: print percent change" > > introduced an additional line to the output of the bloat

Re: [PATCH] scripts/bloat-o-meter: fix percent change output

On Tue, Jun 21, 2016 at 08:00:05AM +, Vineet Gupta wrote: > Hi Heiko, > > On Tuesday 21 June 2016 01:10 PM, Heiko Carstens wrote: > > commit b21e91c305bc "scripts/bloat-o-meter: print percent change" > > introduced an additional line to the output of the bloat

[PATCH] scripts/bloat-o-meter: fix percent change output

+6 Total: Before=24794284, After=24794308, chg 0.97% Cc: Vineet Gupta <vineet.gup...@synopsys.com> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- scripts/bloat-o-meter | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/bloat-o-meter b/scripts/

[PATCH] scripts/bloat-o-meter: fix percent change output

+6 Total: Before=24794284, After=24794308, chg 0.97% Cc: Vineet Gupta Signed-off-by: Heiko Carstens --- scripts/bloat-o-meter | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/bloat-o-meter b/scripts/bloat-o-meter index 0254f3ba0dba..5a5d383004f5 100755 --- a/scripts

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sun, Jun 19, 2016 at 11:01:48PM -0700, Andy Lutomirski wrote: > > The tmll instruction tests if any of the higher bits within the 16k > > stackframe address are set. In this specific case that would be bits 7-15 > > (mask 0x3f80). If no bit would be set we know that only up to 128 bytes > >

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Sun, Jun 19, 2016 at 11:01:48PM -0700, Andy Lutomirski wrote: > > The tmll instruction tests if any of the higher bits within the 16k > > stackframe address are set. In this specific case that would be bits 7-15 > > (mask 0x3f80). If no bit would be set we know that only up to 128 bytes > >

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 17, 2016 at 10:38:24AM -0700, Andy Lutomirski wrote: > > A disassembly looks like this (r15 is the stackpointer): > > > > 0670 : > > 670: eb 6f f0 48 00 24 stmg%r6,%r15,72(%r15) > > 676: c0 d0 00 00 00 00 larl%r13,676

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 17, 2016 at 10:38:24AM -0700, Andy Lutomirski wrote: > > A disassembly looks like this (r15 is the stackpointer): > > > > 0670 : > > 670: eb 6f f0 48 00 24 stmg%r6,%r15,72(%r15) > > 676: c0 d0 00 00 00 00 larl%r13,676 > > 67c:

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 16, 2016 at 08:58:07PM -0700, Andy Lutomirski wrote: > On Wed, Jun 15, 2016 at 11:05 PM, Heiko Carstens > <heiko.carst...@de.ibm.com> wrote: > > On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: > >> Since the dawn of time, a kernel stack ov

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 16, 2016 at 08:58:07PM -0700, Andy Lutomirski wrote: > On Wed, Jun 15, 2016 at 11:05 PM, Heiko Carstens > wrote: > > On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: > >> Since the dawn of time, a kernel stack overflow has been a real PITA >

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: > Since the dawn of time, a kernel stack overflow has been a real PITA > to debug, has caused nondeterministic crashes some time after the > actual overflow, and has generally been easy to exploit for root. > > With this series,

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: > Since the dawn of time, a kernel stack overflow has been a real PITA > to debug, has caused nondeterministic crashes some time after the > actual overflow, and has generally been easy to exploit for root. > > With this series,

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

w, hope that's ok. [I did not yet add your Ack] >From 74ab0aefe07573358cc6a0c462ddc62ccba4c0cf Mon Sep 17 00:00:00 2001 From: Heiko Carstens <heiko.carst...@de.ibm.com> Date: Fri, 10 Jun 2016 10:40:06 +0200 Subject: [PATCH] s390/oprofile: remove hardware sampler support Remove hardware sampler su

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

w, hope that's ok. [I did not yet add your Ack] >From 74ab0aefe07573358cc6a0c462ddc62ccba4c0cf Mon Sep 17 00:00:00 2001 From: Heiko Carstens Date: Fri, 10 Jun 2016 10:40:06 +0200 Subject: [PATCH] s390/oprofile: remove hardware sampler support Remove hardware sampler support from oprofile module.

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote: > Heiko, > > On 09.06.16 11:00:56, Heiko Carstens wrote: > > However I'm wondering if we shouldn't simply remove at least the s390 > > specific hwswampler code from the oprofile module. This would still leav

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On Mon, Jun 13, 2016 at 06:29:14PM +0200, Robert Richter wrote: > Heiko, > > On 09.06.16 11:00:56, Heiko Carstens wrote: > > However I'm wondering if we shouldn't simply remove at least the s390 > > specific hwswampler code from the oprofile module. This would still leav

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

On Tue, Jun 14, 2016 at 02:51:17PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvms390 tree got a conflict in: > > arch/s390/hypfs/hypfs_diag.c > > between commit: > > 6c22c9863760 ("s390: avoid extable collisions") > > from the s390 tree and commit: > >

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

On Tue, Jun 14, 2016 at 02:51:17PM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the kvms390 tree got a conflict in: > > arch/s390/hypfs/hypfs_diag.c > > between commit: > > 6c22c9863760 ("s390: avoid extable collisions") > > from the s390 tree and commit: > >

Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level

On Mon, Jun 13, 2016 at 01:06:21PM +0200, Peter Zijlstra wrote: > On Wed, Jun 08, 2016 at 11:09:16AM +0200, Heiko Carstens wrote: > > The z13 machine added a fourth level to the cpu topology > > information. The new top level is called drawer. > > > > A drawer con

Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level

On Mon, Jun 13, 2016 at 01:06:21PM +0200, Peter Zijlstra wrote: > On Wed, Jun 08, 2016 at 11:09:16AM +0200, Heiko Carstens wrote: > > The z13 machine added a fourth level to the cpu topology > > information. The new top level is called drawer. > > > > A drawer con

Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level

On Mon, Jun 13, 2016 at 01:06:21PM +0200, Peter Zijlstra wrote: > On Wed, Jun 08, 2016 at 11:09:16AM +0200, Heiko Carstens wrote: > > The z13 machine added a fourth level to the cpu topology > > information. The new top level is called drawer. > > > > A drawer con

Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level

On Mon, Jun 13, 2016 at 01:06:21PM +0200, Peter Zijlstra wrote: > On Wed, Jun 08, 2016 at 11:09:16AM +0200, Heiko Carstens wrote: > > The z13 machine added a fourth level to the cpu topology > > information. The new top level is called drawer. > > > > A drawer con

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On Wed, Jun 08, 2016 at 03:29:12AM +0530, Bhaktipriya Shridhar wrote: > A dedicated workqueue has been used since the workqueue hws_wq with > workitem >worker, is involved in hardware based sampling > on System z processors. > > Since, these are long-running work items and aren't involved in

Re: [PATCH] s390/oprofile: Remove deprecated create_workqueue

On Wed, Jun 08, 2016 at 03:29:12AM +0530, Bhaktipriya Shridhar wrote: > A dedicated workqueue has been used since the workqueue hws_wq with > workitem >worker, is involved in hardware based sampling > on System z processors. > > Since, these are long-running work items and aren't involved in

[PATCH 2/2] s390/topology: add drawer scheduling domain level

to be any workloads impacted in a negative way. Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- arch/s390/Kconfig| 4 arch/s390/include/asm/topology.h | 4 arch/s390/kernel/topology.c | 33 +++-- arch/s390/numa/mode

[PATCH 0/2] s390: introduce drawer scheduling domain

any negative impacts. If this is acceptable I'd like to add these patches to the s390 tree for the next merge window. For reference the z13 machine is described here: www.redbooks.ibm.com/redbooks/pdfs/sg248251.pdf Chapter 2 (or 2.2) gives a brief overview of what I'm talking about. Heiko Cars

[PATCH 2/2] s390/topology: add drawer scheduling domain level

to be any workloads impacted in a negative way. Signed-off-by: Heiko Carstens --- arch/s390/Kconfig| 4 arch/s390/include/asm/topology.h | 4 arch/s390/kernel/topology.c | 33 +++-- arch/s390/numa/mode_emu.c| 25

[PATCH 0/2] s390: introduce drawer scheduling domain

any negative impacts. If this is acceptable I'd like to add these patches to the s390 tree for the next merge window. For reference the z13 machine is described here: www.redbooks.ibm.com/redbooks/pdfs/sg248251.pdf Chapter 2 (or 2.2) gives a brief overview of what I'm talking about. Heiko Cars

[PATCH 1/2] topology/sysfs: provide drawer id and siblings attributes

define and select. These additional attributes will be available: /sys/devices/system/cpu/cpuX/topology/drawer_id /sys/devices/system/cpu/cpuX/topology/drawer_siblings /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.

[PATCH 1/2] topology/sysfs: provide drawer id and siblings attributes

define and select. These additional attributes will be available: /sys/devices/system/cpu/cpuX/topology/drawer_id /sys/devices/system/cpu/cpuX/topology/drawer_siblings /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list Signed-off-by: Heiko Carstens --- Documentation/cputopology.txt | 40

Re: [PATCH 0/2] Proper ro_after_init implementation on s390

On Tue, Jun 07, 2016 at 11:11:17AM -0700, Kees Cook wrote: > On Tue, Jun 7, 2016 at 11:07 AM, Heiko Carstens > <heiko.carst...@de.ibm.com> wrote: > > On Tue, Jun 07, 2016 at 08:49:14AM -0700, Kees Cook wrote: > >> > Heiko Carstens (2): > >> > v

Re: [PATCH 0/2] Proper ro_after_init implementation on s390

On Tue, Jun 07, 2016 at 11:11:17AM -0700, Kees Cook wrote: > On Tue, Jun 7, 2016 at 11:07 AM, Heiko Carstens > wrote: > > On Tue, Jun 07, 2016 at 08:49:14AM -0700, Kees Cook wrote: > >> > Heiko Carstens (2): > >> > vmlinux.lds.h: allow arch spe

Re: [PATCH] KVM: s390: fix build failure

On Wed, Jun 08, 2016 at 07:17:35AM +0200, Christian Borntraeger wrote: > On 06/07/2016 11:49 PM, Sudip Mukherjee wrote: > > etr_ptff definitions are moved and renamed but we missed updating them > > here and as a result s390 defconfig and allmodconfig was failing with > > the error: > >

Re: [PATCH] KVM: s390: fix build failure

On Wed, Jun 08, 2016 at 07:17:35AM +0200, Christian Borntraeger wrote: > On 06/07/2016 11:49 PM, Sudip Mukherjee wrote: > > etr_ptff definitions are moved and renamed but we missed updating them > > here and as a result s390 defconfig and allmodconfig was failing with > > the error: > >

Re: [PATCH 0/2] Proper ro_after_init implementation on s390

On Tue, Jun 07, 2016 at 08:49:14AM -0700, Kees Cook wrote: > > Heiko Carstens (2): > > vmlinux.lds.h: allow arch specific handling of ro_after_init data section > > s390/mm: add proper __ro_after_init support > > > > arch/s390/include/asm/cache.h | 3

Re: [PATCH 0/2] Proper ro_after_init implementation on s390

On Tue, Jun 07, 2016 at 08:49:14AM -0700, Kees Cook wrote: > > Heiko Carstens (2): > > vmlinux.lds.h: allow arch specific handling of ro_after_init data section > > s390/mm: add proper __ro_after_init support > > > > arch/s390/include/asm/cache.h | 3

[PATCH 1/2] vmlinux.lds.h: allow arch specific handling of ro_after_init data section

nly within mark_rodata_ro Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- include/asm-generic/vmlinux.lds.h | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 6a67ab94b553..c44

[PATCH 1/2] vmlinux.lds.h: allow arch specific handling of ro_after_init data section

nly within mark_rodata_ro Signed-off-by: Heiko Carstens --- include/asm-generic/vmlinux.lds.h | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 6a67ab94b553..c4436d072d37 100644 --- a/include/a

[PATCH 2/2] s390/mm: add proper __ro_after_init support

to the __ro_after_init data move also the exception table there, since from a practical point of view it fits the __ro_after_init requirements. Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- arch/s390/include/asm/cache.h| 3 --- arch/s390/include/asm/sections.h | 1 + arc

[PATCH 0/2] Proper ro_after_init implementation on s390

on this solution I'd like to add these patches to the s390 tree, so it can be merged during the next merge window. Heiko Carstens (2): vmlinux.lds.h: allow arch specific handling of ro_after_init data section s390/mm: add proper __ro_after_init support arch/s390/include/asm/cache.h | 3 --- arch/s390

[PATCH 2/2] s390/mm: add proper __ro_after_init support

to the __ro_after_init data move also the exception table there, since from a practical point of view it fits the __ro_after_init requirements. Signed-off-by: Heiko Carstens --- arch/s390/include/asm/cache.h| 3 --- arch/s390/include/asm/sections.h | 1 + arch/s390/kernel/vmlinux.lds.S | 12

[PATCH 0/2] Proper ro_after_init implementation on s390

on this solution I'd like to add these patches to the s390 tree, so it can be merged during the next merge window. Heiko Carstens (2): vmlinux.lds.h: allow arch specific handling of ro_after_init data section s390/mm: add proper __ro_after_init support arch/s390/include/asm/cache.h | 3 --- arch/s390

Re: [lockdep] chain_key collision check triggers

On Fri, Jun 03, 2016 at 10:48:01AM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 09:15:44AM +0200, Heiko Carstens wrote: > > Hi all, > > > > the new lockdep chain_key collision detection code triggers quite reliably > > on s390, so it looks like we need a

Re: [lockdep] chain_key collision check triggers

On Fri, Jun 03, 2016 at 10:48:01AM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 09:15:44AM +0200, Heiko Carstens wrote: > > Hi all, > > > > the new lockdep chain_key collision detection code triggers quite reliably > > on s390, so it looks like we need a

[lockdep] chain_key collision check triggers

Hi all, the new lockdep chain_key collision detection code triggers quite reliably on s390, so it looks like we need a different iterate_chain_key() implementation? Actually there was already another report from Shuah Khan, which didn't get any replies as far as I can tell:

[lockdep] chain_key collision check triggers

Hi all, the new lockdep chain_key collision detection code triggers quite reliably on s390, so it looks like we need a different iterate_chain_key() implementation? Actually there was already another report from Shuah Khan, which didn't get any replies as far as I can tell:

Re: [PATCH 01/23] all: syscall wrappers: add documentation

> > > The cost is pretty trivial though. See kernel/compat_wrapper.o: > > > COMPAT_SYSCALL_WRAP2(creat, const char __user *, pathname, umode_t, mode); > > > 0: a9bf7bfdstp x29, x30, [sp,#-16]! > > > 4: 910003fdmov x29, sp > > > 8: 2a0003e0mov w0, w0 > > >

Re: [PATCH 01/23] all: syscall wrappers: add documentation

> > > The cost is pretty trivial though. See kernel/compat_wrapper.o: > > > COMPAT_SYSCALL_WRAP2(creat, const char __user *, pathname, umode_t, mode); > > > 0: a9bf7bfdstp x29, x30, [sp,#-16]! > > > 4: 910003fdmov x29, sp > > > 8: 2a0003e0mov w0, w0 > > >

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote: > From: Yury Norov > Date: Tue, 24 May 2016 03:04:30 +0300 > > > +To clear that top halves, automatic wrappers are introduced. They clear all > > +required registers before passing control to regular syscall

Re: [PATCH 01/23] all: syscall wrappers: add documentation

On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote: > From: Yury Norov > Date: Tue, 24 May 2016 03:04:30 +0300 > > > +To clear that top halves, automatic wrappers are introduced. They clear all > > +required registers before passing control to regular syscall handler. > > Why have one

Re: [PATCH v2] ks390/keyboard: use memdup_user_nul().

On Fri, May 20, 2016 at 06:51:20PM +0530, Muhammad Falak R Wani wrote: > Use memdup_user_nul to duplicate a memory region from user-space > to kernel-space and terminate with a NULL, instead of open coding > using kmalloc + copy_from_user and explicitly NULL terminating. > > Signed-off-by:

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