Re: [PATCH] s390: dasd: Mundane spelling fixes

Am 22.03.21 um 03:39 schrieb Bhaskar Chowdhury: > s/Subssystem/Subsystem/ ..two different places > s/reportet/reported/ > s/managemnet/management/ > > Signed-off-by: Bhaskar Chowdhury > --- > drivers/s390/block/dasd_eckd.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-)

Re: [PATCH v4 2/2] s390/dasd: remove ioctl_by_bdev calls

Am 07.10.20 um 12:44 schrieb Christian Borntraeger: > > On 07.10.20 12:39, Christoph Hellwig wrote: >> On Wed, Oct 07, 2020 at 11:34:17AM +0200, Christian Borntraeger wrote: >>> On 19.05.20 16:22, Stefan Haberland wrote: >>>> The IBM partition parser requires devi

Re: [PATCH 08/14] dasd: cleanup dasd_scan_partitions

Am 21.09.20 um 09:19 schrieb Christoph Hellwig: > Use blkdev_get_by_dev instead of bdget_disk + blkdev_get. > > Signed-off-by: Christoph Hellwig Beside what Sergei mentioned... Reviewed-by: Stefan Haberland > --- > drivers/s390/block/dasd_genhd.c | 15 --- >

Re: [PATCH] dasd: remove the unused dasd_enable_device export

Am 03.09.20 um 10:30 schrieb Christoph Hellwig: > Signed-off-by: Christoph Hellwig Acked-by:Stefan Haberland > --- > drivers/s390/block/dasd.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c > index eb17fea8075c6f..6ab992b3eed004

Re: [PATCH][next] s390/dasd: Use struct_size() helper

Am 19.06.20 um 18:56 schrieb Gustavo A. R. Silva: > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mistakes. Also, remove unnecessary > variable _datasize_. > > This code was detected with the help of Coccinelle and, audited and > fixed

[PATCH v4 0/2] s390/dasd: remove ioctl_by_bdev from DASD driver

ome comments and some cleanup Christoph Hellwig (1): dasd: refactor dasd_ioctl_information Stefan Haberland (1): s390/dasd: remove ioctl_by_bdev calls MAINTAINERS | 1 + block/partitions/ibm.c | 24 --- drivers/s390/block/dasd_ioctl.c |

[PATCH v4 1/2] dasd: refactor dasd_ioctl_information

From: Christoph Hellwig Prepare for in-kernel callers of this functionality. Signed-off-by: Christoph Hellwig [s...@de.ibm.com: remove leftover kfree] Signed-off-by: Stefan Haberland Reviewed-by: Peter Oberparleiter Reviewed-by: Jan Hoeppner --- drivers/s390/block/dasd_ioctl.c | 42

[PATCH v4 2/2] s390/dasd: remove ioctl_by_bdev calls

. Suggested-by: Christoph Hellwig Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner Reviewed-by: Peter Oberparleiter --- MAINTAINERS | 1 + block/partitions/ibm.c | 24 +-- drivers/s390/block/dasd_ioctl.c | 34

Re: [PATCH v3 3/3] s390/dasd: remove ioctl_by_bdev calls

Am 16.05.20 um 17:43 schrieb Christoph Hellwig: > On Mon, May 11, 2020 at 06:30:44PM +0200, Stefan Haberland wrote: >> Am 08.05.20 um 17:53 schrieb Christoph Hellwig: >>> I think this should use symbol_get instead. >> Thanks for the Feedback, also for the previous patc

Re: [PATCH v3 3/3] s390/dasd: remove ioctl_by_bdev calls

Am 08.05.20 um 17:53 schrieb Christoph Hellwig: > I think this should use symbol_get instead. Thanks for the Feedback, also for the previous patch. I will incorporate it, run some test cycles and submit the patches again when I am ready.

[PATCH v3 2/3] block: add a s390-only biodasdinfo method

...@linux.ibm.com: remove fop, add gendisk check, export funcion] Signed-off-by: Stefan Haberland --- drivers/s390/block/dasd_int.h | 1 + drivers/s390/block/dasd_ioctl.c | 21 + include/linux/blkdev.h | 1 + 3 files changed, 23 insertions(+) diff --git a/drivers/s390/block

[PATCH v3 3/3] s390/dasd: remove ioctl_by_bdev calls

Call getgeo method directly and obtain pointer to dasd_biodasdinfo function and use this instead of ioctl. Suggested-by: Christoph Hellwig Signed-off-by: Stefan Haberland --- block/partitions/ibm.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/block

[PATCH v3 1/3] dasd: refactor dasd_ioctl_information

From: Christoph Hellwig Prepare for in-kernel callers of this functionality. Signed-off-by: Christoph Hellwig Signed-off-by: Stefan Haberland --- drivers/s390/block/dasd_ioctl.c | 38 +++-- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers

