Re: [PATCH] s390/cio: fix intparm documentation

On Wed, 11 Sep 2019, Cornelia Huck wrote: > The common I/O layer is maintaining an "intparm" inspired by > the hardware intparm for driver usage. This "intparm" is not > only applicaple for ssch, but also for hsch/csch. The kerneldoc > states that it is only updated for hsch/csch if no prior

Re: [PATCH v2 02/10] s390/pci: Loop using PCI_STD_NUM_BARS

+--- > arch/s390/pci/pci.c | 16 > arch/s390/pci/pci_clp.c | 6 +++--- > 4 files changed, 15 insertions(+), 18 deletions(-) > Acked-by: Sebastian Ott

Re: [PATCH] s390/pci: PCI_IOV_RESOURCES loop refactoring in zpci_map_resources

On Tue, 6 Aug 2019, Denis Efremov wrote: > This patch alters the for loop iteration scheme in zpci_map_resources > to make it more usual. Thus, the patch generalizes the style for > PCI_IOV_RESOURCES iteration and improves readability. > > Signed-off-by: Denis Efremov Applied for inclusion via

Re: [PATCH] s390/cio: introduce driver_override on the css bus

t; > Note that unlike pci we still require a driver override to > match the subchannel type; matching more than one subchannel > type is probably not useful anyway. > > Signed-off-by: Cornelia Huck Reviewed-by: Sebastian Ott Should I take that via our git tree or do you have other patches depending on this one?

Re: [RFC PATCH 01/57] drivers: s390/cio: Use driver_for_each_device

On Mon, 3 Jun 2019, Suzuki K Poulose wrote: > The cio driver use driver_find_device() to find all devices > to release them before the driver is unregistered. Instead, > it could easily use a lighter driver_for_each_device() helper > to iterate over all the devices. > > Cc: S

too large sg segments with commit 09324d32d2a08

Hi, this warning turned up on s390: [7.041512] [ cut here ] [7.041518] DMA-API: nvme :00:00.0: mapping sg segment longer than device claims to support [len=106496] [max=65536] [7.041531] WARNING: CPU: 1 PID: 229 at kernel/dma/debug.c:1233

Re: [PATCH 07/12] s390: cio: fix cio_irb declaration

On Mon, 8 Apr 2019, Arnd Bergmann wrote: > clang points out that the declaration of cio_irb does not match the > definition exactly, it is missing the alignment attribute: > > ../drivers/s390/cio/cio.c:50:1: warning: section does not match previous > declaration [-Wsection] >

Re: [PATCH v3] zcrypt: handle AP Info notification from CHSC SEI command

On Mon, 11 Mar 2019, Tony Krowiak wrote: > On 2/18/19 12:01 PM, Tony Krowiak wrote: > > The current AP bus implementation periodically polls the AP configuration > > to detect changes. When the AP configuration is dynamically changed via the > > SE or an SCLP instruction, the changes will not be

Re: [PATCH v2] zcrypt: handle AP Info notification from CHSC SEI command

On Wed, 6 Feb 2019, Tony Krowiak wrote: > diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c > +void ap_bus_cfg_chg(void) > +{ > + AP_DBF(DBF_INFO, "%s config change, forcing bus rescan\n", __func__); > + > + ap_bus_force_rescan(); > +} >

Re: [PATCH] zcrypt: handle AP Info notification from CHSC SEI command

On Thu, 31 Jan 2019, Tony Krowiak wrote: > On 1/30/19 1:32 PM, Sebastian Ott wrote: > > On Wed, 30 Jan 2019, Tony Krowiak wrote: > >> +++ b/drivers/s390/cio/chsc.h > >> @@ -9,6 +9,7 @@ > >> #include > >> #include > >> #include > >

Re: [PATCH] zcrypt: handle AP Info notification from CHSC SEI command

from module code. As an unrelated question, just to be sure: ap_bus.c is compiled as built-in even with ZCRYPT=m, right? Reviewed-by: Sebastian Ott Regards, Sebastian

Re: [PATCH] s390: pci: no need to check return value of debugfs_create functions

iko Carstens > Cc: Sebastian Ott > Cc: Gerald Schaefer > Cc: linux-s...@vger.kernel.org > Signed-off-by: Greg Kroah-Hartman Applied for inclusion via s390/linux.git Thanks!

