Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers

Hello Yury, On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote: > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so > it's > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that > long, > unsigned long and pointer types are all 32-bit

Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread

On Wed, Jan 27, 2016 at 10:47:37PM +, Mathieu Desnoyers wrote: > - On Jan 27, 2016, at 5:11 PM, Josh Triplett j...@joshtriplett.org wrote: > > > On Wed, Jan 27, 2016 at 09:34:35PM +, Mathieu Desnoyers wrote: > >> - On Jan 27, 2016, at 12:37 PM, Thomas Gleixner t...@linutronix.de

Re: [PATCH 3/3] param: convert some "on"/"off" users to strtobool

+- > arch/x86/kernel/aperture_64.c| 13 +++-- > include/linux/tick.h | 2 +- > kernel/time/hrtimer.c| 11 +++ > kernel/time/tick-sched.c | 11 +++ > 8 files changed, 21 in

Re: [PATCH 1/5] all: s390: move wrapper infrastructure to generic headers

Hello Yury, On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote: > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so > it's > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that > long, > unsigned long and pointer types are all 32-bit

Re: [RFC PATCH v2 1/3] getcpu_cache system call: cache CPU number of running thread

On Wed, Jan 27, 2016 at 10:47:37PM +, Mathieu Desnoyers wrote: > - On Jan 27, 2016, at 5:11 PM, Josh Triplett j...@joshtriplett.org wrote: > > > On Wed, Jan 27, 2016 at 09:34:35PM +, Mathieu Desnoyers wrote: > >> - On Jan 27, 2016, at 12:37 PM, Thomas Gleixner t...@linutronix.de

Re: [PATCH] include/linux/list_bl.h: Use bool instead of int for boolean functions

On Mon, Jan 25, 2016 at 04:58:18AM +0800, cheng...@emindsoft.com.cn wrote: > From: Chen Gang > > hlist_bl_unhashed() and hlist_bl_empty() are all boolean functions, so > return bool instead of int. > > Signed-off-by: Chen Gang > --- > include/linux/list_bl.h | 4 ++-- > 1 file changed, 2

Re: [PATCH v2 3/3] s390: query dynamic DEBUG_PAGEALLOC setting

NFIG_SMP > printk("SMP "); > -#endif > -#ifdef CONFIG_DEBUG_PAGEALLOC > - printk("DEBUG_PAGEALLOC"); > -#endif > +#endif > +if (debug_pagealloc_enabled()) > + printk("DEBUG_PAGEALLOC"); > printk("\n"); Indentation is broken ("if"). Besides that Reviewed-by: Heiko Carstens

Re: [PATCH] include/linux/list_bl.h: Use bool instead of int for boolean functions

On Mon, Jan 25, 2016 at 04:58:18AM +0800, cheng...@emindsoft.com.cn wrote: > From: Chen Gang > > hlist_bl_unhashed() and hlist_bl_empty() are all boolean functions, so > return bool instead of int. > > Signed-off-by: Chen Gang > --- >

Re: [PATCH v2 3/3] s390: query dynamic DEBUG_PAGEALLOC setting

> #endif > #ifdef CONFIG_SMP > printk("SMP "); > -#endif > -#ifdef CONFIG_DEBUG_PAGEALLOC > - printk("DEBUG_PAGEALLOC"); > -#endif > +#endif > +if (debug_pagealloc_enabled()) > + printk("DEBUG_PAGEALLOC"); > printk("\n"); Indentation is broken ("if"). Besides that Reviewed-by: Heiko Carstens <heiko.carst...@de.ibm.com>

Re: [PATCH/RFC 3/3] s390: query dynamic DEBUG_PAGEALLOC setting

On Tue, Jan 26, 2016 at 10:18:25AM +0100, Christian Borntraeger wrote: > We can use debug_pagealloc_enabled() to check if we can map > the identity mapping with 1MB/2GB pages as well as to print > the current setting in dump_stack. > > Signed-off-by: Christian Borntraeger > --- >

Re: [PATCH/RFC 3/3] s390: query dynamic DEBUG_PAGEALLOC setting

On Tue, Jan 26, 2016 at 10:18:25AM +0100, Christian Borntraeger wrote: > We can use debug_pagealloc_enabled() to check if we can map > the identity mapping with 1MB/2GB pages as well as to print > the current setting in dump_stack. > > Signed-off-by: Christian Borntraeger

