Re: [PATCH] s390: char: sclp_async.c: Cleaning up missing null-terminate in conjunction with strncpy

2014-07-28 Thread Heiko Carstens
On Sat, Jul 26, 2014 at 04:30:47PM +0200, Rickard Strandqvist wrote: Replacing strncpy with strlcpy to avoid strings that lacks null terminate. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/s390/char/sclp_async.c |4 ++-- 1 file changed, 2

Re: fs: use after free in /proc/pid/mountinfo

2014-07-09 Thread Heiko Carstens
asha could confirm that reverting the patch actually does fix the crash, please revert the commit, unless somebody else can make sense of the report of course. I'm still wondering how Sasha could reproduce the crash. Thanks, Heiko On Sun, Jul 06, 2014 at 12:04:20PM +0200, Heiko Carstens wrote: > O

Re: fs: use after free in /proc/pid/mountinfo

2014-07-09 Thread Heiko Carstens
that reverting the patch actually does fix the crash, please revert the commit, unless somebody else can make sense of the report of course. I'm still wondering how Sasha could reproduce the crash. Thanks, Heiko On Sun, Jul 06, 2014 at 12:04:20PM +0200, Heiko Carstens wrote: On Fri, Jul 04, 2014

Re: [PATCH] s390: add support for DYNAMIC_FTRACE_WITH_REGS

2014-07-08 Thread Heiko Carstens
On Thu, Jul 03, 2014 at 02:00:46PM +0200, Vojtech Pavlik wrote: > Add support for DYNAMIC_FTRACE_WITH_REGS to 64-bit and 31-bit s390 > architectures. This is required for kGraft and kpatch to work on s390. > > It's done by adding a _regs variant of ftrace_caller that preserves > registers and

Re: [PATCH] s390: add support for DYNAMIC_FTRACE_WITH_REGS

2014-07-08 Thread Heiko Carstens
On Thu, Jul 03, 2014 at 02:00:46PM +0200, Vojtech Pavlik wrote: Add support for DYNAMIC_FTRACE_WITH_REGS to 64-bit and 31-bit s390 architectures. This is required for kGraft and kpatch to work on s390. It's done by adding a _regs variant of ftrace_caller that preserves registers and puts

Re: Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel

2014-07-07 Thread Heiko Carstens
On Mon, Jul 07, 2014 at 03:54:37PM +0200, Helge Deller wrote: > Hi Heiko, > > So for sys_fanotify_mark everything is fine on s390, and probably most other > > architectures as well. Having a 64 bit syscall parameter indeed does work, > > if all the architecture specific details have been correctly

Re: Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel

2014-07-07 Thread Heiko Carstens
On Mon, Jul 07, 2014 at 03:54:37PM +0200, Helge Deller wrote: Hi Heiko, So for sys_fanotify_mark everything is fine on s390, and probably most other architectures as well. Having a 64 bit syscall parameter indeed does work, if all the architecture specific details have been correctly

Re: fs: use after free in /proc/pid/mountinfo

2014-07-06 Thread Heiko Carstens
On Fri, Jul 04, 2014 at 10:55:13AM -0400, Sasha Levin wrote: > On 07/03/2014 05:37 PM, David Rientjes wrote: > > On Wed, 2 Jul 2014, Sasha Levin wrote: > > > >>> Hi all, > >>> > >>> While fuzzing with trinity inside a KVM tools guest running the latest > >>> -next > >>> kernel I've stumbled on

Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel

2014-07-06 Thread Heiko Carstens
On Fri, Jul 04, 2014 at 05:12:35PM +0200, Helge Deller wrote: > This patch affects big endian architectures only. > > On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the > 64bit mask parameter is correctly constructed out of two 32bit values in > the compat_fanotify_mark()

Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel

2014-07-06 Thread Heiko Carstens
On Fri, Jul 04, 2014 at 05:12:35PM +0200, Helge Deller wrote: This patch affects big endian architectures only. On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the 64bit mask parameter is correctly constructed out of two 32bit values in the compat_fanotify_mark() function

Re: fs: use after free in /proc/pid/mountinfo

