From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>
Cc: "hch@lst.de" <hch@lst.de>, "axboe@fb.com" <axboe@fb.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"j-nomura@ce.jp.nec.com" <j-nomura@ce.jp.nec.com>
Subject: Re: [dm-devel] split scsi passthrough fields out of struct request V2
Date: Mon, 30 Jan 2017 17:38:34 -0800 [thread overview]
Message-ID: <4D024E85-CDE7-4FB0-B8CA-F2B8C86CCFCB@kernel.dk> (raw)
In-Reply-To: <1485825148.2669.18.camel@sandisk.com>
> On Jan 30, 2017, at 5:12 PM, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote:
>
>> On Fri, 2017-01-27 at 09:56 -0700, Jens Axboe wrote:
>>> On 01/27/2017 09:52 AM, Bart Van Assche wrote:
>>> [ 215.724452] general protection fault: 0000 [#1] SMP
>>> [ 215.725060] Call Trace:
>>> [ 215.725086] scsi_disk_put+0x2d/0x40
>>> [ 215.725110] sd_release+0x3d/0xb0
>>> [ 215.725137] __blkdev_put+0x29e/0x360
>>> [ 215.725163] blkdev_put+0x49/0x170
>>> [ 215.725192] dm_put_table_device+0x58/0xc0 [dm_mod]
>>> [ 215.725219] dm_put_device+0x70/0xc0 [dm_mod]
>>> [ 215.725269] free_priority_group+0x92/0xc0 [dm_multipath]
>>> [ 215.725295] free_multipath+0x70/0xc0 [dm_multipath]
>>> [ 215.725320] multipath_dtr+0x19/0x20 [dm_multipath]
>>> [ 215.725348] dm_table_destroy+0x67/0x120 [dm_mod]
>>> [ 215.725379] dev_suspend+0xde/0x240 [dm_mod]
>>> [ 215.725434] ctl_ioctl+0x1f5/0x520 [dm_mod]
>>> [ 215.725489] dm_ctl_ioctl+0xe/0x20 [dm_mod]
>>> [ 215.725515] do_vfs_ioctl+0x8f/0x700
>>> [ 215.725589] SyS_ioctl+0x3c/0x70
>>> [ 215.725614] entry_SYSCALL_64_fastpath+0x18/0xad
>>>
>>
>> I have no idea what this is, I haven't messed with life time or devices
>> or queues at all in that branch.
>
> Hello Jens,
>
> Running the srp-test software against kernel 4.9.6 and kernel 4.10-rc5
> went fine. With your for-4.11/block branch (commit 400f73b23f457a) however
> I just ran into the following:
>
> [ 214.555527] ------------[ cut here ]------------
> [ 214.555565] WARNING: CPU: 5 PID: 13201 at kernel/locking/lockdep.c:3514 lock_release+0x346/0x480
> [ 214.555588] DEBUG_LOCKS_WARN_ON(depth <= 0)
> [ 214.555824] CPU: 5 PID: 13201 Comm: fio Not tainted 4.10.0-rc3-dbg+ #1
> [ 214.555846] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 11/17/2014
> [ 214.555867] Call Trace:
> [ 214.555889] dump_stack+0x68/0x93
> [ 214.555911] __warn+0xc6/0xe0
> [ 214.555953] warn_slowpath_fmt+0x4a/0x50
> [ 214.555973] lock_release+0x346/0x480
> [ 214.556021] aio_write+0x106/0x140
> [ 214.556067] do_io_submit+0x37d/0x900
> [ 214.556108] SyS_io_submit+0xb/0x10
> [ 214.556131] entry_SYSCALL_64_fastpath+0x18/0xad
>
> I will continue to try to figure out what is causing this behavior.
That's a known bug in mainline. Pull it into 4.10-rc6,
or use my for-next where everything is already merged.
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>
Cc: "hch@lst.de" <hch@lst.de>, "axboe@fb.com" <axboe@fb.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"j-nomura@ce.jp.nec.com" <j-nomura@ce.jp.nec.com>
Subject: Re: [dm-devel] split scsi passthrough fields out of struct request V2
Date: Mon, 30 Jan 2017 17:38:34 -0800 [thread overview]
Message-ID: <4D024E85-CDE7-4FB0-B8CA-F2B8C86CCFCB@kernel.dk> (raw)
In-Reply-To: <1485825148.2669.18.camel@sandisk.com>
> On Jan 30, 2017, at 5:12 PM, Bart Van Assche <Bart.VanAssche@sandisk.com> w=
rote:
>=20
>> On Fri, 2017-01-27 at 09:56 -0700, Jens Axboe wrote:
>>> On 01/27/2017 09:52 AM, Bart Van Assche wrote:
>>> [ 215.724452] general protection fault: 0000 [#1] SMP
>>> [ 215.725060] Call Trace:
>>> [ 215.725086] scsi_disk_put+0x2d/0x40
>>> [ 215.725110] sd_release+0x3d/0xb0
>>> [ 215.725137] __blkdev_put+0x29e/0x360
>>> [ 215.725163] blkdev_put+0x49/0x170
>>> [ 215.725192] dm_put_table_device+0x58/0xc0 [dm_mod]
>>> [ 215.725219] dm_put_device+0x70/0xc0 [dm_mod]
>>> [ 215.725269] free_priority_group+0x92/0xc0 [dm_multipath]
>>> [ 215.725295] free_multipath+0x70/0xc0 [dm_multipath]
>>> [ 215.725320] multipath_dtr+0x19/0x20 [dm_multipath]
>>> [ 215.725348] dm_table_destroy+0x67/0x120 [dm_mod]
>>> [ 215.725379] dev_suspend+0xde/0x240 [dm_mod]
>>> [ 215.725434] ctl_ioctl+0x1f5/0x520 [dm_mod]
>>> [ 215.725489] dm_ctl_ioctl+0xe/0x20 [dm_mod]
>>> [ 215.725515] do_vfs_ioctl+0x8f/0x700
>>> [ 215.725589] SyS_ioctl+0x3c/0x70
>>> [ 215.725614] entry_SYSCALL_64_fastpath+0x18/0xad
>>>=20
>>=20
>> I have no idea what this is, I haven't messed with life time or devices
>> or queues at all in that branch.
>=20
> Hello Jens,
>=20
> Running the srp-test software against kernel 4.9.6 and kernel 4.10-rc5
> went fine. With your for-4.11/block branch (commit 400f73b23f457a) however=
> I just ran into the following:
>=20
> [ 214.555527] ------------[ cut here ]------------
> [ 214.555565] WARNING: CPU: 5 PID: 13201 at kernel/locking/lockdep.c:3514=
lock_release+0x346/0x480
> [ 214.555588] DEBUG_LOCKS_WARN_ON(depth <=3D 0)
> [ 214.555824] CPU: 5 PID: 13201 Comm: fio Not tainted 4.10.0-rc3-dbg+ #1
> [ 214.555846] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 1=
1/17/2014
> [ 214.555867] Call Trace:
> [ 214.555889] dump_stack+0x68/0x93
> [ 214.555911] __warn+0xc6/0xe0
> [ 214.555953] warn_slowpath_fmt+0x4a/0x50
> [ 214.555973] lock_release+0x346/0x480
> [ 214.556021] aio_write+0x106/0x140
> [ 214.556067] do_io_submit+0x37d/0x900
> [ 214.556108] SyS_io_submit+0xb/0x10
> [ 214.556131] entry_SYSCALL_64_fastpath+0x18/0xad
>=20
> I will continue to try to figure out what is causing this behavior.
That's a known bug in mainline. Pull it into 4.10-rc6,
or use my for-next where everything is already merged.=20
next prev parent reply other threads:[~2017-01-31 1:38 UTC|newest]
Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 17:25 split scsi passthrough fields out of struct request V2 Christoph Hellwig
2017-01-25 17:25 ` [PATCH 01/18] block: add a op_is_flush helper Christoph Hellwig
2017-01-26 2:58 ` Martin K. Petersen
2017-01-26 22:38 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 02/18] md: cleanup bio op / flags handling in raid1_write_request Christoph Hellwig
2017-01-26 2:59 ` Martin K. Petersen
2017-01-26 23:18 ` Bart Van Assche
2017-01-26 23:18 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 03/18] block: fix elevator init check Christoph Hellwig
2017-01-26 3:01 ` Martin K. Petersen
2017-01-26 23:21 ` Bart Van Assche
2017-01-26 23:21 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 04/18] block: simplify blk_init_allocated_queue Christoph Hellwig
2017-01-26 3:02 ` Martin K. Petersen
2017-01-26 23:27 ` Bart Van Assche
2017-01-26 23:27 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 05/18] block: allow specifying size for extra command data Christoph Hellwig
2017-01-26 3:15 ` Martin K. Petersen
2017-01-27 16:12 ` Christoph Hellwig
2017-01-27 16:12 ` Christoph Hellwig
2017-01-27 17:21 ` Bart Van Assche
2017-01-27 17:21 ` Bart Van Assche
2017-01-27 17:26 ` Jens Axboe
2017-01-27 17:26 ` Jens Axboe
2017-01-27 17:30 ` Bart Van Assche
2017-01-27 17:30 ` Bart Van Assche
2017-01-27 17:33 ` Jens Axboe
2017-01-25 17:25 ` [PATCH 06/18] dm: remove incomple BLOCK_PC support Christoph Hellwig
2017-01-27 17:32 ` Bart Van Assche
2017-01-27 17:32 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue Christoph Hellwig
2017-01-27 16:34 ` Mike Snitzer
2017-01-27 16:34 ` Mike Snitzer
2017-01-27 16:36 ` Christoph Hellwig
2017-01-27 16:36 ` Christoph Hellwig
2017-01-27 16:44 ` Mike Snitzer
2017-01-27 16:44 ` Mike Snitzer
2017-01-25 17:25 ` [PATCH 08/18] scsi_dh_rdac: switch to scsi_execute_req_flags() Christoph Hellwig
2017-01-26 3:18 ` Martin K. Petersen
2017-01-25 17:25 ` [PATCH 09/18] scsi_dh_emc: " Christoph Hellwig
2017-01-26 3:19 ` Martin K. Petersen
2017-01-25 17:25 ` [PATCH 10/18] scsi_dh_hp_sw: " Christoph Hellwig
2017-01-26 3:20 ` Martin K. Petersen
2017-01-26 3:20 ` Martin K. Petersen
2017-01-25 17:25 ` [PATCH 11/18] scsi: remove gfp_flags member in scsi_host_cmd_pool Christoph Hellwig
2017-01-26 3:21 ` Martin K. Petersen
2017-01-27 17:38 ` Bart Van Assche
2017-01-27 17:38 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 12/18] scsi: respect unchecked_isa_dma for blk-mq Christoph Hellwig
2017-01-26 3:23 ` Martin K. Petersen
2017-01-27 17:45 ` Bart Van Assche
2017-01-27 17:45 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 13/18] scsi: remove scsi_cmd_dma_pool Christoph Hellwig
2017-01-26 3:24 ` Martin K. Petersen
2017-01-27 17:51 ` Bart Van Assche
2017-01-27 17:51 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 14/18] scsi: remove __scsi_alloc_queue Christoph Hellwig
2017-01-26 3:25 ` Martin K. Petersen
2017-01-27 17:58 ` Bart Van Assche
2017-01-27 17:58 ` Bart Van Assche
2017-01-28 8:23 ` hch
2017-01-25 17:25 ` [PATCH 15/18] scsi: allocate scsi_cmnd structures as part of struct request Christoph Hellwig
2017-01-26 3:30 ` Martin K. Petersen
2017-01-27 18:39 ` Bart Van Assche
2017-01-27 18:39 ` Bart Van Assche
2017-01-28 8:25 ` hch
2017-01-28 8:25 ` hch
2017-01-25 17:25 ` [PATCH 16/18] block/bsg: move queue creation into bsg_setup_queue Christoph Hellwig
2017-01-27 18:48 ` Bart Van Assche
2017-01-27 18:48 ` Bart Van Assche
2017-01-25 17:25 ` [PATCH 17/18] block: split scsi_request out of struct request Christoph Hellwig
2017-01-25 17:25 ` [PATCH 18/18] block: don't assign cmd_flags in __blk_rq_prep_clone Christoph Hellwig
2017-01-26 3:31 ` Martin K. Petersen
2017-01-26 18:29 ` split scsi passthrough fields out of struct request V2 Bart Van Assche
2017-01-26 18:29 ` Bart Van Assche
2017-01-26 18:44 ` Jens Axboe
2017-01-26 18:52 ` Bart Van Assche
2017-01-26 18:52 ` Bart Van Assche
2017-01-26 18:57 ` Jens Axboe
2017-01-26 18:59 ` hch
2017-01-26 19:01 ` Jens Axboe
2017-01-26 19:01 ` Jens Axboe
2017-01-26 20:47 ` [dm-devel] " Bart Van Assche
2017-01-26 20:54 ` Jens Axboe
2017-01-26 20:54 ` [dm-devel] " Jens Axboe
2017-01-26 21:01 ` Bart Van Assche
2017-01-26 21:01 ` Bart Van Assche
2017-01-26 21:12 ` Jens Axboe
2017-01-26 21:12 ` [dm-devel] " Jens Axboe
2017-01-26 21:47 ` Bart Van Assche
2017-01-26 21:47 ` [dm-devel] " Bart Van Assche
2017-01-26 21:51 ` Jens Axboe
2017-01-26 21:51 ` [dm-devel] " Jens Axboe
2017-01-26 23:14 ` Bart Van Assche
2017-01-26 23:14 ` Bart Van Assche
2017-01-26 23:26 ` Jens Axboe
2017-01-26 23:26 ` Jens Axboe
2017-01-26 23:26 ` [dm-devel] " Jens Axboe
2017-01-26 23:47 ` Bart Van Assche
2017-01-26 23:47 ` [dm-devel] " Bart Van Assche
2017-01-26 23:50 ` Jens Axboe
2017-01-27 0:33 ` Jens Axboe
2017-01-27 0:33 ` [dm-devel] " Jens Axboe
2017-01-27 0:38 ` Bart Van Assche
2017-01-27 0:38 ` Bart Van Assche
2017-01-27 0:41 ` Jens Axboe
2017-01-27 1:15 ` Bart Van Assche
2017-01-27 1:15 ` [dm-devel] " Bart Van Assche
2017-01-27 1:22 ` Jens Axboe
2017-01-27 1:22 ` [dm-devel] " Jens Axboe
2017-01-27 6:40 ` Jens Axboe
2017-01-27 8:04 ` Jens Axboe
2017-01-27 8:04 ` [dm-devel] " Jens Axboe
2017-01-27 16:52 ` Bart Van Assche
2017-01-27 16:52 ` [dm-devel] " Bart Van Assche
2017-01-27 16:56 ` Jens Axboe
2017-01-27 16:56 ` [dm-devel] " Jens Axboe
2017-01-27 17:03 ` Bart Van Assche
2017-01-27 17:03 ` [dm-devel] " Bart Van Assche
2017-01-31 1:12 ` Bart Van Assche
2017-01-31 1:12 ` Bart Van Assche
2017-01-31 1:38 ` Jens Axboe [this message]
2017-01-31 1:38 ` Jens Axboe
2017-01-31 4:13 ` Jens Axboe
2017-01-31 4:13 ` [dm-devel] " Jens Axboe
2017-01-31 21:35 ` Bart Van Assche
2017-01-31 21:35 ` Bart Van Assche
2017-01-31 21:55 ` Bart Van Assche
2017-01-31 21:55 ` Bart Van Assche
2017-01-31 21:58 ` Jens Axboe
2017-02-01 1:01 ` Bart Van Assche
2017-02-01 6:38 ` Jens Axboe
2017-02-01 16:46 ` Bart Van Assche
2017-02-01 17:13 ` Jens Axboe
2017-02-01 17:28 ` Bart Van Assche
2017-02-01 19:21 ` Bart Van Assche
2017-02-01 22:01 ` Bart Van Assche
2017-02-02 17:27 ` Bart Van Assche
2017-02-02 18:33 ` Mike Snitzer
2017-02-02 18:43 ` Bart Van Assche
2017-02-02 19:13 ` Mike Snitzer
2017-02-02 19:46 ` Bart Van Assche
2017-02-02 21:04 ` Mike Snitzer
2017-02-02 21:10 ` Mike Snitzer
2017-02-03 0:20 ` Bart Van Assche
2017-02-03 0:42 ` Mike Snitzer
2017-02-02 22:38 ` Bart Van Assche
2017-01-27 17:02 ` [dm-devel] " Bart Van Assche
2017-01-27 17:02 ` Bart Van Assche
2017-01-27 16:11 ` Jens Axboe
2017-01-27 16:11 ` Jens Axboe
2017-01-27 16:17 ` Christoph Hellwig
2017-01-27 16:17 ` Christoph Hellwig
2017-01-27 16:21 ` Jens Axboe
2017-01-27 16:21 ` Jens Axboe
2017-01-27 16:23 ` Christoph Hellwig
2017-01-27 16:23 ` Christoph Hellwig
2017-01-27 16:27 ` Jens Axboe
2017-01-27 16:27 ` Jens Axboe
2017-01-27 16:34 ` Christoph Hellwig
2017-01-27 16:34 ` Christoph Hellwig
2017-01-27 16:38 ` Jens Axboe
2017-01-27 16:38 ` Jens Axboe
2017-01-27 16:42 ` Christoph Hellwig
2017-01-27 16:42 ` Christoph Hellwig
2017-01-27 16:58 ` Jens Axboe
2017-01-27 16:58 ` Jens Axboe
2017-01-27 21:27 ` Bart Van Assche
2017-01-27 21:27 ` Bart Van Assche
2017-01-28 8:29 ` hch
2017-01-30 6:58 ` Hannes Reinecke
2017-01-30 6:58 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D024E85-CDE7-4FB0-B8CA-F2B8C86CCFCB@kernel.dk \
--to=axboe@kernel.dk \
--cc=Bart.VanAssche@sandisk.com \
--cc=axboe@fb.com \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=j-nomura@ce.jp.nec.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=snitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.