Re: [PATCH] s390: convert to DEFINE_SHOW_ATTRIBUTE

On Sat, 1 Dec 2018, Yangtao Li wrote: > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li > --- > drivers/s390/block/dasd.c | 15 +-- > drivers/s390/cio/qdio_debug.c | 16 ++-- > 2 files changed, 3 insertions(+), 28 deletions(-)

Re: [PATCH] s390: convert to DEFINE_SHOW_ATTRIBUTE

On Sat, 1 Dec 2018, Yangtao Li wrote: > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li > --- > drivers/s390/block/dasd.c | 15 +-- > drivers/s390/cio/qdio_debug.c | 16 ++-- > 2 files changed, 3 insertions(+), 28 deletions(-)

[PATCH] s390/cio: make vfio_ccw_io_region static

Fix the following sparse warning: drivers/s390/cio/vfio_ccw_drv.c:25:19: warning: symbol 'vfio_ccw_io_region' was not declared. Should it be static? Signed-off-by: Sebastian Ott --- drivers/s390/cio/vfio_ccw_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/s390

[PATCH] s390/cio: make vfio_ccw_io_region static

Fix the following sparse warning: drivers/s390/cio/vfio_ccw_drv.c:25:19: warning: symbol 'vfio_ccw_io_region' was not declared. Should it be static? Signed-off-by: Sebastian Ott --- drivers/s390/cio/vfio_ccw_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/s390

Re: [GIT PULL] two more s390 bug fixes for 4.17

Hello, On Wed, 30 May 2018, Sebastian Ott wrote: > On Wed, 30 May 2018, Christoph Hellwig wrote: > > > - req->completion_data = cqr; > > > + *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr; > > > + > > > > Please don't play such tricks. In

Re: [GIT PULL] two more s390 bug fixes for 4.17

Hello, On Wed, 30 May 2018, Sebastian Ott wrote: > On Wed, 30 May 2018, Christoph Hellwig wrote: > > > - req->completion_data = cqr; > > > + *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr; > > > + > > > > Please don't play such tricks. In

Re: [GIT PULL] two more s390 bug fixes for 4.17

On Wed, 30 May 2018, Christoph Hellwig wrote: > > - req->completion_data = cqr; > > + *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr; > > + > > Please don't play such tricks. In general your driver structure > should have struct request embedded. If for some reason > struct

Re: [GIT PULL] two more s390 bug fixes for 4.17

On Wed, 30 May 2018, Christoph Hellwig wrote: > > - req->completion_data = cqr; > > + *((struct dasd_ccw_req **) blk_mq_rq_to_pdu(req)) = cqr; > > + > > Please don't play such tricks. In general your driver structure > should have struct request embedded. If for some reason > struct

Re: [PATCH v9 2/2] blk-mq: Rework blk-mq timeout handling again