2014-07-06 Thread Heiko Carstens
On Fri, Jul 04, 2014 at 10:55:13AM -0400, Sasha Levin wrote: On 07/03/2014 05:37 PM, David Rientjes wrote: On Wed, 2 Jul 2014, Sasha Levin wrote: Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on the following spew: [

Re: [RFA][PATCH 26/27] s390/ftrace: remove check of obsolete variable function_trace_stop

2014-06-27 Thread Heiko Carstens
hes, I think. But they don't apply against Linus' master tree and I wouldn't know which tree these patches are against. But anyway, it all looks good ;) Acked-by: Heiko Carstens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord..

Re: [RFA][PATCH 26/27] s390/ftrace: remove check of obsolete variable function_trace_stop

2014-06-27 Thread Heiko Carstens
. But they don't apply against Linus' master tree and I wouldn't know which tree these patches are against. But anyway, it all looks good ;) Acked-by: Heiko Carstens heiko.carst...@de.ibm.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [PATCH] arch,locking: Ciao arch_mutex_cpu_relax()

2014-06-25 Thread Heiko Carstens
On Tue, Jun 24, 2014 at 08:06:55AM -0700, Davidlohr Bueso wrote: > On Mon, 2014-06-23 at 08:58 +0200, Peter Zijlstra wrote: > > While I like the general idea; does anyone have a better name for this? > > So in particular, the difference is that on s390: > > > > cpu_relax()-

Re: [PATCH 0/2] /proc/stat vs. failed order-4 allocation

2014-06-25 Thread Heiko Carstens
On Tue, Jun 24, 2014 at 04:52:22PM -0700, David Rientjes wrote: > On Mon, 23 Jun 2014, Andrew Morton wrote: > > On Sat, 21 Jun 2014 11:10:58 +0200 Heiko Carstens > > wrote: > > > On Wed, Jun 18, 2014 at 02:29:31PM -0700, Andrew Morton wrote: > > > > I'm uncle

Re: [PATCH 0/2] /proc/stat vs. failed order-4 allocation

2014-06-25 Thread Heiko Carstens
On Tue, Jun 24, 2014 at 04:52:22PM -0700, David Rientjes wrote: On Mon, 23 Jun 2014, Andrew Morton wrote: On Sat, 21 Jun 2014 11:10:58 +0200 Heiko Carstens heiko.carst...@de.ibm.com wrote: On Wed, Jun 18, 2014 at 02:29:31PM -0700, Andrew Morton wrote: I'm unclear on how urgent

Re: [PATCH] arch,locking: Ciao arch_mutex_cpu_relax()

2014-06-25 Thread Heiko Carstens
On Tue, Jun 24, 2014 at 08:06:55AM -0700, Davidlohr Bueso wrote: On Mon, 2014-06-23 at 08:58 +0200, Peter Zijlstra wrote: While I like the general idea; does anyone have a better name for this? So in particular, the difference is that on s390: cpu_relax()- yields the

Re: [PATCH 0/2] /proc/stat vs. failed order-4 allocation

2014-06-21 Thread Heiko Carstens
On Wed, Jun 18, 2014 at 02:29:31PM -0700, Andrew Morton wrote: > On Mon, 16 Jun 2014 11:04:50 +0200 Heiko Carstens > wrote: > > > These two patches are supposed to "fix" failed order-4 memory > > allocations which have been observed when reading /proc/stat. &g

Re: [PATCH 0/2] /proc/stat vs. failed order-4 allocation

2014-06-21 Thread Heiko Carstens
On Wed, Jun 18, 2014 at 02:29:31PM -0700, Andrew Morton wrote: On Mon, 16 Jun 2014 11:04:50 +0200 Heiko Carstens heiko.carst...@de.ibm.com wrote: These two patches are supposed to fix failed order-4 memory allocations which have been observed when reading /proc/stat. The problem has

[PATCH 2/2] fs/seq_file: fallback to vmalloc allocation

2014-06-16 Thread Heiko Carstens
_last+0x382/0x10d0 [62129.701612] [<00287570>] path_openat+0xc8/0x4f8 [62129.701614] [<00288bde>] do_filp_open+0x46/0xa8 [62129.701616] [<0027541c>] do_sys_open+0x114/0x1f0 [62129.701618] [<005b1c1c>] sysc_tracego+0x14/0x1a Signed-off-by:

[PATCH 1/2] proc/stat: convert to single_open_size()

2014-06-16 Thread Heiko Carstens
. Signed-off-by: Heiko Carstens --- fs/proc/stat.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/fs/proc/stat.c b/fs/proc/stat.c index 9d231e9e5f0e..bf2d03f8fd3e 100644 --- a/fs/proc/stat.c +++ b/fs/proc/stat.c @@ -184,29 +184,11 @@ static int show_stat

[PATCH 0/2] /proc/stat vs. failed order-4 allocation

2014-06-16 Thread Heiko Carstens
tions also work if memory is fragmented. This approach seems to be simpler and less intrusive than changing /proc/stat to use an interator. Also it "fixes" other users as well, which use seq_file's single_open() interface. Heiko Carstens (2): proc/stat: convert to single_open_size() f

[PATCH 1/2] proc/stat: convert to single_open_size()

2014-06-16 Thread Heiko Carstens
. Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com --- fs/proc/stat.c | 22 ++ 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/fs/proc/stat.c b/fs/proc/stat.c index 9d231e9e5f0e..bf2d03f8fd3e 100644 --- a/fs/proc/stat.c +++ b/fs/proc/stat.c @@ -184,29 +184,11

[PATCH 0/2] /proc/stat vs. failed order-4 allocation

2014-06-16 Thread Heiko Carstens
work if memory is fragmented. This approach seems to be simpler and less intrusive than changing /proc/stat to use an interator. Also it fixes other users as well, which use seq_file's single_open() interface. Heiko Carstens (2): proc/stat: convert to single_open_size() fs/seq_file: fallback

[PATCH 2/2] fs/seq_file: fallback to vmalloc allocation

2014-06-16 Thread Heiko Carstens
] [00288bde] do_filp_open+0x46/0xa8 [62129.701616] [0027541c] do_sys_open+0x114/0x1f0 [62129.701618] [005b1c1c] sysc_tracego+0x14/0x1a Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com --- fs/seq_file.c | 30 +- 1 file changed, 21 insertions