[PATCH v3 0/3] s390/dasd: remove ioctl_by_bdev from DASD driver

: add a s390-only biodasdinfo method Stefan Haberland (1): s390/dasd: remove ioctl_by_bdev calls block/partitions/ibm.c | 15 +++-- drivers/s390/block/dasd_int.h | 1 + drivers/s390/block/dasd_ioctl.c | 59 - include/linux/blkdev.h | 1 + 4

Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

Am 07.05.20 um 17:29 schrieb Christoph Hellwig: > On Thu, May 07, 2020 at 05:22:28PM +0200, Stefan Haberland wrote: >> OK, just thought again about your suggestion and also that >> you have already been talking about a symbol lookup I just >> have written a prototype tha

Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

Am 06.05.20 um 06:52 schrieb Christoph Hellwig: > > No, I mean the series that I actually sent out: > > https://lkml.org/lkml/2020/4/21/66 > https://lkml.org/lkml/2020/4/21/68 > https://lkml.org/lkml/2020/4/21/69 OK, just thought again about your suggestion and also that you have already been

Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

Am 05.05.20 um 14:44 schrieb Christoph Hellwig: > On Mon, May 04, 2020 at 10:45:33AM +0200, Stefan Haberland wrote: >>> findthe corresponding device for example. Not sure if this is that easy. >> I did some additional research on this. >> What I could imagine: >>

Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

Am 30.04.20 um 16:02 schrieb Stefan Haberland: > Am 30.04.20 um 15:13 schrieb Christoph Hellwig: >> On Thu, Apr 30, 2020 at 01:17:54PM +0200, Stefan Haberland wrote: >>> Remove the calls to ioctl_by_bdev from the DASD partition detection code >>> to enable the r

Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

Am 30.04.20 um 15:13 schrieb Christoph Hellwig: > On Thu, Apr 30, 2020 at 01:17:54PM +0200, Stefan Haberland wrote: >> Remove the calls to ioctl_by_bdev from the DASD partition detection code >> to enable the removal of the specific code. >> >> To do so reuse the g

[PATCH 0/1] remove ioclt_by_bdev from DASD

for suggestions. Regards, Stefan Stefan Haberland (1): s390/dasd: remove ioctl_by_bdev from DASD driver block/partitions/ibm.c | 67 ++-- drivers/s390/block/dasd_devmap.c | 17 +++- drivers/s390/block/dasd_diag.c | 10 + drivers/s390/block/dasd_eckd.c | 10

[PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver

information for the partition detection. This makes it independent from the dasd_information2_t structure. Suggested-by: Christoph Hellwig Signed-off-by: Stefan Haberland Reviewed-by: Jan Hoeppner --- block/partitions/ibm.c | 67 ++-- drivers/s390/block

Re: memory leaks in dasd_eckd_check_characteristics() error paths

On 16.10.19 17:28, Stefan Haberland wrote: > On 16.10.19 17:26, Qian Cai wrote: >> On Wed, 2019-10-16 at 16:56 +0200, Stefan Haberland wrote: >>> On 16.10.19 16:09, Qian Cai wrote: >>>> On Wed, 2019-10-16 at 15:29 +0200, Stefan Haberland wrote: >>>

Re: memory leaks in dasd_eckd_check_characteristics() error paths

On 16.10.19 17:26, Qian Cai wrote: > On Wed, 2019-10-16 at 16:56 +0200, Stefan Haberland wrote: >> On 16.10.19 16:09, Qian Cai wrote: >>> On Wed, 2019-10-16 at 15:29 +0200, Stefan Haberland wrote: >>>> Hi, >>>> >>>> thanks for repor

Re: memory leaks in dasd_eckd_check_characteristics() error paths

On 16.10.19 16:09, Qian Cai wrote: > On Wed, 2019-10-16 at 15:29 +0200, Stefan Haberland wrote: >> Hi, >> >> thanks for reporting this. >> >> On 02.10.19 21:33, Qian Cai wrote: >>> For some reasons, dasd_eckd_check_characteristics() received -ENOMEM

Re: memory leaks in dasd_eckd_check_characteristics() error paths

Hi, thanks for reporting this. On 02.10.19 21:33, Qian Cai wrote: > For some reasons, dasd_eckd_check_characteristics() received -ENOMEM and then > dasd_generic_set_online() emits this message, > > dasd: 0.0.0122 Setting the DASD online with discipline ECKD failed with rc=-12 > > After that,

Re: 4.16-RC7 WARNING: CPU: 2 PID: 0 at block/blk-mq.c:1400 __blk_mq_delay_run_hw_queue

f the hctx is mapped in blk_mq_run_hw_queues(). Reported-by: Stefan Haberland <s...@linux.vnet.ibm.com> Cc: Christoph Hellwig <h...@lst.de> Fixes: 20e4d813931961fe ("blk-mq: simplify queue mapping & schedule with each possisble CPU") Signed-off-by: Ming Lei <ming@redha

Re: 4.16-RC7 WARNING: CPU: 2 PID: 0 at block/blk-mq.c:1400 __blk_mq_delay_run_hw_queue

_run_hw_queues(). Reported-by: Stefan Haberland Cc: Christoph Hellwig Fixes: 20e4d813931961fe ("blk-mq: simplify queue mapping & schedule with each possisble CPU") Signed-off-by: Ming Lei --- Hi Ming, thanks a lot for the patch. I tried it on top of our 4.16-rc7 branch and

4.16-RC7 WARNING: CPU: 2 PID: 0 at block/blk-mq.c:1400 __blk_mq_delay_run_hw_queue

Hi, I get the following warning in __blk_mq_delay_run_hw_queue when the scheduler is set to mq-deadline for DASD devices on s390. What I see is that for whatever reason there is a hctx nr 0 which has no hctx->tags pointer set. From my observation it is always hctx nr 0 which has a tags NULL

4.16-RC7 WARNING: CPU: 2 PID: 0 at block/blk-mq.c:1400 __blk_mq_delay_run_hw_queue

Hi, I get the following warning in __blk_mq_delay_run_hw_queue when the scheduler is set to mq-deadline for DASD devices on s390. What I see is that for whatever reason there is a hctx nr 0 which has no hctx->tags pointer set. From my observation it is always hctx nr 0 which has a tags NULL

Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

Ming or Christoph, would you mind to send this patch to stable #4.12? Or is the fixes tag enough to get this fixed in all related releases? Regards, Stefan

Re: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU

Ming or Christoph, would you mind to send this patch to stable #4.12? Or is the fixes tag enough to get this fixed in all related releases? Regards, Stefan

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 11.01.2018 12:44, Christian Borntraeger wrote: On 01/11/2018 10:13 AM, Ming Lei wrote: On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: On 12/18/2017 02:56 PM, Stefan Haberland wrote: On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 11.01.2018 12:44, Christian Borntraeger wrote: On 01/11/2018 10:13 AM, Ming Lei wrote: On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: On 12/18/2017 02:56 PM, Stefan Haberland wrote: On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 11.01.2018 10:13, Ming Lei wrote: On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: On 12/18/2017 02:56 PM, Stefan Haberland wrote: On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote: t > com

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

On 11.01.2018 10:13, Ming Lei wrote: On Wed, Dec 20, 2017 at 04:47:21PM +0100, Christian Borntraeger wrote: On 12/18/2017 02:56 PM, Stefan Haberland wrote: On 07.12.2017 00:29, Christoph Hellwig wrote: On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote: t > com

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

commit 9c6ae239e01ae9a9f8657f05c55c4372e9fc8bcc-> good genirq/affinity: assign vectors to all possible CPUs does boot with DASD disks. Also adding Stefan Haberland if he has an idea why this fails on DASD and adding Martin (for the s390 irq handling code). That is interesting as it really isn't related to interrup

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

commit 9c6ae239e01ae9a9f8657f05c55c4372e9fc8bcc-> good genirq/affinity: assign vectors to all possible CPUs does boot with DASD disks. Also adding Stefan Haberland if he has an idea why this fails on DASD and adding Martin (for the s390 irq handling code). That is interesting as it really isn't related to interrup

Re: [PATCH] s390/dasd: Simplify code

On 09.12.2017 07:29, Christophe JAILLET wrote: Use 'seq_printf(m, "...%*phN...")' instead of duplicating its implementation. Signed-off-by: Christophe JAILLET Thanks for the patch. Applied.

Re: [PATCH] s390/dasd: Simplify code

On 09.12.2017 07:29, Christophe JAILLET wrote: Use 'seq_printf(m, "...%*phN...")' instead of duplicating its implementation. Signed-off-by: Christophe JAILLET Thanks for the patch. Applied.

Re: [PATCH] s390/dasd: remove 'struct timespec' usage

On 27.11.2017 12:46, Arnd Bergmann wrote: getnstimeofday() and timespec are deprecated since they can overflow on 32-bit architectures. This simply changes to the explicitly typed timespec64 version that doesn't have that problem. It would be nice to also convert to monotonic timestamps and

Re: [PATCH] s390/dasd: remove 'struct timespec' usage

On 27.11.2017 12:46, Arnd Bergmann wrote: getnstimeofday() and timespec are deprecated since they can overflow on 32-bit architectures. This simply changes to the explicitly typed timespec64 version that doesn't have that problem. It would be nice to also convert to monotonic timestamps and

Re: [PATCH] s390/dasd: avoid calling do_gettimeofday()

On 06.11.2017 15:02, Arnd Bergmann wrote: do_gettimeofday() is deprecated because it's not y2038-safe on 32-bit architectures. Since it is basically a wrapper around ktime_get_real_ts64(), we can just call that function directly instead. Signed-off-by: Arnd Bergmann ---

Re: [PATCH] s390/dasd: avoid calling do_gettimeofday()

On 06.11.2017 15:02, Arnd Bergmann wrote: do_gettimeofday() is deprecated because it's not y2038-safe on 32-bit architectures. Since it is basically a wrapper around ktime_get_real_ts64(), we can just call that function directly instead. Signed-off-by: Arnd Bergmann ---

blk-mq timeout question

While changing the DASD device driver to use the blk-mq interfaces I found the following unexpected behavior: In case of a timeout our complete callback is never called. Here is the sequence of events as I understood: - timeout occurs - blk_mq_check_expired() calls and checks

blk-mq timeout question

While changing the DASD device driver to use the blk-mq interfaces I found the following unexpected behavior: In case of a timeout our complete callback is never called. Here is the sequence of events as I understood: - timeout occurs - blk_mq_check_expired() calls and checks

[v2] block: check partition alignment

In a worst case scenario this might destroy data on the device. To prevent partitions that are not aligned to the physical blocksize of a device check for the alignment in the blkpg_ioctl. Signed-off-by: Stefan Haberland <s...@linux.vnet.ibm.com> --- block/ioctl.c | 3 +++ 1 file changed, 3 ins

Re: [RFC] block: check partition alignment

y aligned accesses make sense > for DASD. > We already do it this way. So the logical blocksize is fine for DASD. I just was not aware of the fact that the physical blocksize is a best_can_do field. So I changed it this way and also incorporated your other feedback regarding the modulo. Here is

Re: [RFC] block: check partition alignment

y aligned accesses make sense > for DASD. > We already do it this way. So the logical blocksize is fine for DASD. I just was not aware of the fact that the physical blocksize is a best_can_do field. So I changed it this way and also incorporated your other feedback regarding the modulo. Here is

[v2] block: check partition alignment

In a worst case scenario this might destroy data on the device. To prevent partitions that are not aligned to the physical blocksize of a device check for the alignment in the blkpg_ioctl. Signed-off-by: Stefan Haberland --- block/ioctl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/block

[RFC] block: check partition alignment

In a worst case scenario this might destroy data on the device. To prevent partitions that are not aligned to the physical blocksize of a device check for the alignment in the blkpg_ioctl. Signed-off-by: Stefan Haberland <s...@linux.vnet.ibm.com> --- block/ioctl.c | 3 +++ 1 file changed, 3 ins

[RFC] block: check partition alignment

In a worst case scenario this might destroy data on the device. To prevent partitions that are not aligned to the physical blocksize of a device check for the alignment in the blkpg_ioctl. Signed-off-by: Stefan Haberland --- block/ioctl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/block

Re: [PATCH v1] block: fix bio splitting on max sectors

when the block size is bigger than 512. This patch fixes the issue by making the max io size aligned to logical block size. Fixes: e36f62042880(block: split bios to maxpossible length) Reported-by: Stefan Haberland Cc: Keith Busch Suggested-by: Linus Torvalds Signed-off-by: Ming Lei --- V1

Re: [PATCH v1] block: fix bio splitting on max sectors

when the block size is bigger than 512. This patch fixes the issue by making the max io size aligned to logical block size. Fixes: e36f62042880(block: split bios to maxpossible length) Reported-by: Stefan Haberland <s...@linux.vnet.ibm.com> Cc: Keith Busch <keith.bu...@intel.com&g

[BUG] Regression introduced with "block: split bios to max possible length"

Hi, unfortunately commit e36f62042880 "block: split bios to maxpossible length" breaks the DASD driver on s390. We expect the block requests to be multiple of 4k in size. With the patch applied I see the requests split up in multiple of 512 byte and therefore the requests get rejected and

[BUG] Regression introduced with "block: split bios to max possible length"

Hi, unfortunately commit e36f62042880 "block: split bios to maxpossible length" breaks the DASD driver on s390. We expect the block requests to be multiple of 4k in size. With the patch applied I see the requests split up in multiple of 512 byte and therefore the requests get rejected and

Re: [PATCH 0/4] drivers/s390/block/dasd.c: code clean-up

On Thu, 26 Jun 2014, Fabian Frederick wrote: > This is an untested patchset to address some checkpatch warnings in dasd.c > Hi, thanks for the patches. I just tested and checked them and will apply them to our internal git repository. So they will most likely get upstream with the next

Re: [PATCH 0/4] drivers/s390/block/dasd.c: code clean-up

On Thu, 26 Jun 2014, Fabian Frederick wrote: This is an untested patchset to address some checkpatch warnings in dasd.c Hi, thanks for the patches. I just tested and checked them and will apply them to our internal git repository. So they will most likely get upstream with the next merge