Re: [PATCH] driver core: move uevent call to driver_register

Hi, On Mon, 16 Jul 2012, Greg Kroah-Hartman wrote: On Tue, Jul 17, 2012 at 09:35:02AM +0800, Ming Lei wrote: On Tue, Jul 3, 2012 at 1:08 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: --- a/drivers/base/driver.c +++ b/drivers/base/driver.c @@ -187,6 +187,9 @@ int

Re: [PATCH] driver core: move uevent call to driver_register

Hi, On Tue, 17 Jul 2012, Ming Lei wrote: On Tue, Jul 3, 2012 at 1:08 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: --- a/drivers/base/driver.c +++ b/drivers/base/driver.c @@ -187,6 +187,9 @@ int driver_register(struct device_driver ret = driver_add_groups(drv, drv-groups

Re: [RFC PATCH 01/10] s390/pci: base support

On Thu, 13 Dec 2012, Bjorn Helgaas wrote: On Thu, Dec 13, 2012 at 4:51 AM, Jan Glauber j...@linux.vnet.ibm.com wrote: On Mon, 2012-12-10 at 14:14 -0700, Bjorn Helgaas wrote: On Wed, Nov 14, 2012 at 2:41 AM, Jan Glauber j...@linux.vnet.ibm.com wrote: Add PCI support for s390, (only 64

mm/dmapool.c: possible circular locking dependency detected

); [ 34.736015] [ 34.736015] *** DEADLOCK *** Fix this by moving the pools attribute creation and removal outside the pools_lock (which is used to protect access to the dma_pools list). And add a new lock to serialize the pools attribute creation/removal. Signed-off-by: Sebastian Ott seb

Re: [GIT PULL] ima: bug fixes for Linus

Hello, On Mon, 25 Nov 2013, Roberto Sassu wrote: On 11/25/2013 07:46 PM, Roberto Sassu wrote: On 11/25/2013 04:40 PM, James Morris wrote: On Mon, 25 Nov 2013, Mimi Zohar wrote: Hi James, These are the essential fixes for regressions. The following changes since

Re: [PATCH] ima: store address of template_fmt_copy in a pointer before calling strsep

On Wed, 27 Nov 2013, Roberto Sassu wrote: This patch stores the address of the 'template_fmt_copy' variable in a new variable, called 'template_fmt_ptr', so that the latter is passed as an argument of strsep() instead of the former. This modification is needed in order to correctly free the

Re: [PATCH 7/7] s390/PCI: Use generic pci_enable_resources()

pcibios_add_device() calls pci_claim_resource() on all BARs (except ROM, IOV, and bridge windows) so this isn't a problem either. Signed-off-by: Bjorn Helgaas bhelg...@google.com CC: Martin Schwidefsky schwidef...@de.ibm.com CC: Heiko Carstens heiko.carst...@de.ibm.com CC: Sebastian Ott seb

[PATCH] pci: add pcibios_release_device

() call that architectures can override to do so. Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- drivers/pci/pci.c | 10 ++ drivers/pci/probe.c |1 + include/linux/pci.h |1 + 3 files changed, 12 insertions(+) --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1335,6

Re: hanging aio process

On Mon, 19 May 2014, Benjamin LaHaise wrote: On Mon, May 19, 2014 at 07:38:51PM +0200, Sebastian Ott wrote: Hello, on the latest kernel a fio job with 4 workers using libaio hangs. Is more than one process stuck in state D when the hang occurs? If so, what does a backtrace show

Re: hanging aio process

On Tue, 20 May 2014, Sebastian Ott wrote: On Mon, 19 May 2014, Benjamin LaHaise wrote: It is entirely possible the bug isn't caused by the referenced commit, as the commit you're pointing to merely makes io_destroy() syscall wait for all aio outstanding to complete before returning

Re: hanging aio process

Hi, On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Sebastian Ott wrote: On Mon, 19 May 2014, Benjamin LaHaise wrote: It is entirely possible the bug isn't caused by the referenced commit

Re: hanging aio process

On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Sebastian Ott wrote

Re: hanging aio process

On Wed, 21 May 2014, Sebastian Ott wrote: On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott seb...@linux.vnet.ibm.com

Re: [PATCH 1/1] drivers/s390/cio/qdio_main.c: replace shift loop by ilog2

On Tue, 20 May 2014, Joe Perches wrote: On Tue, 2014-05-20 at 18:37 +0200, Fabian Frederick wrote: This is untested. [] diff --git a/drivers/s390/cio/qdio_main.c b/drivers/s390/cio/qdio_main.c [] @@ -411,15 +411,14 @@ static inline void qdio_stop_polling(struct qdio_q *q) static

Re: hanging aio process

On Wed, 21 May 2014, Anatol Pomozov wrote: On Wed, May 21, 2014 at 1:48 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Wed, 21 May 2014, Sebastian Ott wrote: On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott seb...@linux.vnet.ibm.com

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

...@canb.auug.org.au Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- drivers/pci/pci-sysfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 4e0acef..d6e61ae 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c

hanging aio process

Hello, on the latest kernel a fio job with 4 workers using libaio hangs. git bisect points to: commit e02ba72aabfade4c9cd6e3263e9b57bf890ad25c Author: Anatol Pomozov anatol.pomo...@gmail.com Date: Tue Apr 15 11:31:33 2014 -0700 aio: block io_destroy() until

Re: [PATCH 1/1] drivers/s390/cio/qdio_main.c: replace shift loop by ilog2

Hello Fabian, On Tue, 20 May 2014, Fabian Frederick wrote: This is untested. Cc: Sebastian Ott seb...@linux.vnet.ibm.com Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Fabian Frederick f...@skynet.be --- drivers/s390/cio/qdio_main.c | 5 ++--- 1 file changed, 2 insertions

Re: [PATCH 1/1] drivers/s390/cio/qdio_main.c: replace shift loop by ilog2

On Mon, 2 Jun 2014, Fabian Frederick wrote: On Mon, 2 Jun 2014 16:41:48 +0200 (CEST) Sebastian Ott seb...@linux.vnet.ibm.com wrote: Hello Fabian, On Tue, 20 May 2014, Fabian Frederick wrote: This is untested. Cc: Sebastian Ott seb...@linux.vnet.ibm.com Cc: Andrew Morton

Re: [PATCH 8/10] s390/pci: use safer test on the result of find_first_zero_bit

On Wed, 4 Jun 2014, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may return a larger number than the maximum position argument if that position is not a multiple of BITS_PER_LONG. The semantic match that

[PATCH] percpu-refcount: fix usage of this_cpu_ops (was Re: hanging aio process)

Hello, On Wed, 21 May 2014, Anatol Pomozov wrote: Hi On Wed, May 21, 2014 at 1:48 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Wed, 21 May 2014, Sebastian Ott wrote: On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott seb

Re: [PATCH V2 2/2] drivers/s390/cio/qdio_main.c: replace shift loop by ilog2

On Tue, 3 Jun 2014, Fabian Frederick wrote: account_sbals is called by get_inbound_buffer_frontier and get_outbound_buffer_frontier with 'count' value 0 so we can safely convert shift loop to ilog2. Cc: Sebastian Ott seb...@linux.vnet.ibm.com Cc: Joe Perches j...@perches.com Cc: Andrew

Re: [PATCH] percpu-refcount: fix usage of this_cpu_ops (was Re: hanging aio process)

Hi, On Wed, 4 Jun 2014, Tejun Heo wrote: On Wed, Jun 04, 2014 at 03:58:24PM +0200, Sebastian Ott wrote: From 82295633cad58c7d6b9af4e470e3168ed43a6779 Mon Sep 17 00:00:00 2001 From: Heiko Carstens heiko.carst...@de.ibm.com Date: Wed, 4 Jun 2014 12:53:19 +0200 Subject: [PATCH] percpu

[PATCH] mm/mempool: warn about __GFP_ZERO usage

called with __GFP_ZERO. Add a note and VM_BUG_ON statement to make that clear. Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- mm/mempool.c |2 ++ 1 file changed, 2 insertions(+) --- a/mm/mempool.c +++ b/mm/mempool.c @@ -192,6 +192,7 @@ EXPORT_SYMBOL(mempool_resize); * returns

Re: [PATCH] s390: fix new ccwgroup.h kernel-doc warning

On Mon, 14 Apr 2014, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix new s390 kernel-doc warning: Warning(arch/s390/include/asm/ccwgroup.h:27): No description found for parameter 'ungroup_work' Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Sebastian Ott seb

[PATCH] misc/GenWQE: fix pci_enable_msi usage

pci_enable_msi_exact() instead of pci_enable_msi_block() pci_enable_msi_exact is used which fails if the desired number of MSI's was not possible to allocate. Change GenWQE to use pci_enable_msi_range to restore the old behavior. Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- drivers/misc/genwqe

Re: [PATCH] misc/GenWQE: fix pci_enable_msi usage

On Wed, 9 Jul 2014, Alexander Gordeev wrote: On Wed, Jul 09, 2014 at 12:46:39PM +0200, Sebastian Ott wrote: GenWQE used to call pci_enable_msi_block to allocate a desired number of MSI's. If that was not possible pci_enable_msi_block returned with a smaller number which might be possible

Re: [PATCH] misc/GenWQE: fix pci_enable_msi usage

On Thu, 17 Jul 2014, Frank Haverkamp wrote: Hi Bjorn and Sebastian, Am Mittwoch, den 16.07.2014, 15:10 -0600 schrieb Bjorn Helgaas: [+cc linux-pci] On Wed, Jul 09, 2014 at 12:46:39PM +0200, Sebastian Ott wrote: GenWQE used to call pci_enable_msi_block to allocate a desired number

Re: [PATCH v3 22/27] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq

On Wed, 15 Oct 2014, Yijing Wang wrote: Use MSI chip framework instead of arch MSI functions to configure MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. Signed-off-by: Yijing Wang wangyij...@huawei.com --- Hi Sebastian, I dropped the Acked-by , because this

Re: [PATCH 1/1] s390/pci: Deletion of unnecessary checks before the function call debug_unregister

On Sat, 22 Nov 2014, SF Markus Elfring wrote: From: Markus Elfring elfr...@users.sourceforge.net Date: Sat, 22 Nov 2014 15:00:55 +0100 The debug_unregister() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using

Re: [PATCH percpu/for-3.18-fixes] s390: fix machine check regression caused by the conversion from __get_cpu_var() to this_cpu_ptr()

On Tue, 2 Dec 2014, Tejun Heo wrote: Sorry about the delay. Was on vacation. Patch applied to percpu/for-3.18-fixes w/ minor updates to the patch subject and description. Will push out to Linus soon. I've seen that Martin took the patch and it's already in Linus' tree - commit

Re: [PATCH RFC 2/5] s390: add pci_iomap_range

On Mon, 15 Dec 2014, Michael S. Tsirkin wrote: From: Michael S Tsirkin m...@redhat.com Virtio drivers should map the part of the range they need, not necessarily all of it. To this end, support mapping ranges within BAR on s390. Since multiple ranges can now be mapped within a BAR, we keep

Re: [PATCH RFC 2/5] s390: add pci_iomap_range

On Fri, 19 Dec 2014, Michael S. Tsirkin wrote: On Fri, Dec 19, 2014 at 03:13:37PM +0100, Sebastian Ott wrote: On Mon, 15 Dec 2014, Michael S. Tsirkin wrote: From: Michael S Tsirkin m...@redhat.com Virtio drivers should map the part of the range they need, not necessarily all

PATCH] s390: fix machine check handling

Hi, would it be possible to have this one for 3.18 (if not, please add Cc: sta...@vger.kernel.org # v3.18) Regards, Sebastian 8- From ca198a6ff5766f19645104b7f8d621774524c4b4 Mon Sep 17 00:00:00 2001 From: Sebastian Ott seb...@linux.vnet.ibm.com Date: Fri, 28 Nov 2014 15:40:57 +0100

Re: [PATCH v3 10/16] s390: add pci_iomap_range

, and only clear out the mapping for a BAR when this number reaches 0. Cc: Bjorn Helgaas bhelg...@google.com Cc: linux-...@vger.kernel.org Tested-by: Sebastian Ott seb...@linux.vnet.ibm.com Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Heiko, Martin, can you please ack merging

[PATCH] infiniband/mlx4: check for mapping error

Since ib_dma_map_single can fail use ib_dma_mapping_error to check for errors. Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- drivers/infiniband/hw/mlx4/mad.c |9 + drivers/infiniband/hw/mlx4/qp.c |4 2 files changed, 13 insertions(+) --- a/drivers/infiniband

Re: [PATCH] lib/dma-debug: fix bucket_find_contain

On Thu, 19 Mar 2015, Andrew Morton wrote: On Mon, 16 Mar 2015 19:24:29 +0100 (CET) Sebastian Ott seb...@linux.vnet.ibm.com wrote: bucket_find_contain will search the bucket list for a dma_debug_entry. When the entry isn't found it needs to search other buckets too, since only the start

[PATCH] lib/dma-debug: fix bucket_find_contain

bucket but when its list is searched the original dma_debug_entry is to be used not its modified copy. This fixes false device driver tries to sync DMA memory it has not allocated warnings. Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- lib/dma-debug.c |2 +- 1 file changed, 1

Re: [PATCH 19/27] s390: Remove use of seq_printf return value

On Sat, 21 Feb 2015, Joe Perches wrote: The seq_printf return value, because it's frequently misused, will eventually be converted to void. See: commit 1f33c41c03da (seq_file: Rename seq_overflow() to seq_has_overflowed() and make public) Acked-By: Sebastian Ott seb

Re: [PATCH v1 7/7] s390/block/dasd: remove obsolete while -EBUSY loop

...@kernel.org CC: Alexander Viro v...@zeniv.linux.org.uk CC: Markus Pargmann m...@pengutronix.de CC: Stefan Weinhuber w...@de.ibm.com CC: Stefan Haberland stefan.haberl...@de.ibm.com CC: Sebastian Ott seb...@linux.vnet.ibm.com CC: Fabian Frederick f...@skynet.be CC: Ming Lei ming

[PATCH] input/arc_ps2: add HAS_IOMEM dependency

Fix this compile error: drivers/built-in.o: In function `arc_ps2_probe': /mnt/linux/drivers/input/serio/arc_ps2.c:206: undefined reference to `devm_ioremap_resource' Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- drivers/input/serio/Kconfig |1 + 1 file changed, 1 insertion

[PATCH] phy/pxa: add HAS_IOMEM dependency

' Signed-off-by: Sebastian Ott seb...@linux.vnet.ibm.com --- drivers/phy/Kconfig |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -56,6 +56,7 @@ config PHY_EXYNOS_MIPI_VIDEO config PHY_PXA_28NM_HSIC tristate Marvell USB HSIC 28nm PHY

Re: mlx4: failed to allocate default counter port 1

On Tue, 30 Jun 2015, Or Gerlitz wrote: On Tue, Jun 30, 2015 at 1:45 PM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: after the latest mellanox update the mlx4 driver fails to probe a VF: [ 88.909562] mlx4_core :00:00.0: mlx4_allocate_default_counters: failed to allocate default

mlx4: failed to allocate default counter port 1

Hello, after the latest mellanox update the mlx4 driver fails to probe a VF: [ 88.909562] mlx4_core :00:00.0: mlx4_allocate_default_counters: failed to allocate default counter port 1 err -22 [ 88.909564] mlx4_core :00:00.0: Failed to allocate default counters, aborting [

Re: [PATCH 16/31] s390: handle page-less SG entries

On Wed, 12 Aug 2015, Christoph Hellwig wrote: Use sg_phys() instead of page_to_phys(sg_page(sg)) so that we don't require a page structure for all DMA memory. Signed-off-by: Christoph Hellwig h...@lst.de Acked-by: Sebastian Ott seb...@linux.vnet.ibm.com --- arch/s390/pci/pci_dma.c | 20

Re: [RFC Patch V1 04/12] s390/pci: Use for_pci_msi_entry() to access MSI device list

On Thu, 9 Jul 2015, Jiang Liu wrote: Use accessor for_pci_msi_entry() to access MSI device list, so we could easily move msi_list from struct pci_dev into struct device later. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Sebastian Ott seb...@linux.vnet.ibm.com Regards

[PATCH] iommu/s390: fix sparse warnings

-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- drivers/iommu/s390-iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c index cbe198c..030e94c 100644 --- a/drivers/iommu/s390-iommu.c +++ b/drivers/iommu/s390-iommu.c @@

Re: [PATCH] security: device_cgroup: fix RCU lockdep splat

On Mon, 31 Aug 2015, Felipe Balbi wrote: > while booting AM437x device, the following splat > triggered: > > [ 12.005238] === > [ 12.009749] [ INFO: suspicious RCU usage. ] > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted > [ 12.019050]

[PATCH] misc/genwqe: get rid of atomic allocations

s atomic. Regards, Sebastian >8 misc/genwqe: get rid of atomic allocations All of genwqe's atomic allocations happen in a context where it's allowed to sleep. Change these to use GFP_KERNEL. Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- drivers/misc/genwqe/card_ddcb.c |

[PATCH] lib/iommu-helper: skip to next segment

the start of the next segment (which is the next bit position such that we'll not cross the same segment boundary again). Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> Reviewed-by: Gerald Schaefer <gerald.schae...@de.ibm.com> --- lib/iommu-helper.c | 3 +-- 1 file changed,

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Fri, 12 Feb 2016, Will Deacon wrote: > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote: > > On Thu, 11 Feb 2016 21:09:42 +0200 > > "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gera

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 11 Feb 2016, Kirill A. Shutemov wrote: > On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote: > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote: > > > Hi, > > > > > > Sebastian Ott reported random kernel crashes begin

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Sat, 13 Feb 2016, Kirill A. Shutemov wrote: > Could you check if revert of fecffad25458 helps? I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with: ¢ 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space ¢ 1851.721075! failing address:

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Wed, 24 Feb 2016, Martin Schwidefsky wrote: > On Tue, 23 Feb 2016 22:33:45 +0300 > "Kirill A. Shutemov" wrote: > > > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote: > > > I'll check with Martin, maybe it is actually trivial, then we can > > > do a quick

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

Hi, On Wed, 17 Feb 2016, Kirill A. Shutemov wrote: > On Tue, Feb 16, 2016 at 05:24:44PM +0100, Gerald Schaefer wrote: > > On Mon, 15 Feb 2016 23:35:26 +0200 > > "Kirill A. Shutemov" wrote: > > > > > Is there any chance that I'll be able to trigger the bug using QEMU? > > >

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 18 Feb 2016, Kirill A. Shutemov wrote: > I worth minimizing kernel config on which you can see the bug. Things like > CONFIG_DEBUG_PAGEALLOC used to interfere with THP before. I disabled all debugging options (using arch/s390/configs/performance_defconfig) - we still chrashed. Sebastian

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016, Kirill A. Shutemov wrote: > > [ 59.851421] list_del corruption. next->prev should be 6e1eb000, > > but was 0400 > > This kinda interesting: 0x400 is TAIL_MAPPING.. Hm.. > > Could you check if you see the problem on commit 1c290f642101 and its >

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016, Kirill A. Shutemov wrote: > Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97 > crashes. Correct? Correct.

Re: [PATCH 3.16 098/217] s390/pci: enforce fmb page boundary rule

On Wed, 27 Apr 2016, Ben Hutchings wrote: > 3.16.35-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Sebastian Ott <seb...@linux.vnet.ibm.com> > > commit 80c544ded25ac14d7cc3e555abb8ed2c2da99b84 upstream. > &g

Re: [PATCH] s390/pci: Remove unnecessary if condition

On Fri, 29 Jul 2016, Julia Lawall wrote: > On Fri, 29 Jul 2016, Sebastian Ott wrote: > > On Fri, 29 Jul 2016, Amitoj Kaur Chawla wrote: > > > Remove unnecessary error handling because the only failure value that > > > can be returned is NULL and so

Re: [PATCH] s390/pci: Remove unnecessary if condition

On Fri, 29 Jul 2016, Amitoj Kaur Chawla wrote: > Remove unnecessary error handling because the only failure value that > can be returned is NULL and so the test can never be true. > > The Coccinelle semantic patch used to make this change is as follows: > @@ > expression e; > @@ > > e =

Re: [PATCH] s390/cio/chp : Remove deprecated create_singlethread_workqueue

On Sat, 16 Jul 2016, Bhaktipriya Shridhar wrote: > The workqueue "chp_wq" is involved in performing pending > configure tasks for channel paths. > > It has a single work item(_work) and hence doesn't require > ordering. Also, it is not being used on a memory reclaim path. > Hence, the

IB on s390 broken with commit 99db94940 "IB/core: Remove ib_device.dma_device"

Hi, commit 99db94940 "IB/core: Remove ib_device.dma_device" breaks infiniband on s390 (and I think also other archs that do something like to_pci_dev(dev) in one of their dma_ops callbacks). With this commit you use the dma_ops of the device that called ib_register_device but you call e.g.

Re: IB on s390 broken with commit 99db94940 "IB/core: Remove ib_device.dma_device"

On Mon, 27 Feb 2017, Bart Van Assche wrote: > On Mon, 2017-02-27 at 21:17 +0100, Sebastian Ott wrote: > > commit 99db94940 "IB/core: Remove ib_device.dma_device" > > breaks infiniband on s390 (and I think also other archs that do something > > like to_pci_d

Re: IB on s390 broken with commit 99db94940 "IB/core: Remove ib_device.dma_device"

On Tue, 28 Feb 2017, Sebastian Ott wrote: > On Mon, 27 Feb 2017, Bart Van Assche wrote: > > On Mon, 2017-02-27 at 21:17 +0100, Sebastian Ott wrote: > > > commit 99db94940 "IB/core: Remove ib_device.dma_device" > > > breaks infiniband on s390 (and I thi

[PATCH] mm, add_memory_resource: hold device_hotplug lock over mem_hotplug_{begin, done}

d to a warning when add_memory() is called. Fix this by acquiring device_hotplug_lock in add_memory_resource(). Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- mm/memory_hotplug.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c i

Re: [PATCH] net/mlx4_en: fix off by one in error handling

Hello Tariq, On Wed, 14 Sep 2016, Tariq Toukan wrote: > On 14/09/2016 2:09 PM, Sebastian Ott wrote: > > If an error occurs in mlx4_init_eq_table the index used in the > > err_out_unmap label is one too big which results in a panic in > > mlx4_free_eq. This patch fixes the in

[PATCH] net/mlx4_en: fix off by one in error handling

If an error occurs in mlx4_init_eq_table the index used in the err_out_unmap label is one too big which results in a panic in mlx4_free_eq. This patch fixes the index in the error path. Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- drivers/net/ethernet/mellanox/mlx4/eq

Re: [PATCH] net/mlx4_en: fix off by one in error handling

On Wed, 14 Sep 2016, Tariq Toukan wrote: > On 14/09/2016 4:53 PM, Sebastian Ott wrote: > > On Wed, 14 Sep 2016, Tariq Toukan wrote: > > > On 14/09/2016 2:09 PM, Sebastian Ott wrote: > > > > If an error occurs in mlx4_init_eq_table the index used in the > > &g

[PATCH] misc/genwqe: ensure zero initialization

guaranteed. Simply switch to dma_zalloc_coherent. Signed-off-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- drivers/misc/genwqe/card_ddcb.c | 2 -- drivers/misc/genwqe/card_utils.c | 4 ++-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/misc/genwqe/card_ddcb.c b/driver

Re: [PATCH] misc/genwqe: ensure zero initialization

On Thu, 22 Sep 2016, Frank Haverkamp wrote: > > On 12.09.2016, at 20:09, Sebastian Ott <seb...@linux.vnet.ibm.com> wrote: > > Genwqe uses dma_alloc_coherent and depends on zero initialized memory. On > > one occasion it ueses an explicit memset on others it uses u

Re: [PATCH 25/28] s390: pci: don't print uninitialized data for debugging

gt; + unsigned long pa = 0; > > int ret; > > > > size = PAGE_ALIGN(size); > > The compiler is right. pa is set in the for-loop. If "dma_addr < > dma_addr_base + size" > is never true and __dma_purge_tlb() returns with an error, pa *is* > uninitialized. > The fix seems sensible to me. Although that could only happen if map_sg is called with zero length sg list entries I'm in favor getting rid of that warning. Acked-by: Sebastian Ott <seb...@linux.vnet.ibm.com> Regards, Sebastian

mlx4: panic during shutdown

Hi, After a userspace update (fedora 23->24) I reproducibly run into the following oops during shutdown (on s390): [ 71.054832] Unable to handle kernel pointer dereference in virtual kernel address space [ 71.054835] Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 [ 71.054838]

mlx5: ifup failure due to huge allocation

Hi, Ifup on an interface provided by CX4 (MLX5 driver) on s390 fails with: [ 22.318553] [ cut here ] [ 22.318564] WARNING: CPU: 1 PID: 399 at mm/page_alloc.c:3421 __alloc_pages_nodemask+0x2ee/0x1298 [ 22.318568] Modules linked in: mlx4_ib ib_core mlx5_core mlx4_en

[PATCH resend] IB/core: fix unmap_sg argument

_common.isra.15+0x572/0x1010 [mlx4_ib] [ 20.781949] [<03ff8013929e>] mlx4_ib_create_qp+0x1de/0x438 [mlx4_ib] [ 20.781953] [<03ff8004f52c>] create_qp.isra.11+0x44c/0x7f0 [ib_uverbs] The following patch fixes this: >8 >From ec91646d8c14e2a8dd2b62187084dab32ef8a56b

mlx5: net_device.addr_list_lock usage before initialization

Hi, I ran into the following lockdep complaint: [7.059561] INFO: trying to register non-static key. [7.059566] the code is fine but needs lockdep annotation. [7.059570] turning off the locking correctness validator. [7.059579] CPU: 6 PID: 6 Comm: kworker/u32:0 Not tainted

[PATCH] IB/core: fix unmap_sg argument

_common.isra.15+0x572/0x1010 [mlx4_ib] [ 20.781949] [<03ff8013929e>] mlx4_ib_create_qp+0x1de/0x438 [mlx4_ib] [ 20.781953] [<03ff8004f52c>] create_qp.isra.11+0x44c/0x7f0 [ib_uverbs] The following patch fixes this: >8 >From ec91646d8c14e2a8dd2b62187084dab32ef8a56b

Re: lockdep warning: console vs. mem hotplug

On Fri, 24 Mar 2017, Steven Rostedt wrote: > Is there a stack trace of where the lockdep dump happened? That is > useful too. Otherwise we don't see where the inverse happened. Sure. Here you go. [ 132.379220] == [ 132.379220] [ INFO:

Re: lockdep warning: console vs. mem hotplug

On Sat, 25 Mar 2017, Sergey Senozhatsky wrote: > On (03/21/17 13:44), Sergey Senozhatsky wrote: > [..] > > so we probably can > > > > > > 1) move pr_info() out of zone->lock in __offline_isolated_pages(). > >meh... > > > > > > 2) switch to printk_deferred() in __offline_isolated_pages().

lockdep warning: console vs. mem hotplug

Since commit f975237b7682 ("printk: use printk_safe buffers in printk") I observe lockdep warnings on s390 when doing memory hotplug: [ 132.379220] == [ 132.379220] [ INFO: possible circular locking dependency detected ] [ 132.379221]

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 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: > * 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

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: 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: &

[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

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

On Fri, 28 Apr 2017, Joerg Roedel wrote: > On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > > On Thu, 27 Apr 2017 23:03:25 +0200 > > Joerg Roedel wrote: > > > > > > Well, there is a separate zpci_dev for each pci_dev on s390, > > > > and each of those has its

Re: [PATCH] s390: provide default ioremap and iounmap declaration

Hi, On Fri, 26 May 2017, Logan Gunthorpe wrote: > On 26/05/17 06:38 AM, Heiko Carstens wrote: > > On Thu, May 25, 2017 at 09:43:48AM -0600, Logan Gunthorpe wrote: > > I'd rather move the #ifdef CONFIG_PCI than implementing this yet another > > time (see patch below). But I'll leave that up to

Re: [PATCH v2] s390: provide default ioremap and iounmap declaration

e they'd likely > never be called without CONFIG_PCI set, but this is needed to compile > such changes. > > Signed-off-by: Logan Gunthorpe <log...@deltatee.com> > Cc: Martin Schwidefsky <schwidef...@de.ibm.com> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> >

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

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: 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: 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 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: [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 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: [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

[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

  1   2   3   >