[dm-devel] split scsi passthrough fields out of struct request V2
Jens Axboe
axboe at kernel.dk
Tue Jan 31 21:58:35 UTC 2017
On 01/31/2017 01:55 PM, Bart Van Assche wrote:
> On Tue, 2017-01-31 at 13:34 -0800, Bart Van Assche wrote:
>> On Mon, 2017-01-30 at 17:38 -0800, Jens Axboe wrote:
>>> That's a known bug in mainline. Pull it into 4.10-rc6,
>>> or use my for-next where everything is already merged.
>>
>> Hello Jens,
>>
>> With your for-next branch (commit c2e60b3a2602) I haven't hit any block
>> layer crashes so far. The only issue I encountered that is new is a
>> memory leak triggered by the SG-IO code. These memory leak reports
>> started to appear after I started testing the mq-deadline scheduler.
>> kmemleak reported the following call stack multiple times after my tests
>> had finished:
>>
>> unreferenced object 0xffff88041119e528 (size 192):
>> comm "multipathd", pid 2353, jiffies 4295128020 (age 1332.440s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 00 00 00 00 00 00 00 00 12 01 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffff8165e3b5>] kmemleak_alloc+0x45/0xa0
>> [<ffffffff811cc23d>] __kmalloc+0x15d/0x2f0
>> [<ffffffff81310e35>] bio_alloc_bioset+0x185/0x1f0
>> [<ffffffff813117f4>] bio_map_user_iov+0x124/0x400
>> [<ffffffff81320b7a>] blk_rq_map_user_iov+0x11a/0x210
>> [<ffffffff81320cbd>] blk_rq_map_user+0x4d/0x60
>> [<ffffffff81336694>] sg_io+0x3d4/0x410
>> [<ffffffff813369d0>] scsi_cmd_ioctl+0x300/0x490
>> [<ffffffff81336b9d>] scsi_cmd_blk_ioctl+0x3d/0x50
>> [<ffffffff814b4360>] sd_ioctl+0x80/0x100
>> [<ffffffff8132ddde>] blkdev_ioctl+0x51e/0x9f0
>> [<ffffffff8122f388>] block_ioctl+0x38/0x40
>> [<ffffffff8120097f>] do_vfs_ioctl+0x8f/0x700
>> [<ffffffff8120102c>] SyS_ioctl+0x3c/0x70
>> [<ffffffff8166c4aa>] entry_SYSCALL_64_fastpath+0x18/0xad
>
> After I repeated my test the above findings were confirmed: no memory leaks
> were reported by kmemleak after a test with I/O scheduler "none" and the
> above call stack was reported 44 times by kmemleak after a test with I/O
> scheduler "mq-deadline".
Interesting, I'll check this. Doesn't make any sense why the scheduler
would be implicated in that, given how we run completions now. But if
it complains, then something must be up.
--
Jens Axboe
More information about the dm-devel
mailing list