Re: [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc

On Mon, Jan 25, 2016 at 10:45:50AM +0100, Christian Borntraeger wrote: > >> +By default this option will be almost for free and can be activated > >> +in distribution kernels. The overhead and the debugging can be enabled > >> +by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc

Re: [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc

On Mon, Jan 25, 2016 at 10:19:48AM +0100, Christian Borntraeger wrote: > since commit 031bc5743f158 ("mm/debug-pagealloc: make debug-pagealloc > boottime configurable") CONFIG_DEBUG_PAGEALLOC is by default a no-op. > > This resulted in several unnoticed bugs, e.g. > >

Re: [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc

On Mon, Jan 25, 2016 at 10:19:48AM +0100, Christian Borntraeger wrote: > since commit 031bc5743f158 ("mm/debug-pagealloc: make debug-pagealloc > boottime configurable") CONFIG_DEBUG_PAGEALLOC is by default a no-op. > > This resulted in several unnoticed bugs, e.g. > >

Re: [PATCH] mm/debug_pagealloc: Ask users for default setting of debug_pagealloc

On Mon, Jan 25, 2016 at 10:45:50AM +0100, Christian Borntraeger wrote: > >> +By default this option will be almost for free and can be activated > >> +in distribution kernels. The overhead and the debugging can be enabled > >> +by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc

[PATCH] lib/bug: make panic_on_warn available for all architectures

was added to warn_slowpath_common() in panic.c. This enables panic_on_warn also for arm64, parisc, powerpc, s390 and sh. Cc: Prarit Bhargava Reported-by: Christian Borntraeger Signed-off-by: Heiko Carstens --- lib/bug.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/lib/b

[PATCH] lib/bug: make panic_on_warn available for all architectures

was added to warn_slowpath_common() in panic.c. This enables panic_on_warn also for arm64, parisc, powerpc, s390 and sh. Cc: Prarit Bhargava <pra...@redhat.com> Reported-by: Christian Borntraeger <borntrae...@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm

Re: [lkp] [mm/vmstat] 6cdb18ad98: -8.5% will-it-scale.per_thread_ops

On Wed, Jan 06, 2016 at 11:20:55AM +0800, kernel test robot wrote: > FYI, we noticed the below changes on > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 6cdb18ad98a49f7e9b95d538a0614cde827404b8 ("mm/vmstat: fix overflow in > mod_zone_page_state()") > > >

Re: [lkp] [mm/vmstat] 6cdb18ad98: -8.5% will-it-scale.per_thread_ops

On Wed, Jan 06, 2016 at 11:20:55AM +0800, kernel test robot wrote: > FYI, we noticed the below changes on > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 6cdb18ad98a49f7e9b95d538a0614cde827404b8 ("mm/vmstat: fix overflow in > mod_zone_page_state()") > > >

Re: 390/qeth: Refactoring for qeth_core_set_online()

On Mon, Jan 04, 2016 at 03:10:41PM +0100, SF Markus Elfring wrote: > > In this case the function body is very small > > so I don't see any benefit at all. > > Do you care for fine-tuning of variable placement occasionally? No. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online()

On Mon, Jan 04, 2016 at 02:10:34PM +0100, SF Markus Elfring wrote: > >> +++ b/drivers/s390/net/qeth_core_main.c > >> @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct > >> ccwgroup_device *gdev) > >> { > >>struct qeth_card *card = dev_get_drvdata(>dev); > >>int rc; > >> -

Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online()

On Sun, Jan 03, 2016 at 11:02:56AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 3 Jan 2016 10:50:11 +0100 > > Reduce the scope for the local variable "def_discipline" to one branch > of an if statement. > > Signed-off-by: Markus Elfring > --- >

Re: [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online()

On Sun, Jan 03, 2016 at 11:02:00AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 3 Jan 2016 10:48:05 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by: Markus Elfring > --- >

Re: [PATCH 0/6] generic relative extable support

rch and sort routines > x86/extable: use generic search and sort routines > ia64/extable: use generic search and sort routines > arm64: switch to relative exception tables For the s390 bits: Acked-by: Heiko Carstens -- To unsubscribe from this list: send the line "unsubscrib

Re: [PATCH] s390: fix normalization bug in exception table sorting

On Fri, Jan 01, 2016 at 01:39:22PM +0100, Ard Biesheuvel wrote: > The normalization pass in the sorting routine of the relative exception > table serves two purposes: > - it ensures that the address fields of the exception table entries are > fully ordered, so that no ambiguities arise between

Re: [PATCH 0/6] generic relative extable support

rch and sort routines > x86/extable: use generic search and sort routines > ia64/extable: use generic search and sort routines > arm64: switch to relative exception tables For the s390 bits: Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com> -- To unsubscribe f

Re: [PATCH 1/2] 390/qeth: Delete an unnecessary variable initialisation in qeth_core_set_online()

On Sun, Jan 03, 2016 at 11:02:00AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 3 Jan 2016 10:48:05 +0100 > > Omit explicit initialisation at the beginning for one local variable > that is redefined before its first use. > > Signed-off-by:

Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online()

On Sun, Jan 03, 2016 at 11:02:56AM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 3 Jan 2016 10:50:11 +0100 > > Reduce the scope for the local variable "def_discipline" to one branch > of an if statement. > > Signed-off-by: Markus Elfring

Re: [PATCH] s390: fix normalization bug in exception table sorting

On Fri, Jan 01, 2016 at 01:39:22PM +0100, Ard Biesheuvel wrote: > The normalization pass in the sorting routine of the relative exception > table serves two purposes: > - it ensures that the address fields of the exception table entries are > fully ordered, so that no ambiguities arise between

Re: [PATCH 2/2] 390/qeth: Refactoring for qeth_core_set_online()

On Mon, Jan 04, 2016 at 02:10:34PM +0100, SF Markus Elfring wrote: > >> +++ b/drivers/s390/net/qeth_core_main.c > >> @@ -5638,9 +5638,10 @@ static int qeth_core_set_online(struct > >> ccwgroup_device *gdev) > >> { > >>struct qeth_card *card = dev_get_drvdata(>dev); > >>int rc; > >> -

Re: 390/qeth: Refactoring for qeth_core_set_online()

On Mon, Jan 04, 2016 at 03:10:41PM +0100, SF Markus Elfring wrote: > > In this case the function body is very small > > so I don't see any benefit at all. > > Do you care for fine-tuning of variable placement occasionally? No. -- To unsubscribe from this list: send the line "unsubscribe

[PATCH] mm/vmstat: fix overflow in mod_zone_page_state()

now. However the overflow problem does exist anyway. Given the description that a system with slightly less than 8TB does work, this seems to be a candidate for the observed problem. Signed-off-by: Heiko Carstens --- include/linux/vmstat.h | 6 +++--- mm/vmstat.c| 10 +- 2 fil

[PATCH] mm/vmstat: fix overflow in mod_zone_page_state()

now. However the overflow problem does exist anyway. Given the description that a system with slightly less than 8TB does work, this seems to be a candidate for the observed problem. Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- include/linux/vmstat.h | 6 +++--- mm/vmsta

Re: [PATCH] s390: char: constify hmcdrv_ftp_ops structs

On Sun, Dec 13, 2015 at 08:51:49PM +0200, Aya Mahfouz wrote: > Constifies hmcdrv_ftp_ops structures in s390's char > driver since they are not modified after their > initialization. > > Detected and found using Coccinelle. > > Suggested-by: Julia Lawall > Signed-off-by: Aya Mahfouz > --- >

Re: [PATCH 3/4] s390/cio: add NULL test

On Sun, Dec 20, 2015 at 12:15:52PM +0100, Julia Lawall wrote: > Add NULL test on call to kzalloc. > > The semantic match that finds this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > expression x; > identifier fld; > @@ > > * x = kzalloc(...); > ... when != x == NULL >

Re: [PATCH] s390: char: constify hmcdrv_ftp_ops structs

On Sun, Dec 13, 2015 at 08:51:49PM +0200, Aya Mahfouz wrote: > Constifies hmcdrv_ftp_ops structures in s390's char > driver since they are not modified after their > initialization. > > Detected and found using Coccinelle. > > Suggested-by: Julia Lawall > Signed-off-by:

Re: [PATCH 3/4] s390/cio: add NULL test

On Sun, Dec 20, 2015 at 12:15:52PM +0100, Julia Lawall wrote: > Add NULL test on call to kzalloc. > > The semantic match that finds this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > expression x; > identifier fld; > @@ > > * x = kzalloc(...); > ... when != x == NULL >

Re: [PATCH] qeth: don't rely on signedness of char

On Mon, Dec 07, 2015 at 02:47:44PM +0100, Heiko Carstens wrote: > On Mon, Dec 07, 2015 at 01:02:35PM +0100, Ursula Braun wrote: > > Rasmus, > > > > I do not see a need for your first patch proposal. Our code works fine > > in our environment. > > > > But I

Re: [PATCH] qeth: don't rely on signedness of char

On Mon, Dec 07, 2015 at 01:02:35PM +0100, Ursula Braun wrote: > Rasmus, > > I do not see a need for your first patch proposal. Our code works fine > in our environment. > > But I will pickup your second part to remove the explicit setting of the > 0-termination. Thanks! > > Regards, Ursula Hi

Re: [PATCH] qeth: don't rely on signedness of char

On Mon, Dec 07, 2015 at 01:02:35PM +0100, Ursula Braun wrote: > Rasmus, > > I do not see a need for your first patch proposal. Our code works fine > in our environment. > > But I will pickup your second part to remove the explicit setting of the > 0-termination. Thanks! > > Regards, Ursula Hi

Re: [PATCH] qeth: don't rely on signedness of char

On Mon, Dec 07, 2015 at 02:47:44PM +0100, Heiko Carstens wrote: > On Mon, Dec 07, 2015 at 01:02:35PM +0100, Ursula Braun wrote: > > Rasmus, > > > > I do not see a need for your first patch proposal. Our code works fine > > in our environment. > > > > But I

Re: [PATCH v2 1/4] init: create cmdline param to disable readonly

On Mon, Nov 30, 2015 at 01:52:10PM -0800, Kees Cook wrote: > On Wed, Nov 25, 2015 at 11:51 PM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> +#ifdef CONFIG_DEBUG_RODATA > > > > Btw., could you please remove the Kconfig option altogether in an > > additional patch > > and make read-only

Re: [PATCH 1/2] kbuild: add AFLAGS_REMOVE_(basename).o option

On Mon, Nov 30, 2015 at 09:36:29AM +0100, Michal Marek wrote: > >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > >> index 79e86613712f..26a48d76eb9d 100644 > >> --- a/scripts/Makefile.lib > >> +++ b/scripts/Makefile.lib > >> @@ -104,8 +104,9 @@ modname_flags = $(if $(filter 1,$(words

Re: [PATCH] ARM64: fix building without CONFIG_UID16

On Fri, Nov 20, 2015 at 12:12:21PM +0100, Arnd Bergmann wrote: > As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16 > disabled currently fails because the system call table still needs to > reference the individual function entry points that are provided by > kernel/sys_ni.c

Re: [PATCH 1/2] kbuild: add AFLAGS_REMOVE_(basename).o option

On Sat, Nov 21, 2015 at 11:59:58AM +0100, Heiko Carstens wrote: > It is already possible to remove CFLAGS with the CFLAGS_REMOVE option > that was introduced with commit 656ee82cc855 ("kbuild: create new > CFLAGS_REMOVE_(basename).o option"). However it is not possible

Re: [PATCH 1/2] kbuild: add AFLAGS_REMOVE_(basename).o option

On Mon, Nov 30, 2015 at 09:36:29AM +0100, Michal Marek wrote: > >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > >> index 79e86613712f..26a48d76eb9d 100644 > >> --- a/scripts/Makefile.lib > >> +++ b/scripts/Makefile.lib > >> @@ -104,8 +104,9 @@ modname_flags = $(if $(filter 1,$(words

Re: [PATCH v2 1/4] init: create cmdline param to disable readonly

On Mon, Nov 30, 2015 at 01:52:10PM -0800, Kees Cook wrote: > On Wed, Nov 25, 2015 at 11:51 PM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> +#ifdef CONFIG_DEBUG_RODATA > > > > Btw., could you please remove the Kconfig option altogether in an > >

Re: [PATCH 1/2] kbuild: add AFLAGS_REMOVE_(basename).o option

On Sat, Nov 21, 2015 at 11:59:58AM +0100, Heiko Carstens wrote: > It is already possible to remove CFLAGS with the CFLAGS_REMOVE option > that was introduced with commit 656ee82cc855 ("kbuild: create new > CFLAGS_REMOVE_(basename).o option"). However it is not possible

Re: [PATCH] ARM64: fix building without CONFIG_UID16

On Fri, Nov 20, 2015 at 12:12:21PM +0100, Arnd Bergmann wrote: > As reported by Michal Simek, building an ARM64 kernel with CONFIG_UID16 > disabled currently fails because the system call table still needs to > reference the individual function entry points that are provided by > kernel/sys_ni.c

Re: [PATCH 1/2] arch: consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug

k > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Benjamin Herrenschmidt > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Andrew Morton > Cc: Greg Kroah-Hartman >

Re: [PATCH 1/2] arch: consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug

lt;keesc...@chromium.org> > Cc: Russell King <li...@arm.linux.org.uk> > Cc: Catalin Marinas <catalin.mari...@arm.com> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Cc: Martin Schwidefsky <schwidef...@de.i

[PATCH 2/2] s390: compile head.s always with -march=z900

instructions which are availanble with the earliest machine generation (z900). In order to make sure we don't accidently add instructions which are not available on z900, always compile with -march=z900. This makes sure compilation will fail if wrong instructions are used. Signed-off-by: Heiko Carstens

[PATCH 1/2] kbuild: add AFLAGS_REMOVE_(basename).o option

tion which works the same like CFLAGS_REMOVE. Signed-off-by: Heiko Carstens --- scripts/Makefile.lib | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 79e86613712f..26a48d76eb9d 100644 --- a/scripts/Makefile.lib +++ b/scripts/Ma

[PATCH 0/2] kbuild: add AFLAGS_REMOVE

Hi Michal, these are just two simple patches which add 1) an AFLAGS_REMOVE option which works just like CFLAGS_REMOVE and 2) one user of it in s390 code. If you agree this is ok, then these two patches could go upstream either via your tree or the s390 tree. Thanks, Heiko Heiko Carstens (2

[PATCH 1/2] kbuild: add AFLAGS_REMOVE_(basename).o option

tion which works the same like CFLAGS_REMOVE. Signed-off-by: Heiko Carstens <heiko.carst...@de.ibm.com> --- scripts/Makefile.lib | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 79e86613712f..26a48d76eb9d 100644 --- a/scri

[PATCH 0/2] kbuild: add AFLAGS_REMOVE

Hi Michal, these are just two simple patches which add 1) an AFLAGS_REMOVE option which works just like CFLAGS_REMOVE and 2) one user of it in s390 code. If you agree this is ok, then these two patches could go upstream either via your tree or the s390 tree. Thanks, Heiko Heiko Carstens (2

[PATCH 2/2] s390: compile head.s always with -march=z900

instructions which are availanble with the earliest machine generation (z900). In order to make sure we don't accidently add instructions which are not available on z900, always compile with -march=z900. This makes sure compilation will fail if wrong instructions are used. Signed-off-by: Heiko Carstens

Re: [PATCH] s390: Delete unnecessary checks before the function call "debug_unregister"

On Mon, Nov 16, 2015 at 03:15:17PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 16 Nov 2015 14:45:40 +0100 > > The debug_unregister() function performs also input parameter validation. > Thus the test around the calls is not needed. > > This issue was detected by using

Re: [PATCH] s390: Delete unnecessary checks before the function call "debug_unregister"

On Mon, Nov 16, 2015 at 03:15:17PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 16 Nov 2015 14:45:40 +0100 > > The debug_unregister() function performs also input parameter validation. > Thus the test around the calls is not needed. > > This

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

ch/powerpc/Kconfig| 3 --- > arch/s390/Kconfig | 3 --- > arch/sh/Kconfig | 3 --- > arch/sparc/Kconfig | 4 > arch/unicore32/Kconfig | 3 --- > arch/x86/Kconfig | 3 --- > lib/Kconfig.debug | 1 - > 12 files changed, 37 deletions(

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote: > Hi Heiko, > > On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote: > > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote: > > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrot

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

3 --- > arch/parisc/Kconfig | 3 --- > arch/powerpc/Kconfig| 3 --- > arch/s390/Kconfig | 3 --- > arch/sh/Kconfig | 3 --- > arch/sparc/Kconfig | 4 > arch/unicore32/Kconfig | 3 --- > arch/x86/Kconfig | 3 --- > lib/Kc

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

On Tue, Nov 10, 2015 at 10:05:48AM +, Will Deacon wrote: > Hi Heiko, > > On Tue, Nov 10, 2015 at 08:41:24AM +0100, Heiko Carstens wrote: > > On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote: > > > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrot

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote: > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote: > > i just enable it on ARM64, > > and it can work, > > i don’t see some special requirement to enable this config . > > Right, so why does HAVE_LATENCYTOP_SUPPORT exist? If

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote: > On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote: > > i just enable it on ARM64, > > and it can work, > > i don’t see some special requirement to enable this config . > > Right, so why does HAVE_LATENCYTOP_SUPPORT exist? If

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 02:45:37PM +0200, Thomas Gleixner wrote: > The only point I found which does not update the sequence count is > timekeeping_init(). > > Does the patch below fix your issue? > Yes, it does. Thanks for looking into this and fixing it! > 8< > > diff

Re: [RFC][PATCH] sched: Start stopper early

On Fri, Oct 16, 2015 at 11:57:06AM +0200, Peter Zijlstra wrote: > On Fri, Oct 16, 2015 at 10:22:12AM +0200, Heiko Carstens wrote: > > So, actually this doesn't fix the bug and it _seems_ to be reproducible. > > > > [ FWIW, I will be offline for the next two weeks ] > &

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:54:51PM +0200, Heiko Carstens wrote: > > > So you are saying this works on x86 and it must be some s390 specific bug? > > > > Looks like. I have no idea why that would break on s390. Did you try > > to revert the commit on top of tree? >

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:35:23PM +0200, Thomas Gleixner wrote: > On Fri, 16 Oct 2015, Heiko Carstens wrote: > > On Fri, Oct 16, 2015 at 12:21:51PM +0200, Thomas Gleixner wrote: > > > Heiko, > > > > > > On Thu, 15 Oct 2015, Heiko Carstens wrote: &g

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:33:51PM +0200, Thomas Gleixner wrote: > On Fri, 16 Oct 2015, Heiko Carstens wrote: > > So you are saying this works on x86 and it must be some s390 specific bug? > > time ./f > futex-syscall returned with an error:: Connection timed out > ret = -

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:21:51PM +0200, Thomas Gleixner wrote: > Heiko, > > On Thu, 15 Oct 2015, Heiko Carstens wrote: > > /* We wait for half a second. */ > > ts.tv_nsec += 5; > > if (ts.tv_nsec >= 10) > > { > > ++ts.

Re: [RFC][PATCH] sched: Start stopper early

On Wed, Oct 07, 2015 at 10:41:10AM +0200, Peter Zijlstra wrote: > Hi, > > So Heiko reported some 'interesting' fail where stop_two_cpus() got > stuck in multi_cpu_stop() with one cpu waiting for another that never > happens. > > It _looks_ like the 'other' cpu isn't running and the current best

Re: [RFC][PATCH] sched: Start stopper early

On Wed, Oct 07, 2015 at 10:41:10AM +0200, Peter Zijlstra wrote: > Hi, > > So Heiko reported some 'interesting' fail where stop_two_cpus() got > stuck in multi_cpu_stop() with one cpu waiting for another that never > happens. > > It _looks_ like the 'other' cpu isn't running and the current best

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:21:51PM +0200, Thomas Gleixner wrote: > Heiko, > > On Thu, 15 Oct 2015, Heiko Carstens wrote: > > /* We wait for half a second. */ > > ts.tv_nsec += 5; > > if (ts.tv_nsec >= 10) > > { > > ++ts.

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:33:51PM +0200, Thomas Gleixner wrote: > On Fri, 16 Oct 2015, Heiko Carstens wrote: > > So you are saying this works on x86 and it must be some s390 specific bug? > > time ./f > futex-syscall returned with an error:: Connection timed out > ret = -

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:35:23PM +0200, Thomas Gleixner wrote: > On Fri, 16 Oct 2015, Heiko Carstens wrote: > > On Fri, Oct 16, 2015 at 12:21:51PM +0200, Thomas Gleixner wrote: > > > Heiko, > > > > > > On Thu, 15 Oct 2015, Heiko Carstens wrote: &g

Re: [RFC][PATCH] sched: Start stopper early

On Fri, Oct 16, 2015 at 11:57:06AM +0200, Peter Zijlstra wrote: > On Fri, Oct 16, 2015 at 10:22:12AM +0200, Heiko Carstens wrote: > > So, actually this doesn't fix the bug and it _seems_ to be reproducible. > > > > [ FWIW, I will be offline for the next two weeks ] > &

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 12:54:51PM +0200, Heiko Carstens wrote: > > > So you are saying this works on x86 and it must be some s390 specific bug? > > > > Looks like. I have no idea why that would break on s390. Did you try > > to revert the commit on top of tree? >

Re: futex timeout not working? (bisected)

On Fri, Oct 16, 2015 at 02:45:37PM +0200, Thomas Gleixner wrote: > The only point I found which does not update the sequence count is > timekeeping_init(). > > Does the patch below fix your issue? > Yes, it does. Thanks for looking into this and fixing it! > 8< > > diff

futex timeout not working? (bisected)

Hi Thomas, I received a bug report from Stefan Liebler that certain futex timeouts do not work anymore at least on s390 (see test case below). I did a quick bisect which ended at this commit: 868a3e915f7f5eba8f8cb4f7da2276760807c51c is the first bad commit commit

futex timeout not working? (bisected)

Hi Thomas, I received a bug report from Stefan Liebler that certain futex timeouts do not work anymore at least on s390 (see test case below). I did a quick bisect which ended at this commit: 868a3e915f7f5eba8f8cb4f7da2276760807c51c is the first bad commit commit

Re: [PATCH 2/2] s390/crash_dump: Use PFN_PHYS and PFN_DOWN macros

On Wed, Sep 16, 2015 at 12:54:38AM +0600, Alexander Kuleshov wrote: > The provides PFN_PHYS and PFN_DOWN macros for the > getting page frame number and physical address of a page frame number. > This patch replaces (pfn << PAGE_SHIFT) and (addr >> PAGE_SHIFT) > expressions with the PFN_PHYS and

Re: [PATCH 1/2] s390/crash_dump: Use for_each_mem_range

On Wed, Sep 16, 2015 at 12:54:24AM +0600, Alexander Kuleshov wrote: > The already provides for_each_mem_range() macro that > iterates through memblock areas from type_a and not included in type_b. > We can remove custom for_each_dump_mem_range() macro and use the > for_each_mem_range() instead. >

Re: [PATCH 1/2] s390/crash_dump: Use for_each_mem_range

On Wed, Sep 16, 2015 at 12:54:24AM +0600, Alexander Kuleshov wrote: > The already provides for_each_mem_range() macro that > iterates through memblock areas from type_a and not included in type_b. > We can remove custom for_each_dump_mem_range() macro and use the > for_each_mem_range() instead. >

Re: [PATCH 2/2] s390/crash_dump: Use PFN_PHYS and PFN_DOWN macros

On Wed, Sep 16, 2015 at 12:54:38AM +0600, Alexander Kuleshov wrote: > The provides PFN_PHYS and PFN_DOWN macros for the > getting page frame number and physical address of a page frame number. > This patch replaces (pfn << PAGE_SHIFT) and (addr >> PAGE_SHIFT) > expressions with the PFN_PHYS and

Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section

On Tue, Sep 15, 2015 at 09:41:49AM +0200, Willy Tarreau wrote: > On Tue, Sep 15, 2015 at 08:09:27AM +0200, Heiko Carstens wrote: > > On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote: > > > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote: > > > >

Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section

On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote: > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote: > > 2.6.32-longterm review patch. If anyone has any objections, please let me > > know. > > > > ------ > > > >

Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section

On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote: > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote: > > 2.6.32-longterm review patch. If anyone has any objections, please let me > > know. > > > > ------ > > > > From: He

Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section

On Tue, Sep 15, 2015 at 09:41:49AM +0200, Willy Tarreau wrote: > On Tue, Sep 15, 2015 at 08:09:27AM +0200, Heiko Carstens wrote: > > On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote: > > > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote: > > > >

Re: [PATCH] x86: Wire up 32-bit direct socket calls

On Mon, Sep 07, 2015 at 02:53:12PM +0200, Arnd Bergmann wrote: > On Wednesday 02 September 2015 13:16:19 H. Peter Anvin wrote: > > On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > > > > > Should all other architectures follow suit? > > > Or should we follow the s390 approach: > > > > > > >

Re: [PATCH] x86: Wire up 32-bit direct socket calls

On Mon, Sep 07, 2015 at 02:53:12PM +0200, Arnd Bergmann wrote: > On Wednesday 02 September 2015 13:16:19 H. Peter Anvin wrote: > > On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > > > > > Should all other architectures follow suit? > > > Or should we follow the s390 approach: > > > > > > >

Re: [PATCH] [s390]: Use .rept directive to store/load fpu registers

On Tue, Sep 01, 2015 at 09:51:32AM +0200, Christian Borntraeger wrote: > Am 28.08.2015 um 15:49 schrieb Alexander Kuleshov: > > arch/s390/kernel/swsusp.S | 49 > > --- > > 1 file changed, 17 insertions(+), 32 deletions(-) > > > > diff --git

Re: [PATCH] [s390]: Use .rept directive to store/load fpu registers

On Tue, Sep 01, 2015 at 09:51:32AM +0200, Christian Borntraeger wrote: > Am 28.08.2015 um 15:49 schrieb Alexander Kuleshov: > > arch/s390/kernel/swsusp.S | 49 > > --- > > 1 file changed, 17 insertions(+), 32 deletions(-) > > > > diff --git

Re: [PATCH -next] s390: lib: Export __delay

On Tue, Aug 04, 2015 at 11:38:23PM -0700, Guenter Roeck wrote: > __delay is exported by most architectures, and may be used in modules. > Since it is not exported for s390, s390:allmodconfig currently fails > to build with > > ERROR: "__delay" [drivers/net/phy/mdio-octeon.ko] undefined! > >

Re: [PATCH 2/2] s390: Remove unneeded variables

On Tue, Aug 04, 2015 at 05:11:47PM +0200, Peter Senna Tschudin wrote: > This patch remove unneeded variables used to store return values. > > These issues were detected with the Coccinelle script: > scripts/coccinelle/misc/returnvar.cocci > > Signed-off-by: Peter Senna Tschudin > --- > static

Re: [PATCH 1/2] s390: Remove unneeded semicolon

On Tue, Aug 04, 2015 at 05:11:15PM +0200, Peter Senna Tschudin wrote: > Remove unneeded semicolon. > > The semantic patch that detects this change is available > at scripts/coccinelle/misc/semicolon.cocci. > > Signed-off-by: Peter Senna Tschudin > --- > Tested by cross compilation only. > >

Re: [PATCH 1/2] s390: Remove unneeded semicolon

On Tue, Aug 04, 2015 at 05:11:15PM +0200, Peter Senna Tschudin wrote: Remove unneeded semicolon. The semantic patch that detects this change is available at scripts/coccinelle/misc/semicolon.cocci. Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com --- Tested by cross compilation

Re: [PATCH 2/2] s390: Remove unneeded variables

On Tue, Aug 04, 2015 at 05:11:47PM +0200, Peter Senna Tschudin wrote: This patch remove unneeded variables used to store return values. These issues were detected with the Coccinelle script: scripts/coccinelle/misc/returnvar.cocci Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com

Re: [PATCH -next] s390: lib: Export __delay

On Tue, Aug 04, 2015 at 11:38:23PM -0700, Guenter Roeck wrote: __delay is exported by most architectures, and may be used in modules. Since it is not exported for s390, s390:allmodconfig currently fails to build with ERROR: __delay [drivers/net/phy/mdio-octeon.ko] undefined! Fixes:

[tip:locking/core] s390/uaccess, locking/static_keys: employ static_branch_likely()

Commit-ID: ed79e946732e5311934d7f404b3b4e702e45cb97 Gitweb: http://git.kernel.org/tip/ed79e946732e5311934d7f404b3b4e702e45cb97 Author: Heiko Carstens AuthorDate: Wed, 29 Jul 2015 08:31:24 +0200 Committer: Ingo Molnar CommitDate: Mon, 3 Aug 2015 11:34:17 +0200 s390/uaccess, locking

<    4   5   6   7   8   9   10   11   12   13   >