Re: fs/stat: Reduce memory requirements for stat_open

2014-06-12 Thread Heiko Carstens
On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote: > When reading from /proc/stat we allocate a large buffer to maximise > the chances of the results being from a single run and thus internally > consistent. This currently is sized at 128 * num_possible_cpus() which, > in the face of

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-06-12 Thread Heiko Carstens
On Thu, Jun 12, 2014 at 09:27:41AM +0200, Heiko Carstens wrote: > On Wed, Jun 11, 2014 at 11:52:31PM -0700, David Rientjes wrote: > > On Thu, 12 Jun 2014, Ian Kent wrote: > > > > > +static void seq_alloc(struct seq_file *m) > > > > > +{ > > > >

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-06-12 Thread Heiko Carstens
On Wed, Jun 11, 2014 at 11:52:31PM -0700, David Rientjes wrote: > On Thu, 12 Jun 2014, Ian Kent wrote: > > > > +static void seq_alloc(struct seq_file *m) > > > > +{ > > > > + m->size = PAGE_SIZE; > > > > + m->buf = kmalloc(m->size, GFP_KERNEL | __GFP_NOWARN); > > > > + if

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-06-12 Thread Heiko Carstens
On Wed, Jun 11, 2014 at 11:52:31PM -0700, David Rientjes wrote: On Thu, 12 Jun 2014, Ian Kent wrote: +static void seq_alloc(struct seq_file *m) +{ + m-size = PAGE_SIZE; + m-buf = kmalloc(m-size, GFP_KERNEL | __GFP_NOWARN); + if (!m-buf) +

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-06-12 Thread Heiko Carstens
On Thu, Jun 12, 2014 at 09:27:41AM +0200, Heiko Carstens wrote: On Wed, Jun 11, 2014 at 11:52:31PM -0700, David Rientjes wrote: On Thu, 12 Jun 2014, Ian Kent wrote: +static void seq_alloc(struct seq_file *m) +{ + m-size = PAGE_SIZE; + m-buf = kmalloc(m-size

Re: fs/stat: Reduce memory requirements for stat_open

2014-06-12 Thread Heiko Carstens
On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote: When reading from /proc/stat we allocate a large buffer to maximise the chances of the results being from a single run and thus internally consistent. This currently is sized at 128 * num_possible_cpus() which, in the face of

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-06-11 Thread Heiko Carstens
[full quote, since I added Al to cc] On Mon, Jun 09, 2014 at 04:11:59PM +0800, Ian Kent wrote: > On Wed, 2014-05-28 at 15:37 -0700, Andrew Morton wrote: > > On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens > > wrote: > > > > > Now, /proc/stat uses single_

Re: [PATCH] s390: avoid format strings leaking into names

2014-06-11 Thread Heiko Carstens
On Tue, Jun 10, 2014 at 10:46:20AM -0700, Kees Cook wrote: > This makes sure format strings can't accidentally leak into kernel > interface names. > > Signed-off-by: Kees Cook > --- > drivers/s390/block/dcssblk.c |2 +- > drivers/s390/char/vmlogrdr.c |2 +- >

Re: [PATCH] s390: avoid format strings leaking into names

2014-06-11 Thread Heiko Carstens
On Tue, Jun 10, 2014 at 10:46:20AM -0700, Kees Cook wrote: This makes sure format strings can't accidentally leak into kernel interface names. Signed-off-by: Kees Cook keesc...@chromium.org --- drivers/s390/block/dcssblk.c |2 +- drivers/s390/char/vmlogrdr.c |2 +-

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-06-11 Thread Heiko Carstens
[full quote, since I added Al to cc] On Mon, Jun 09, 2014 at 04:11:59PM +0800, Ian Kent wrote: On Wed, 2014-05-28 at 15:37 -0700, Andrew Morton wrote: On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens heiko.carst...@de.ibm.com wrote: Now, /proc/stat uses single_open() for showing

Re: [PATCH] s390: scsi: zfcp_aux.c: Cleaning up missing null-terminate after strncpy call

2014-06-04 Thread Heiko Carstens
On Wed, Jun 04, 2014 at 11:31:11PM +0200, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. > > This was partly found using a static code analysis program called cppcheck. > > Signed-off-by: Rickard Strandqvist > --- > drivers/s390/scsi/zfcp_aux.c |1 + >

Re: [PATCH] s390: scsi: zfcp_aux.c: Cleaning up missing null-terminate after strncpy call

2014-06-04 Thread Heiko Carstens
On Wed, Jun 04, 2014 at 11:31:11PM +0200, Rickard Strandqvist wrote: Added a guaranteed null-terminate after call to strncpy. This was partly found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se ---

[PATCH] fs: proc/stat: use seq_file iterator interface

2014-05-30 Thread Heiko Carstens
leading potentially to inconsistent data. This is still the case after the change, however because of the iterator interface, and the additional latencies we get with that, the per cpu statistics may get more inconsistent than before. If this is really an issue remains to b

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-05-30 Thread Heiko Carstens
On Wed, May 28, 2014 at 03:37:04PM -0700, Andrew Morton wrote: > On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens > wrote: > > With this patch it should not happen anymore that reading /proc/stat > > fails because of a failing high order memory allocation. > > So this

Re: [PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-05-30 Thread Heiko Carstens
On Wed, May 28, 2014 at 03:37:04PM -0700, Andrew Morton wrote: On Wed, 28 May 2014 11:01:53 +0200 Heiko Carstens heiko.carst...@de.ibm.com wrote: With this patch it should not happen anymore that reading /proc/stat fails because of a failing high order memory allocation. So this deletes

[PATCH] fs: proc/stat: use seq_file iterator interface

2014-05-30 Thread Heiko Carstens
of the iterator interface, and the additional latencies we get with that, the per cpu statistics may get more inconsistent than before. If this is really an issue remains to be seen. Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com

[PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-05-28 Thread Heiko Carstens
ges like e.g. that the cpu iterator handles 32 cpus in a batch to avoid lots of iterations. With this patch it should not happen anymore that reading /proc/stat fails because of a failing high order memory allocation. Signed-off-by: KAMEZAWA Hiroyuki Signed-off-by: Heiko Carstens --- fs/proc/

[PATCH 1/2] fs: proc/stat: use num_online_cpus() for buffer size

2014-05-28 Thread Heiko Carstens
ilp_open+0x46/0xa8 [62129.701616] [<0027541c>] do_sys_open+0x114/0x1f0 [62129.701618] [<005b1c1c>] sysc_tracego+0x14/0x1a Signed-off-by: Heiko Carstens --- fs/proc/stat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/stat.c b/fs/proc/stat.c index 9d

Re: /proc/stat vs. failed order-4 allocation

2014-05-28 Thread Heiko Carstens
On Wed, May 21, 2014 at 07:32:29AM -0700, Christoph Hellwig wrote: > On Wed, May 21, 2014 at 02:25:21PM +0200, Heiko Carstens wrote: > > Hi all, > > > > I'm just wondering why /proc/stat is a single_open() seq_file and not a > > regular seq_file with an iterator (

Re: /proc/stat vs. failed order-4 allocation

2014-05-28 Thread Heiko Carstens
On Wed, May 21, 2014 at 07:32:29AM -0700, Christoph Hellwig wrote: On Wed, May 21, 2014 at 02:25:21PM +0200, Heiko Carstens wrote: Hi all, I'm just wondering why /proc/stat is a single_open() seq_file and not a regular seq_file with an iterator (say 48 online cpus for each iteration

[PATCH 1/2] fs: proc/stat: use num_online_cpus() for buffer size

2014-05-28 Thread Heiko Carstens
] sysc_tracego+0x14/0x1a Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com --- fs/proc/stat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/stat.c b/fs/proc/stat.c index 9d231e9e5f0e..3898ca5f1e92 100644 --- a/fs/proc/stat.c +++ b/fs/proc/stat.c @@ -184,7 +184,7

[PATCH 2/2] fs: proc/stat: use usual seq_file ops rather than single_open

2014-05-28 Thread Heiko Carstens
-off-by: Heiko Carstens heiko.carst...@de.ibm.com --- fs/proc/stat.c | 278 + 1 file changed, 203 insertions(+), 75 deletions(-) diff --git a/fs/proc/stat.c b/fs/proc/stat.c index 3898ca5f1e92..652e255fee90 100644 --- a/fs/proc/stat.c +++ b

/proc/stat vs. failed order-4 allocation

2014-05-21 Thread Heiko Carstens
Hi all, I'm just wondering why /proc/stat is a single_open() seq_file and not a regular seq_file with an iterator (say 48 online cpus for each iteration or something similar). Of course, in theory, the "intr" line may be very long as well... With the current implementation everything must fit

/proc/stat vs. failed order-4 allocation

2014-05-21 Thread Heiko Carstens
Hi all, I'm just wondering why /proc/stat is a single_open() seq_file and not a regular seq_file with an iterator (say 48 online cpus for each iteration or something similar). Of course, in theory, the intr line may be very long as well... With the current implementation everything must fit

Re: [PATCH 13/13] s390/irq: make return of 0 explicit

2014-05-19 Thread Heiko Carstens
On Mon, May 19, 2014 at 06:31:15AM +0200, Julia Lawall wrote: > From: Julia Lawall > > Delete unnecessary local variable whose value is always 0 and that hides > the fact that the result is always 0. > > A simplified version of the semantic patch that fixes this problem is as > follows:

Re: [PATCH 13/13] s390/irq: make return of 0 explicit

2014-05-19 Thread Heiko Carstens
On Mon, May 19, 2014 at 06:31:15AM +0200, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr Delete unnecessary local variable whose value is always 0 and that hides the fact that the result is always 0. A simplified version of the semantic patch that fixes this problem is as

Re: [PATCH] s390: add slab.h for kzalloc/kfree

2014-04-28 Thread Heiko Carstens
On Sun, Apr 27, 2014 at 05:35:43PM -0400, Jeff Mahoney wrote: > This fixes: > arch/s390/appldata/appldata_mem.c:135:2: error: implicit declaration of > function 'kzalloc' [-Werror=implicit-function-declaration] > arch/s390/appldata/appldata_mem.c:141:3: error: implicit declaration of > function

Re: [PATCH] s390: add slab.h for kzalloc/kfree

2014-04-28 Thread Heiko Carstens
On Sun, Apr 27, 2014 at 05:35:43PM -0400, Jeff Mahoney wrote: This fixes: arch/s390/appldata/appldata_mem.c:135:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] arch/s390/appldata/appldata_mem.c:141:3: error: implicit declaration of function

Re: [GIT PULL] ext4 changes for 3.15

2014-04-08 Thread Heiko Carstens
h it and > inform us about it during our next kernel build. > > If you add it to x86_64 only, bad luck for anyone else ;-) Also it would be nice if somebody would pick up the patch below as well :) >From 97cdc756ca508f2200ae0cebf1cf1f1b8daa711b Mon Sep 17 00:00:00 2001 From: Heiko

Re: [GIT PULL] ext4 changes for 3.15

2014-04-08 Thread Heiko Carstens
pick up the patch below as well :) From 97cdc756ca508f2200ae0cebf1cf1f1b8daa711b Mon Sep 17 00:00:00 2001 From: Heiko Carstens heiko.carst...@de.ibm.com Date: Tue, 8 Apr 2014 12:55:46 +0200 Subject: [PATCH] include/linux/syscalls.h: add sys_renameat2() prototype Signed-off-by: Heiko Carstens

[GIT PULL] s390 compat wrapper rework

2014-03-30 Thread Heiko Carstens
less bugs, and much more sanity checking. Thanks, Heiko Heiko Carstens (44): compat: let architectures define __ARCH_WANT_COMPAT_SYS_GETDENTS64 compat: add COMPAT_SYSCALL_DEFINE0 macro s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 1 s390/compa

[GIT PULL] s390 compat wrapper rework

2014-03-30 Thread Heiko Carstens
, and much more sanity checking. Thanks, Heiko Heiko Carstens (44): compat: let architectures define __ARCH_WANT_COMPAT_SYS_GETDENTS64 compat: add COMPAT_SYSCALL_DEFINE0 macro s390/compat: convert to COMPAT_SYSCALL_DEFINEx part 1 s390/compat: convert

Re: [patch 03/16] s390: net: lcs: Add missing destroy_timer_on_stack()

2014-03-24 Thread Heiko Carstens
On Sun, Mar 23, 2014 at 03:09:25PM -, Thomas Gleixner wrote: > Otherwise we leak a tracking object when DEBUG_OBJECTS is enabled. > drivers/s390/net/lcs.c |1 + > 1 file changed, 1 insertion(+) > > Index: tip/drivers/s390/net/lcs.c >

Re: [patch 02/16] s390: tape: Add missing destroy_timer_on_stack()

2014-03-24 Thread Heiko Carstens
On Sun, Mar 23, 2014 at 03:09:25PM -, Thomas Gleixner wrote: > Otherwise we leak a tracking object when DEBUG_OBJECTS is enabled. > [...] > del_timer_sync(); > + destroy_timer_on_stack(); Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [patch 01/16] s390: tape: Use del_timer_sync()

2014-03-24 Thread Heiko Carstens
On Sun, Mar 23, 2014 at 03:09:24PM -, Thomas Gleixner wrote: > del_timer() does not wait for a possible running callback to > complete. So the call side might free request and the associated > objects while on another cpu the timer handler runs. [...] > > - del_timer(); > +

Re: [patch 01/16] s390: tape: Use del_timer_sync()

2014-03-24 Thread Heiko Carstens
On Sun, Mar 23, 2014 at 03:09:24PM -, Thomas Gleixner wrote: del_timer() does not wait for a possible running callback to complete. So the call side might free request and the associated objects while on another cpu the timer handler runs. [...] - del_timer(timeout); +

Re: [patch 03/16] s390: net: lcs: Add missing destroy_timer_on_stack()

2014-03-24 Thread Heiko Carstens
On Sun, Mar 23, 2014 at 03:09:25PM -, Thomas Gleixner wrote: Otherwise we leak a tracking object when DEBUG_OBJECTS is enabled. drivers/s390/net/lcs.c |1 + 1 file changed, 1 insertion(+) Index: tip/drivers/s390/net/lcs.c

Re: [patch 02/16] s390: tape: Add missing destroy_timer_on_stack()

2014-03-24 Thread Heiko Carstens
On Sun, Mar 23, 2014 at 03:09:25PM -, Thomas Gleixner wrote: Otherwise we leak a tracking object when DEBUG_OBJECTS is enabled. [...] del_timer_sync(timeout); + destroy_timer_on_stack(timeout); Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

2014-03-23 Thread Heiko Carstens
gt; select VIRT_CPU_ACCOUNTING > select VIRT_TO_BUS > + select ARCH_HAS_SG_CHAIN > Acked-by: Heiko Carstens FWIW, it would have been nice to keep the list of selected configs sorted. However no need to resend. -- To unsubscribe from this list: send the line "unsubscrib

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

2014-03-23 Thread Heiko Carstens
VIRT_TO_BUS + select ARCH_HAS_SG_CHAIN Acked-by: Heiko Carstens heiko.carst...@de.ibm.com FWIW, it would have been nice to keep the list of selected configs sorted. However no need to resend. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH 23/31] arch,s390: Convert smp_mb__*

2014-03-19 Thread Heiko Carstens
On Wed, Mar 19, 2014 at 07:47:52AM +0100, Peter Zijlstra wrote: > As per the existing implementation; implement the new one using > smp_mb(). > > AFAICT the s390 compare-and-swap does imply a barrier, however there > are some immediate ops that seem to be singly-copy atomic and do not > imply a

Re: [PATCH 23/31] arch,s390: Convert smp_mb__*

2014-03-19 Thread Heiko Carstens
On Wed, Mar 19, 2014 at 07:47:52AM +0100, Peter Zijlstra wrote: As per the existing implementation; implement the new one using smp_mb(). AFAICT the s390 compare-and-swap does imply a barrier, however there are some immediate ops that seem to be singly-copy atomic and do not imply a

[BUG -next] "mm: per-thread vma caching fix 5" breaks s390

2014-03-18 Thread Heiko Carstens
Hi Andrew, your patch "mm-per-thread-vma-caching-fix-5" in linux-next (see below) breaks s390: [ 10.101173] kernel BUG at mm/vmacache.c:76! [ 10.101206] illegal operation: 0001 [#1] SMP DEBUG_PAGEALLOC [ 10.101210] Modules linked in: [ 10.101212] CPU: 3 PID: 2286 Comm: ifup-eth Not

[BUG -next] mm: per-thread vma caching fix 5 breaks s390

2014-03-18 Thread Heiko Carstens
Hi Andrew, your patch mm-per-thread-vma-caching-fix-5 in linux-next (see below) breaks s390: [ 10.101173] kernel BUG at mm/vmacache.c:76! [ 10.101206] illegal operation: 0001 [#1] SMP DEBUG_PAGEALLOC [ 10.101210] Modules linked in: [ 10.101212] CPU: 3 PID: 2286 Comm: ifup-eth Not

Re: [PATCH 01/15] sched/prio: Add a macro named NICE_TO_RLIMIT in prio.h.

2014-03-11 Thread Heiko Carstens
On Tue, Mar 11, 2014 at 04:20:24PM +0800, Dongsheng Yang wrote: > On 03/11/2014 04:17 PM, Heiko Carstens wrote: > >On Tue, Mar 11, 2014 at 12:59:16PM +0800, Dongsheng Yang wrote: > >>+#define NICE_TO_RLIMIT(nice) (MAX_NICE - nice + 1) > >Where is MAX_NICE defin

Re: [PATCH 01/15] sched/prio: Add a macro named NICE_TO_RLIMIT in prio.h.

2014-03-11 Thread Heiko Carstens
On Tue, Mar 11, 2014 at 12:59:16PM +0800, Dongsheng Yang wrote: > This patch add a macro named NICE_TO_RLIMIT in prio.h to > convert nice value [19,-20] to rlimit style value [1,40]. > > Signed-off-by: Dongsheng Yang > --- > include/linux/sched/prio.h | 5 + > 1 file changed, 5

Re: [PATCH 01/15] sched/prio: Add a macro named NICE_TO_RLIMIT in prio.h.

2014-03-11 Thread Heiko Carstens
On Tue, Mar 11, 2014 at 12:59:16PM +0800, Dongsheng Yang wrote: This patch add a macro named NICE_TO_RLIMIT in prio.h to convert nice value [19,-20] to rlimit style value [1,40]. Signed-off-by: Dongsheng Yang yangds.f...@cn.fujitsu.com --- include/linux/sched/prio.h | 5 + 1 file

Re: [PATCH 01/15] sched/prio: Add a macro named NICE_TO_RLIMIT in prio.h.

2014-03-11 Thread Heiko Carstens
On Tue, Mar 11, 2014 at 04:20:24PM +0800, Dongsheng Yang wrote: On 03/11/2014 04:17 PM, Heiko Carstens wrote: On Tue, Mar 11, 2014 at 12:59:16PM +0800, Dongsheng Yang wrote: +#define NICE_TO_RLIMIT(nice) (MAX_NICE - nice + 1) Where is MAX_NICE defined? The s390 patch fails to compile

[tip:core/locking] futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test

2014-03-03 Thread tip-bot for Heiko Carstens
Commit-ID: 03b8c7b623c80af264c4c8d6111e5c6289933666 Gitweb: http://git.kernel.org/tip/03b8c7b623c80af264c4c8d6111e5c6289933666 Author: Heiko Carstens AuthorDate: Sun, 2 Mar 2014 13:09:47 +0100 Committer: Thomas Gleixner CommitDate: Mon, 3 Mar 2014 11:32:08 +0100 futex: Allow

[tip:core/locking] futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test

2014-03-03 Thread tip-bot for Heiko Carstens
Commit-ID: 03b8c7b623c80af264c4c8d6111e5c6289933666 Gitweb: http://git.kernel.org/tip/03b8c7b623c80af264c4c8d6111e5c6289933666 Author: Heiko Carstens heiko.carst...@de.ibm.com AuthorDate: Sun, 2 Mar 2014 13:09:47 +0100 Committer: Thomas Gleixner t...@linutronix.de CommitDate: Mon, 3 Mar

[PATCH] futexes: allow architectures to skip futex_atomic_cmpxchg_inatomic() test

2014-03-02 Thread Heiko Carstens
away. Cc: Geert Uytterhoeven Cc: Finn Thain Signed-off-by: Heiko Carstens --- arch/s390/Kconfig | 1 + include/linux/futex.h | 4 init/Kconfig | 7 +++ kernel/futex.c| 37 - 4 files changed, 36 insertions(+), 13 deletions

[PATCH] futexes: allow architectures to skip futex_atomic_cmpxchg_inatomic() test

2014-03-02 Thread Heiko Carstens
away. Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Finn Thain fth...@telegraphics.com.au Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com --- arch/s390/Kconfig | 1 + include/linux/futex.h | 4 init/Kconfig | 7 +++ kernel/futex.c| 37

Re: [PATCH] s390: select CONFIG_TTY for use of tty in unconditional keyboard driver

2014-02-26 Thread Heiko Carstens
On Wed, Feb 26, 2014 at 06:13:06PM -0800, Josh Triplett wrote: > The unconditionally built keyboard driver, drivers/s390/char/keyboard.c, > requires CONFIG_TTY, so select it from CONFIG_S390 to prevent a build > error. > > Signed-off-by: Josh Triplett > --- > arch/s390/Kconfig | 1 + > 1 file

Re: [PATCH] s390: select CONFIG_TTY for use of tty in unconditional keyboard driver

2014-02-26 Thread Heiko Carstens
On Wed, Feb 26, 2014 at 06:13:06PM -0800, Josh Triplett wrote: The unconditionally built keyboard driver, drivers/s390/char/keyboard.c, requires CONFIG_TTY, so select it from CONFIG_S390 to prevent a build error. Signed-off-by: Josh Triplett j...@joshtriplett.org --- arch/s390/Kconfig | 1

Re: [PATCH] checkpatch.pl: Add warning for new __packed additions

2014-02-25 Thread Heiko Carstens
On Mon, Feb 24, 2014 at 05:04:57PM -0500, Tom Rini wrote: > On 02/24/2014 05:02 PM, Joe Perches wrote: > > On Mon, 2014-02-24 at 16:52 -0500, Tom Rini wrote: > >> I've been lead to > >> believe that most cases now people should be using regmap instead, which > >> just leaves the case of having to

Re: [PATCH] checkpatch.pl: Add warning for new __packed additions

2014-02-25 Thread Heiko Carstens
On Mon, Feb 24, 2014 at 05:04:57PM -0500, Tom Rini wrote: On 02/24/2014 05:02 PM, Joe Perches wrote: On Mon, 2014-02-24 at 16:52 -0500, Tom Rini wrote: I've been lead to believe that most cases now people should be using regmap instead, which just leaves the case of having to match

Re: [PATCH RFC/RFT v3 4/9] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-20 Thread Heiko Carstens
On Thu, Feb 20, 2014 at 01:33:56PM +, Sudeep Holla wrote: > Thanks, this info was helpful and looks like it's stupid mistake I did. I > deleted a line unknowingly while trying to minimise the diff for > show_cacheinfo. > The below fix-up must work IIUC the issue. I will squash this in my next

Re: [PATCH RFC/RFT v3 4/9] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-20 Thread Heiko Carstens
On Wed, Feb 19, 2014 at 04:06:11PM +, Sudeep Holla wrote: > From: Sudeep Holla > > This patch removes the redundant sysfs cacheinfo code by making use of > the newly introduced generic cacheinfo infrastructure. > > Signed-off-by: Sudeep Holla > Cc: Martin Schwidefsky

Re: [PATCH RFC/RFT v3 4/9] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-20 Thread Heiko Carstens
Schwidefsky schwidef...@de.ibm.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: linux...@de.ibm.com Cc: linux-s...@vger.kernel.org --- arch/s390/kernel/cache.c | 388 --- 1 file changed, 93 insertions(+), 295 deletions(-) (FWIW, if you send

Re: [PATCH RFC/RFT v3 4/9] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-20 Thread Heiko Carstens
On Thu, Feb 20, 2014 at 01:33:56PM +, Sudeep Holla wrote: Thanks, this info was helpful and looks like it's stupid mistake I did. I deleted a line unknowingly while trying to minimise the diff for show_cacheinfo. The below fix-up must work IIUC the issue. I will squash this in my next

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-18 Thread Heiko Carstens
Hi Sudeep, > > Please have a look at these two commits which should describe why things > > are as they are on s390: > > > > 881730ad365130f64b5c70c40904b04eb3b79de3 > > "s390/cache: expose cpu cache topology via sysfs" > > 6668022c7bde3fdc96d3d257294a7216c7a46829 > > "s390/cache: add cpu

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-18 Thread Heiko Carstens
Hi Sudeep, Please have a look at these two commits which should describe why things are as they are on s390: 881730ad365130f64b5c70c40904b04eb3b79de3 s390/cache: expose cpu cache topology via sysfs 6668022c7bde3fdc96d3d257294a7216c7a46829 s390/cache: add cpu cache information to

Re: [PATCH] s390: remove HAVE_MARCH_Z9?0_FEATURES

2014-02-17 Thread Heiko Carstens
On Mon, Feb 17, 2014 at 09:50:40AM +0100, Paul Bolle wrote: > On Mon, 2014-02-17 at 09:20 +0100, Heiko Carstens wrote: > > On Sun, Feb 16, 2014 at 06:15:27PM +0100, Paul Bolle wrote: > > No, I want to keep them, so there is a config symbol for each cpu generation > > and

Re: [PATCH] s390: remove HAVE_MARCH_Z9?0_FEATURES

2014-02-17 Thread Heiko Carstens
On Sun, Feb 16, 2014 at 06:15:27PM +0100, Paul Bolle wrote: > The Kconfig symbols HAVE_MARCH_Z900_FEATURES and > HAVE_MARCH_Z990_FEATURES were added in v3.5. They have never been used. > Apparently they are not needed. They can safely be removed. > No, I want to keep them, so there is a config

Re: [PATCH] s390: remove HAVE_MARCH_Z9?0_FEATURES

2014-02-17 Thread Heiko Carstens
On Sun, Feb 16, 2014 at 06:15:27PM +0100, Paul Bolle wrote: The Kconfig symbols HAVE_MARCH_Z900_FEATURES and HAVE_MARCH_Z990_FEATURES were added in v3.5. They have never been used. Apparently they are not needed. They can safely be removed. No, I want to keep them, so there is a config

Re: [PATCH] s390: remove HAVE_MARCH_Z9?0_FEATURES

2014-02-17 Thread Heiko Carstens
On Mon, Feb 17, 2014 at 09:50:40AM +0100, Paul Bolle wrote: On Mon, 2014-02-17 at 09:20 +0100, Heiko Carstens wrote: On Sun, Feb 16, 2014 at 06:15:27PM +0100, Paul Bolle wrote: No, I want to keep them, so there is a config symbol for each cpu generation and we don't have to add the config

[ANNOUNCE] s390 31 bit kernel support removal

2014-02-12 Thread Heiko Carstens
Hi all, we plan to remove 31 bit kernel support of the s390 architecture in the Linux kernel sources. The reason for this is quite simple: the current 31 bit kernel was broken for nearly a year before somebody noticed. Keeping the 31 bit kernel support adds extra maintenance and development

[ANNOUNCE] s390 31 bit kernel support removal

2014-02-12 Thread Heiko Carstens
Hi all, we plan to remove 31 bit kernel support of the s390 architecture in the Linux kernel sources. The reason for this is quite simple: the current 31 bit kernel was broken for nearly a year before somebody noticed. Keeping the 31 bit kernel support adds extra maintenance and development

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-10 Thread Heiko Carstens
On Mon, Feb 10, 2014 at 11:34:55AM +, Sudeep Holla wrote: > On 10/02/14 09:50, Heiko Carstens wrote: > > On Fri, Feb 07, 2014 at 04:49:18PM +, Sudeep Holla wrote: > >> - show_cacheinfo(m); > >>} > >>get_online_cpus(); > >>i

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-10 Thread Heiko Carstens
On Fri, Feb 07, 2014 at 04:49:18PM +, Sudeep Holla wrote: > From: Sudeep Holla > > This patch removes the redundant sysfs cacheinfo code by making use of > the newly introduced generic cacheinfo infrastructure. > > Signed-off-by: Sudeep Holla [...] > -static ssize_t

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-10 Thread Heiko Carstens
On Fri, Feb 07, 2014 at 04:49:18PM +, Sudeep Holla wrote: > From: Sudeep Holla > > This patch removes the redundant sysfs cacheinfo code by making use of > the newly introduced generic cacheinfo infrastructure. > > Signed-off-by: Sudeep Holla > Cc: Martin Schwidefsky

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-10 Thread Heiko Carstens
Schwidefsky schwidef...@de.ibm.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: linux...@de.ibm.com Cc: linux-s...@vger.kernel.org --- [...] diff --git a/arch/s390/kernel/processor.c b/arch/s390/kernel/processor.c index 2461202..1f875db 100644 --- a/arch/s390/kernel/processor.c +++ b

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-10 Thread Heiko Carstens
On Fri, Feb 07, 2014 at 04:49:18PM +, Sudeep Holla wrote: From: Sudeep Holla sudeep.ho...@arm.com This patch removes the redundant sysfs cacheinfo code by making use of the newly introduced generic cacheinfo infrastructure. Signed-off-by: Sudeep Holla sudeep.ho...@arm.com [...]

Re: [PATCH RFC/RFT v2 3/8] s390: move cacheinfo sysfs to generic cacheinfo infrastructure

2014-02-10 Thread Heiko Carstens
On Mon, Feb 10, 2014 at 11:34:55AM +, Sudeep Holla wrote: On 10/02/14 09:50, Heiko Carstens wrote: On Fri, Feb 07, 2014 at 04:49:18PM +, Sudeep Holla wrote: - show_cacheinfo(m); } get_online_cpus(); if (cpu_online(n)) { You can't remove that. It's a user

[PATCH] tile: remove compat_sys_lookup_dcookie declaration to fix compile error

2014-01-30 Thread Heiko Carstens
ent compat lookup_dcookie() versions have been merged. The declaration is now in include/linux/compat.h The build error was reported by Fenguang's build bot. Signed-off-by: Heiko Carstens --- arch/tile/include/asm/compat.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/tile/include/asm/compat.h b

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