diff for duplicates of <1485899692.3113.9.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index 376ca30..40d3d2a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,42 +1,44 @@ 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. -> +> > or use my for-next where everything is already merged.=20 +>=20 > Hello Jens, -> +>=20 > 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: -> +>=20 > 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 +> =A0 comm "multipathd", pid 2353, jiffies 4295128020 (age 1332.440s) +> =A0 hex dump (first 32 bytes): +> =A0=A0=A0=A000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=A0=A0........= +........ +> =A0=A0=A0=A000 00 00 00 00 00 00 00 12 01 00 00 00 00 00 00=A0=A0........= +........ +> =A0 backtrace: +> =A0=A0=A0=A0[<ffffffff8165e3b5>] kmemleak_alloc+0x45/0xa0 +> =A0=A0=A0=A0[<ffffffff811cc23d>] __kmalloc+0x15d/0x2f0 +> =A0=A0=A0=A0[<ffffffff81310e35>] bio_alloc_bioset+0x185/0x1f0 +> =A0=A0=A0=A0[<ffffffff813117f4>] bio_map_user_iov+0x124/0x400 +> =A0=A0=A0=A0[<ffffffff81320b7a>] blk_rq_map_user_iov+0x11a/0x210 +> =A0=A0=A0=A0[<ffffffff81320cbd>] blk_rq_map_user+0x4d/0x60 +> =A0=A0=A0=A0[<ffffffff81336694>] sg_io+0x3d4/0x410 +> =A0=A0=A0=A0[<ffffffff813369d0>] scsi_cmd_ioctl+0x300/0x490 +> =A0=A0=A0=A0[<ffffffff81336b9d>] scsi_cmd_blk_ioctl+0x3d/0x50 +> =A0=A0=A0=A0[<ffffffff814b4360>] sd_ioctl+0x80/0x100 +> =A0=A0=A0=A0[<ffffffff8132ddde>] blkdev_ioctl+0x51e/0x9f0 +> =A0=A0=A0=A0[<ffffffff8122f388>] block_ioctl+0x38/0x40 +> =A0=A0=A0=A0[<ffffffff8120097f>] do_vfs_ioctl+0x8f/0x700 +> =A0=A0=A0=A0[<ffffffff8120102c>] SyS_ioctl+0x3c/0x70 +> =A0=A0=A0=A0[<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". -Bart. +Bart.= diff --git a/a/content_digest b/N1/content_digest index 9227960..3a91902 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -41,44 +41,46 @@ "On Tue, 2017-01-31 at 13:34 -0800, Bart Van Assche wrote:\n" "> On Mon, 2017-01-30 at 17:38 -0800, Jens Axboe wrote:\n" "> > That's a known bug in mainline. Pull it into 4.10-rc6,\n" - "> > or use my for-next where everything is already merged. \n" - "> \n" + "> > or use my for-next where everything is already merged.=20\n" + ">=20\n" "> Hello Jens,\n" - "> \n" + ">=20\n" "> With your for-next branch (commit c2e60b3a2602) I haven't hit any block\n" "> layer crashes so far. The only issue I encountered that is new is a\n" "> memory leak triggered by the SG-IO code. These memory leak reports\n" "> started to appear after I started testing the mq-deadline scheduler.\n" "> kmemleak reported the following call stack multiple times after my tests\n" "> had finished:\n" - "> \n" + ">=20\n" "> unreferenced object 0xffff88041119e528 (size 192):\n" - "> \302\240 comm \"multipathd\", pid 2353, jiffies 4295128020 (age 1332.440s)\n" - "> \302\240 hex dump (first 32 bytes):\n" - "> \302\240\302\240\302\240\302\24000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\302\240\302\240................\n" - "> \302\240\302\240\302\240\302\24000 00 00 00 00 00 00 00 12 01 00 00 00 00 00 00\302\240\302\240................\n" - "> \302\240 backtrace:\n" - "> \302\240\302\240\302\240\302\240[<ffffffff8165e3b5>] kmemleak_alloc+0x45/0xa0\n" - "> \302\240\302\240\302\240\302\240[<ffffffff811cc23d>] __kmalloc+0x15d/0x2f0\n" - "> \302\240\302\240\302\240\302\240[<ffffffff81310e35>] bio_alloc_bioset+0x185/0x1f0\n" - "> \302\240\302\240\302\240\302\240[<ffffffff813117f4>] bio_map_user_iov+0x124/0x400\n" - "> \302\240\302\240\302\240\302\240[<ffffffff81320b7a>] blk_rq_map_user_iov+0x11a/0x210\n" - "> \302\240\302\240\302\240\302\240[<ffffffff81320cbd>] blk_rq_map_user+0x4d/0x60\n" - "> \302\240\302\240\302\240\302\240[<ffffffff81336694>] sg_io+0x3d4/0x410\n" - "> \302\240\302\240\302\240\302\240[<ffffffff813369d0>] scsi_cmd_ioctl+0x300/0x490\n" - "> \302\240\302\240\302\240\302\240[<ffffffff81336b9d>] scsi_cmd_blk_ioctl+0x3d/0x50\n" - "> \302\240\302\240\302\240\302\240[<ffffffff814b4360>] sd_ioctl+0x80/0x100\n" - "> \302\240\302\240\302\240\302\240[<ffffffff8132ddde>] blkdev_ioctl+0x51e/0x9f0\n" - "> \302\240\302\240\302\240\302\240[<ffffffff8122f388>] block_ioctl+0x38/0x40\n" - "> \302\240\302\240\302\240\302\240[<ffffffff8120097f>] do_vfs_ioctl+0x8f/0x700\n" - "> \302\240\302\240\302\240\302\240[<ffffffff8120102c>] SyS_ioctl+0x3c/0x70\n" - "> \302\240\302\240\302\240\302\240[<ffffffff8166c4aa>] entry_SYSCALL_64_fastpath+0x18/0xad\n" + "> =A0 comm \"multipathd\", pid 2353, jiffies 4295128020 (age 1332.440s)\n" + "> =A0 hex dump (first 32 bytes):\n" + "> =A0=A0=A0=A000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=A0=A0........=\n" + "........\n" + "> =A0=A0=A0=A000 00 00 00 00 00 00 00 12 01 00 00 00 00 00 00=A0=A0........=\n" + "........\n" + "> =A0 backtrace:\n" + "> =A0=A0=A0=A0[<ffffffff8165e3b5>] kmemleak_alloc+0x45/0xa0\n" + "> =A0=A0=A0=A0[<ffffffff811cc23d>] __kmalloc+0x15d/0x2f0\n" + "> =A0=A0=A0=A0[<ffffffff81310e35>] bio_alloc_bioset+0x185/0x1f0\n" + "> =A0=A0=A0=A0[<ffffffff813117f4>] bio_map_user_iov+0x124/0x400\n" + "> =A0=A0=A0=A0[<ffffffff81320b7a>] blk_rq_map_user_iov+0x11a/0x210\n" + "> =A0=A0=A0=A0[<ffffffff81320cbd>] blk_rq_map_user+0x4d/0x60\n" + "> =A0=A0=A0=A0[<ffffffff81336694>] sg_io+0x3d4/0x410\n" + "> =A0=A0=A0=A0[<ffffffff813369d0>] scsi_cmd_ioctl+0x300/0x490\n" + "> =A0=A0=A0=A0[<ffffffff81336b9d>] scsi_cmd_blk_ioctl+0x3d/0x50\n" + "> =A0=A0=A0=A0[<ffffffff814b4360>] sd_ioctl+0x80/0x100\n" + "> =A0=A0=A0=A0[<ffffffff8132ddde>] blkdev_ioctl+0x51e/0x9f0\n" + "> =A0=A0=A0=A0[<ffffffff8122f388>] block_ioctl+0x38/0x40\n" + "> =A0=A0=A0=A0[<ffffffff8120097f>] do_vfs_ioctl+0x8f/0x700\n" + "> =A0=A0=A0=A0[<ffffffff8120102c>] SyS_ioctl+0x3c/0x70\n" + "> =A0=A0=A0=A0[<ffffffff8166c4aa>] entry_SYSCALL_64_fastpath+0x18/0xad\n" "\n" "After I repeated my test the above findings were confirmed: no memory leaks\n" "were reported by kmemleak after a test with I/O scheduler \"none\" and the\n" "above call stack was reported 44 times by kmemleak after a test with I/O\n" "scheduler \"mq-deadline\".\n" "\n" - Bart. + Bart.= -0bef95b02a42abdb71a2ebf6619777ce23369871bf36ffbc4f68a3e51f3a61a3 +210414afb9db4b4097ee891492ae90a41c364c82eec772d4871383a7d5cddf30
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.