On Mon, 14 May 2018, Bart Van Assche wrote: > Recently the blk-mq timeout handling code was reworked. See also Tejun > Heo, "[PATCHSET v4] blk-mq: reimplement timeout handling", 08 Jan 2018 > (https://www.mail-archive.com/linux-block@vger.kernel.org/msg16985.html). > This patch reworks the blk-mq

Re: [PATCH v9 2/2] blk-mq: Rework blk-mq timeout handling again

On Mon, 14 May 2018, Bart Van Assche wrote: > Recently the blk-mq timeout handling code was reworked. See also Tejun > Heo, "[PATCHSET v4] blk-mq: reimplement timeout handling", 08 Jan 2018 > (https://www.mail-archive.com/linux-block@vger.kernel.org/msg16985.html). > This patch reworks the blk-mq

Re: make TAGS broken with commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources()...")

On Thu, 26 Apr 2018, Sebastian Ott wrote: > on my s390 test system make TAGS is broken since commit 99443f811c452c6 > ("scripts/tags.sh: change find_other_sources() for include directories") > > # make TAGS > GEN TAGS > xargs: etags: terminated by signal 11 >

Re: make TAGS broken with commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources()...")

On Thu, 26 Apr 2018, Sebastian Ott wrote: > on my s390 test system make TAGS is broken since commit 99443f811c452c6 > ("scripts/tags.sh: change find_other_sources() for include directories") > > # make TAGS > GEN TAGS > xargs: etags: terminated by signal 11 >

make TAGS broken with commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources()...")

Hi, on my s390 test system make TAGS is broken since commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources() for include directories") # make TAGS GEN TAGS xargs: etags: terminated by signal 11 This is a rather old etags from fedora 24. On x86 using a more recent etags

make TAGS broken with commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources()...")

Hi, on my s390 test system make TAGS is broken since commit 99443f811c452c6 ("scripts/tags.sh: change find_other_sources() for include directories") # make TAGS GEN TAGS xargs: etags: terminated by signal 11 This is a rather old etags from fedora 24. On x86 using a more recent etags

Re: [BUG, PATCH] random: sleep in irq context

On Mon, 23 Apr 2018, Sebastian Ott wrote: > This happend once during boot and I could not reproduce this since, but I > think the following patch should fix the issue: I can now recreate the issue reliably. The following patch works for me: -->8 >From 6bbfab86beae8fe8b6efeffd08c9

Re: [BUG, PATCH] random: sleep in irq context

On Mon, 23 Apr 2018, Sebastian Ott wrote: > This happend once during boot and I could not reproduce this since, but I > think the following patch should fix the issue: I can now recreate the issue reliably. The following patch works for me: -->8 >From 6bbfab86beae8fe8b6efeffd08c9

Re: [BUG, PATCH] random: sleep in irq context

On Mon, 23 Apr 2018, Sebastian Ott wrote: > From 9d29e0c92efaf94277bc178782523283958ae8c8 Mon Sep 17 00:00:00 2001 > From: Sebastian Ott <seb...@linux.ibm.com> > Date: Mon, 23 Apr 2018 14:59:20 +0200 > Subject: [PATCH] random: don't sleep during allocations in irq context > &

Re: [BUG, PATCH] random: sleep in irq context

On Mon, 23 Apr 2018, Sebastian Ott wrote: > From 9d29e0c92efaf94277bc178782523283958ae8c8 Mon Sep 17 00:00:00 2001 > From: Sebastian Ott > Date: Mon, 23 Apr 2018 14:59:20 +0200 > Subject: [PATCH] random: don't sleep during allocations in irq context > > Since numa_crng_init()

[BUG, PATCH] random: sleep in irq context

idle+0x32/0x50 [<008e659e>] default_idle_call+0x3e/0x68 [<001889aa>] do_idle+0xea/0x1c0 [<00188d26>] cpu_startup_entry+0x3e/0x48 [<0011758e>] smp_start_secondary+0x13e/0x158 [<008e87a2>] restart_int_handler+0x5a/0x70 [

[BUG, PATCH] random: sleep in irq context

idle+0x32/0x50 [<008e659e>] default_idle_call+0x3e/0x68 [<001889aa>] do_idle+0xea/0x1c0 [<00188d26>] cpu_startup_entry+0x3e/0x48 [<0011758e>] smp_start_secondary+0x13e/0x158 [<008e87a2>] restart_int_handler+0x5a/0x70 [&l

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, 9 Apr 2018, Linus Torvalds wrote: > On Mon, Apr 9, 2018 at 10:03 AM, Linus Torvalds > wrote: > > > > Our old "min()" had the internal variables called "min1" and "min2", > > which is crazy too. > > Actually, no, it used the really cumbersome "__UNIQUE_ID"

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, 9 Apr 2018, Linus Torvalds wrote: > On Mon, Apr 9, 2018 at 10:03 AM, Linus Torvalds > wrote: > > > > Our old "min()" had the internal variables called "min1" and "min2", > > which is crazy too. > > Actually, no, it used the really cumbersome "__UNIQUE_ID" and then > passed that odd as

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, 9 Apr 2018, Linus Torvalds wrote: > On Mon, Apr 9, 2018 at 9:18 AM, Sebastian Ott <seb...@linux.ibm.com> wrote: > > > > Both of the following return 0 on my machine: > > + pr_warn("%u\n", min_not_zero(100, 1000)); > > + pr_warn(

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, 9 Apr 2018, Linus Torvalds wrote: > On Mon, Apr 9, 2018 at 9:18 AM, Sebastian Ott wrote: > > > > Both of the following return 0 on my machine: > > + pr_warn("%u\n", min_not_zero(100, 1000)); > > + pr_warn("%u\n", min_not_

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, 9 Apr 2018, Sebastian Ott wrote: > On Fri, 6 Apr 2018, Kees Cook wrote: > > On Fri, Apr 6, 2018 at 2:47 AM, Sebastian Ott <seb...@linux.vnet.ibm.com> > > wrote: > > > Today's kernel oopsed on s390. Bisect points to: > > > 3c8ba0d61d04 ("

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Mon, 9 Apr 2018, Sebastian Ott wrote: > On Fri, 6 Apr 2018, Kees Cook wrote: > > On Fri, Apr 6, 2018 at 2:47 AM, Sebastian Ott > > wrote: > > > Today's kernel oopsed on s390. Bisect points to: > > > 3c8ba0d61d04 ("kernel.h: Retain constant

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Fri, 6 Apr 2018, Kees Cook wrote: > On Fri, Apr 6, 2018 at 2:47 AM, Sebastian Ott <seb...@linux.vnet.ibm.com> > wrote: > > Today's kernel oopsed on s390. Bisect points to: > > 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") > &g

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Fri, 6 Apr 2018, Kees Cook wrote: > On Fri, Apr 6, 2018 at 2:47 AM, Sebastian Ott > wrote: > > Today's kernel oopsed on s390. Bisect points to: > > 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") > > > > [1.898277]

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Fri, 6 Apr 2018, Kees Cook wrote: > On Fri, Apr 6, 2018 at 9:47 AM, Kees Cook <keesc...@chromium.org> wrote: > > On Fri, Apr 6, 2018 at 2:47 AM, Sebastian Ott <seb...@linux.vnet.ibm.com> > > wrote: > >> Today's kernel oopsed on s390. Bisect points to:

Re: [bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

On Fri, 6 Apr 2018, Kees Cook wrote: > On Fri, Apr 6, 2018 at 9:47 AM, Kees Cook wrote: > > On Fri, Apr 6, 2018 at 2:47 AM, Sebastian Ott > > wrote: > >> Today's kernel oopsed on s390. Bisect points to: > >> 3c8ba0d61d04 ("kernel.h: Retain constant

[bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

Hi, Today's kernel oopsed on s390. Bisect points to: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") [1.898277] dasd-eckd 0.0.3304: DASD with 4 KB/block, 21636720 KB total size, 48 KB/track, compatible disk layout [1.898308] [ cut here

[bisected] 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91 oopses on s390

Hi, Today's kernel oopsed on s390. Bisect points to: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") [1.898277] dasd-eckd 0.0.3304: DASD with 4 KB/block, 21636720 KB total size, 48 KB/track, compatible disk layout [1.898308] [ cut here

Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

On Tue, 27 Mar 2018, Christoph Hellwig wrote: > On Tue, Mar 27, 2018 at 05:24:10PM +0200, Sebastian Ott wrote: > > What do you mean by current implementations? Arch specific code? At least > > on s390 we don't do that. dma-mapping.h doesn't do it either. > > The arch impl

Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

On Tue, 27 Mar 2018, Christoph Hellwig wrote: > On Tue, Mar 27, 2018 at 05:24:10PM +0200, Sebastian Ott wrote: > > What do you mean by current implementations? Arch specific code? At least > > on s390 we don't do that. dma-mapping.h doesn't do it either. > > The arch impl

Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

On Tue, 27 Mar 2018, Christoph Hellwig wrote: > On Tue, Mar 27, 2018 at 10:12:54AM +0200, Sebastian Ott wrote: > > Hi, > > > > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma > > allocations specifying __GFP_ZERO by silently removing that flag. >

Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

On Tue, 27 Mar 2018, Christoph Hellwig wrote: > On Tue, Mar 27, 2018 at 10:12:54AM +0200, Sebastian Ott wrote: > > Hi, > > > > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma > > allocations specifying __GFP_ZERO by silently removing that flag. >

Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

Hello Geert, On Tue, 27 Mar 2018, Geert Uytterhoeven wrote: > On Tue, Mar 27, 2018 at 10:12 AM, Sebastian Ott > <seb...@linux.vnet.ibm.com> wrote: > > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma > > allocations specifying __GFP_ZERO by silently remo

Re: dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

Hello Geert, On Tue, 27 Mar 2018, Geert Uytterhoeven wrote: > On Tue, Mar 27, 2018 at 10:12 AM, Sebastian Ott > wrote: > > commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma > > allocations specifying __GFP_ZERO by silently removing that flag. > > Ho

dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

Hi, commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma allocations specifying __GFP_ZERO by silently removing that flag. Why should "the memory returned [] always be zeroed."? Regards, Sebastian

dma_zalloc_coherent broken with 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7

Hi, commit 57bf5a8963f80fb3828c46c3e3a5b2dd790e09a7 broke usage of dma allocations specifying __GFP_ZERO by silently removing that flag. Why should "the memory returned [] always be zeroed."? Regards, Sebastian

[PATCH] kvm: fix warning for CONFIG_HAVE_KVM_EVENTFD builds

Move the kvm_arch_irq_routing_update() prototype outside of ifdef CONFIG_HAVE_KVM_EVENTFD guards to fix the following sparse warning: arch/s390/kvm/../../../virt/kvm/irqchip.c:171:28: warning: symbol 'kvm_arch_irq_routing_update' was not declared. Should it be static? Signed-off-by: Sebastian

[PATCH] kvm: fix warning for CONFIG_HAVE_KVM_EVENTFD builds

Move the kvm_arch_irq_routing_update() prototype outside of ifdef CONFIG_HAVE_KVM_EVENTFD guards to fix the following sparse warning: arch/s390/kvm/../../../virt/kvm/irqchip.c:171:28: warning: symbol 'kvm_arch_irq_routing_update' was not declared. Should it be static? Signed-off-by: Sebastian

[PATCH] kvm: fix warning for non-x86 builds

' was not declared. Should it be static? Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- arch/x86/include/asm/kvm_host.h | 3 --- include/linux/kvm_host.h| 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_

[PATCH] kvm: fix warning for non-x86 builds

' was not declared. Should it be static? Signed-off-by: Sebastian Ott --- arch/x86/include/asm/kvm_host.h | 3 --- include/linux/kvm_host.h| 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index dd6f57a54a26

Re: [PATCH] PCI: Add SPDX GPL-2.0+ to replace implicit GPL v2 or later statement

identifier to files with no license") that the SPDX identifier may be used > instead of the full boilerplate text. > > Signed-off-by: Bjorn Helgaas <bhelg...@google.com> Acked-by: Sebastian Ott <seb...@linux.vnet.ibm.com>

Re: [PATCH] PCI: Add SPDX GPL-2.0+ to replace implicit GPL v2 or later statement

> subsequently replaced the MODULE_LICENSE() with a "License: GPL" comment. > > Add SPDX GPL-2.0+ and remove the "License: GPL" comment, relying on the > assertion in b24413180f56 ("License cleanup: add SPDX GPL-2.0 license > identifier to files with no license") that the SPDX identifier may be used > instead of the full boilerplate text. > > Signed-off-by: Bjorn Helgaas Acked-by: Sebastian Ott

Re: [PATCH 0/3] s390: documentation update

On Tue, 23 Jan 2018, Cornelia Huck wrote: > Cornelia Huck (3): > s390/docs: mention subchannel types > s390/docs: reword airq section > s390/cmf: fix kerneldoc All applied. Thanks!

Re: [PATCH 0/3] s390: documentation update

On Tue, 23 Jan 2018, Cornelia Huck wrote: > Cornelia Huck (3): > s390/docs: mention subchannel types > s390/docs: reword airq section > s390/cmf: fix kerneldoc All applied. Thanks!

Re: [PATCH 3/3] s390/cmf: fix kerneldoc

On Tue, 23 Jan 2018, Cornelia Huck wrote: > Make sure we use proper Return sections, and make the output > for cmf_enable() less odd. > > Signed-off-by: Cornelia Huck > --- > +++ b/drivers/s390/cio/cmf.c > @@ -1118,9 +1118,10 @@ int ccw_set_cmf(struct ccw_device *cdev, int

Re: [PATCH 3/3] s390/cmf: fix kerneldoc

On Tue, 23 Jan 2018, Cornelia Huck wrote: > Make sure we use proper Return sections, and make the output > for cmf_enable() less odd. > > Signed-off-by: Cornelia Huck > --- > +++ b/drivers/s390/cio/cmf.c > @@ -1118,9 +1118,10 @@ int ccw_set_cmf(struct ccw_device *cdev, int enable) > *

Re: [bisected] system hang after boot

On Mon, 27 Nov 2017, Will Deacon wrote: > Sebastian: could you try the diff below, please? If that fixes s390, then > we can debate the merits of GENERIC_LOCKBREAK independently of fixing this > issue. > > Thanks, > > Will > > --->8 > > diff --git a/kernel/locking/spinlock.c

Re: [bisected] system hang after boot

On Mon, 27 Nov 2017, Will Deacon wrote: > Sebastian: could you try the diff below, please? If that fixes s390, then > we can debate the merits of GENERIC_LOCKBREAK independently of fixing this > issue. > > Thanks, > > Will > > --->8 > > diff --git a/kernel/locking/spinlock.c

Re: [bisected] system hang after boot

Hello Will, On Wed, 22 Nov 2017, Will Deacon wrote: > Now, I can't see what the break_lock is doing here other than causing > problems. Is there a good reason for it, or can you just try removing it > altogether? Patch below. With your patch applied the system is able to boot again. I did some

Re: [bisected] system hang after boot

Hello Will, On Wed, 22 Nov 2017, Will Deacon wrote: > Now, I can't see what the break_lock is doing here other than causing > problems. Is there a good reason for it, or can you just try removing it > altogether? Patch below. With your patch applied the system is able to boot again. I did some

[bisected] system hang after boot

Hi, One of my test systems (s390) hangs after boot. One of the cpus is idle the other is in arch_spin_relax. Bisect pointed to this one: a8a217c22116eff6c120d753c9934089fb229af0 is the first bad commit commit a8a217c22116eff6c120d753c9934089fb229af0 Author: Will Deacon

[bisected] system hang after boot

Hi, One of my test systems (s390) hangs after boot. One of the cpus is idle the other is in arch_spin_relax. Bisect pointed to this one: a8a217c22116eff6c120d753c9934089fb229af0 is the first bad commit commit a8a217c22116eff6c120d753c9934089fb229af0 Author: Will Deacon Date: Tue Oct 3

Re: [PATCH] s390: qdio: Convert timers to use timer_setup()

On Thu, 5 Oct 2017, Kees Cook wrote: > On Thu, Oct 5, 2017 at 2:13 AM, Sebastian Ott <seb...@linux.vnet.ibm.com> > wrote: > > On Wed, 4 Oct 2017, Kees Cook wrote: > >> In preparation for unconditionally passing the struct timer_list pointer to > >> all time

Re: [PATCH] s390: qdio: Convert timers to use timer_setup()

On Thu, 5 Oct 2017, Kees Cook wrote: > On Thu, Oct 5, 2017 at 2:13 AM, Sebastian Ott > wrote: > > On Wed, 4 Oct 2017, Kees Cook wrote: > >> In preparation for unconditionally passing the struct timer_list pointer to > >> all timer callbacks, switch to using the ne

Re: [PATCH] s390: qdio: Convert timers to use timer_setup()

On Wed, 4 Oct 2017, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > -void qdio_outbound_timer(unsigned long data) > +void

Re: [PATCH] s390: qdio: Convert timers to use timer_setup()

On Wed, 4 Oct 2017, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > -void qdio_outbound_timer(unsigned long data) > +void

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Tue, 15 Aug 2017, Joerg Roedel wrote: > On Tue, Aug 15, 2017 at 06:02:20PM +0200, Sebastian Ott wrote: > > On Mon, 14 Aug 2017, Joerg Roedel wrote: > > > I attach the patch I wrote to fix this, can you please test it together > > > with the initial patch in this thr

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Tue, 15 Aug 2017, Joerg Roedel wrote: > On Tue, Aug 15, 2017 at 06:02:20PM +0200, Sebastian Ott wrote: > > On Mon, 14 Aug 2017, Joerg Roedel wrote: > > > I attach the patch I wrote to fix this, can you please test it together > > > with the initial patch in this thr

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Mon, 14 Aug 2017, Joerg Roedel wrote: > I attach the patch I wrote to fix this, can you please test it together > with the initial patch in this thread? I did and can confirm that everything worked as expected! Thanks, Sebastian

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Mon, 14 Aug 2017, Joerg Roedel wrote: > I attach the patch I wrote to fix this, can you please test it together > with the initial patch in this thread? I did and can confirm that everything worked as expected! Thanks, Sebastian

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Fri, 11 Aug 2017, Sebastian Ott wrote: > * That patch embedded a struct iommu_device within struct zpci_dev but > the iommu_device has a release function (via its class) - so when > the release function gets called it frees memory that was never allocated. > The fix is to not e

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Fri, 11 Aug 2017, Sebastian Ott wrote: > * That patch embedded a struct iommu_device within struct zpci_dev but > the iommu_device has a release function (via its class) - so when > the release function gets called it frees memory that was never allocated. > The fix is to not e

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Fri, 11 Aug 2017, Sebastian Ott wrote: > * iommu_release_device must not release the struct device but the > structure it is embedded in: struct iommu_device (I'll send a patch > for that) --->8 >From 2839c92e038af47b8cb569f84d571878c54d1815 Mon Sep 17 00:00:00 2001 From: Seb

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Fri, 11 Aug 2017, Sebastian Ott wrote: > * iommu_release_device must not release the struct device but the > structure it is embedded in: struct iommu_device (I'll send a patch > for that) --->8 >From 2839c92e038af47b8cb569f84d571878c54d1815 Mon Sep 17 00:00:00 2001 From: Seba

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

Hello Joerg, On Fri, 11 Aug 2017, Joerg Roedel wrote: > Hey Sebastian, > > On Thu, Aug 10, 2017 at 09:07:06PM +0200, Sebastian Ott wrote: > > With this patch pci hot-unplug fails with a use after free or refcounting > > issue - I'm currently trying to understand what's go

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

Hello Joerg, On Fri, 11 Aug 2017, Joerg Roedel wrote: > Hey Sebastian, > > On Thu, Aug 10, 2017 at 09:07:06PM +0200, Sebastian Ott wrote: > > With this patch pci hot-unplug fails with a use after free or refcounting > > issue - I'm currently trying to understand what's go

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Wed, 9 Aug 2017, Joerg Roedel wrote: > From: Joerg Roedel > > Add support for the iommu_device_register interface to make > the s390 hardware iommus visible to the iommu core and in > sysfs. > With this patch pci hot-unplug fails with a use after free or refcounting issue -

Re: [PATCH v3] iommu/s390: Add support for iommu_device handling

On Wed, 9 Aug 2017, Joerg Roedel wrote: > From: Joerg Roedel > > Add support for the iommu_device_register interface to make > the s390 hardware iommus visible to the iommu core and in > sysfs. > With this patch pci hot-unplug fails with a use after free or refcounting issue - I'm currently

Re: lockdep warning: console vs. mem hotplug

Hello Sergey, On Tue, 21 Mar 2017, Sergey Senozhatsky wrote: > // I kept only lockdep splats from the original report and cut off .configs > // full version: > // lkml.kernel.org/r/alpine.LFD.2.20.1703201736070.1753@schleppi > > On (03/20/17 17:43), Sebastian Ott wrote: &

Re: lockdep warning: console vs. mem hotplug

Hello Sergey, On Tue, 21 Mar 2017, Sergey Senozhatsky wrote: > // I kept only lockdep splats from the original report and cut off .configs > // full version: > // lkml.kernel.org/r/alpine.LFD.2.20.1703201736070.1753@schleppi > > On (03/20/17 17:43), Sebastian Ott wrote: &

[tip:irq/urgent] genirq/debugfs: Fix build for !CONFIG_IRQ_DOMAIN

Commit-ID: e5682b4eecb2b73282853d0ef314d3164b986997 Gitweb: http://git.kernel.org/tip/e5682b4eecb2b73282853d0ef314d3164b986997 Author: Sebastian Ott <seb...@linux.vnet.ibm.com> AuthorDate: Tue, 4 Jul 2017 11:25:15 +0200 Committer: Thomas Gleixner <t...@linutronix.de> Commit

[tip:irq/urgent] genirq/debugfs: Fix build for !CONFIG_IRQ_DOMAIN

Commit-ID: e5682b4eecb2b73282853d0ef314d3164b986997 Gitweb: http://git.kernel.org/tip/e5682b4eecb2b73282853d0ef314d3164b986997 Author: Sebastian Ott AuthorDate: Tue, 4 Jul 2017 11:25:15 +0200 Committer: Thomas Gleixner CommitDate: Tue, 4 Jul 2017 12:36:43 +0200 genirq/debugfs: Fix

[PATCH] genirq/debugfs: fix build for !CONFIG_IRQ_DOMAIN

-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- kernel/irq/internals.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h index 9da14d1..dbfba99 100644 --- a/kernel/irq/internals.h +++ b/kernel/irq/internals.h @@ -437,7

[PATCH] genirq/debugfs: fix build for !CONFIG_IRQ_DOMAIN

-by: Sebastian Ott --- kernel/irq/internals.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h index 9da14d1..dbfba99 100644 --- a/kernel/irq/internals.h +++ b/kernel/irq/internals.h @@ -437,7 +437,9 @@ static inline void

Re: linux-next: build failure after merge of the block tree

On Thu, 15 Jun 2017, Sebastian Ott wrote: > On Tue, 13 Jun 2017, Stephen Rothwell wrote: > > After merging the block tree, today's linux-next build (s390x > > s390-defconfig) failed like this: > > > > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY'

Re: linux-next: build failure after merge of the block tree

On Thu, 15 Jun 2017, Sebastian Ott wrote: > On Tue, 13 Jun 2017, Stephen Rothwell wrote: > > After merging the block tree, today's linux-next build (s390x > > s390-defconfig) failed like this: > > > > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY'

Re: linux-next: build failure after merge of the block tree

On Tue, 13 Jun 2017, Stephen Rothwell wrote: > After merging the block tree, today's linux-next build (s390x > s390-defconfig) failed like this: > > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared > (first use in this function) > drivers/s390/block/scm_blk.c:327:9:

Re: linux-next: build failure after merge of the block tree

On Tue, 13 Jun 2017, Stephen Rothwell wrote: > After merging the block tree, today's linux-next build (s390x > s390-defconfig) failed like this: > > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared > (first use in this function) > drivers/s390/block/scm_blk.c:327:9:

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

Hi, On Tue, 13 Jun 2017, Christoph Hellwig wrote: > Btw, scm_blk.c blk-mq conversion seems odd if not broken. It should > always call blk_mq_complete_request from scm_request_finish and > then pass the error to blk_mq_end_request frin > there. OK. I had added that because rq->errors went away.

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

Hi, On Tue, 13 Jun 2017, Christoph Hellwig wrote: > Btw, scm_blk.c blk-mq conversion seems odd if not broken. It should > always call blk_mq_complete_request from scm_request_finish and > then pass the error to blk_mq_end_request frin > there. OK. I had added that because rq->errors went away.

Re: Oops with commit 6d18c73 bridge: start hello_timer when enabling KERNEL_STP in br_stp_start

On Thu, 1 Jun 2017, Xin Long wrote: > On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott > <seb...@linux.vnet.ibm.com> wrote: > > [...] > I couldn't see any bridge-related thing here, and it couldn't be reproduced > with virbr0 (stp=1) on my box (on both s390x and x86_64), I gu

Re: Oops with commit 6d18c73 bridge: start hello_timer when enabling KERNEL_STP in br_stp_start

On Thu, 1 Jun 2017, Xin Long wrote: > On Thu, Jun 1, 2017 at 12:32 AM, Sebastian Ott > wrote: > > [...] > I couldn't see any bridge-related thing here, and it couldn't be reproduced > with virbr0 (stp=1) on my box (on both s390x and x86_64), I guess there > is somethin

Oops with commit 6d18c73 bridge: start hello_timer when enabling KERNEL_STP in br_stp_start

Hi, A system running v4.12-rc3-11-gf511c0b on s390 hangs after boot with no messages on the console. The message buffer obtained via a system dump looked like this: [...] [ 17.870712] virbr0: port 1(virbr0-nic) entered disabled state [ 19.618523] Unable to handle kernel pointer dereference

Oops with commit 6d18c73 bridge: start hello_timer when enabling KERNEL_STP in br_stp_start

Hi, A system running v4.12-rc3-11-gf511c0b on s390 hangs after boot with no messages on the console. The message buffer obtained via a system dump looked like this: [...] [ 17.870712] virbr0: port 1(virbr0-nic) entered disabled state [ 19.618523] Unable to handle kernel pointer dereference

  1   2   3   >