<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/md/dm.c, branch linux-5.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-04-13T18:03:03Z</updated>
<entry>
<title>dm: requeue IO if mapping table not yet available</title>
<updated>2022-04-13T18:03:03Z</updated>
<author>
<name>Mike Snitzer</name>
</author>
<published>2022-02-22T18:28:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6ec8bb00066e8c7ceec1c6222e8f5179a2cd31d1'/>
<id>urn:sha1:6ec8bb00066e8c7ceec1c6222e8f5179a2cd31d1</id>
<content type='text'>
[ Upstream commit fa247089de9936a46e290d4724cb5f0b845600f5 ]

Update both bio-based and request-based DM to requeue IO if the
mapping table not available.

This race of IO being submitted before the DM device ready is so
narrow, yet possible for initial table load given that the DM device's
request_queue is created prior, that it best to requeue IO to handle
this unlikely case.

Reported-by: Zhang Yi &lt;yi.zhang@huawei.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dm: fix double accounting of flush with data</title>
<updated>2022-04-08T12:05:28Z</updated>
<author>
<name>Mike Snitzer</name>
</author>
<published>2022-02-18T04:39:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6925d909195f31d7fb380f5c68dd3e03c02303ef'/>
<id>urn:sha1:6925d909195f31d7fb380f5c68dd3e03c02303ef</id>
<content type='text'>
commit 8d394bc4adf588ca4a0650745167cb83f86c18c9 upstream.

DM handles a flush with data by first issuing an empty flush and then
once it completes the REQ_PREFLUSH flag is removed and the payload is
issued.  The problem fixed by this commit is that both the empty flush
bio and the data payload will account the full extent of the data
payload.

Fix this by factoring out dm_io_acct() and having it wrap all IO
accounting to set the size of  bio with REQ_PREFLUSH to 0, account the
IO, and then restore the original size.

Cc: stable@vger.kernel.org
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm: interlock pending dm_io and dm_wait_for_bios_completion</title>
<updated>2022-04-08T12:05:28Z</updated>
<author>
<name>Mike Snitzer</name>
</author>
<published>2022-02-18T04:40:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bee1419a19201a3ac0f98c8ee37413d2176a577e'/>
<id>urn:sha1:bee1419a19201a3ac0f98c8ee37413d2176a577e</id>
<content type='text'>
commit 9f6dc633761006f974701d4c88da71ab68670749 upstream.

Commit d208b89401e0 ("dm: fix mempool NULL pointer race when
completing IO") didn't go far enough.

When bio_end_io_acct ends the count of in-flight I/Os may reach zero
and the DM device may be suspended. There is a possibility that the
suspend races with dm_stats_account_io.

Fix this by adding percpu "pending_io" counters to track outstanding
dm_io. Move kicking of suspend queue to dm_io_dec_pending(). Also,
rename md_in_flight_bios() to dm_in_flight_bios() and update it to
iterate all pending_io counters.

Fixes: d208b89401e0 ("dm: fix mempool NULL pointer race when completing IO")
Cc: stable@vger.kernel.org
Co-developed-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm: fix use-after-free in dm_cleanup_zoned_dev()</title>
<updated>2022-04-08T12:05:28Z</updated>
<author>
<name>Kirill Tkhai</name>
</author>
<published>2022-02-01T08:39:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fdfe414ca28ddfd562c233fb27385cf820de03e8'/>
<id>urn:sha1:fdfe414ca28ddfd562c233fb27385cf820de03e8</id>
<content type='text'>
commit 588b7f5df0cb64f281290c7672470c006abe7160 upstream.

dm_cleanup_zoned_dev() uses queue, so it must be called
before blk_cleanup_disk() starts its killing:

blk_cleanup_disk-&gt;blk_cleanup_queue()-&gt;kobject_put()-&gt;blk_release_queue()-&gt;
-&gt;...RCU...-&gt;blk_free_queue_rcu()-&gt;kmem_cache_free()

Otherwise, RCU callback may be executed first and
dm_cleanup_zoned_dev() will touch free'd memory:

 BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0
 Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681

 CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x57/0x7d
  print_address_description.constprop.0+0x1f/0x150
  ? dm_cleanup_zoned_dev+0x33/0xd0
  kasan_report.cold+0x7f/0x11b
  ? dm_cleanup_zoned_dev+0x33/0xd0
  dm_cleanup_zoned_dev+0x33/0xd0
  __dm_destroy+0x26a/0x400
  ? dm_blk_ioctl+0x230/0x230
  ? up_write+0xd8/0x270
  dev_remove+0x156/0x1d0
  ctl_ioctl+0x269/0x530
  ? table_clear+0x140/0x140
  ? lock_release+0xb2/0x750
  ? remove_all+0x40/0x40
  ? rcu_read_lock_sched_held+0x12/0x70
  ? lock_downgrade+0x3c0/0x3c0
  ? rcu_read_lock_sched_held+0x12/0x70
  dm_ctl_ioctl+0xa/0x10
  __x64_sys_ioctl+0xb9/0xf0
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fb6dfa95c27

Fixes: bb37d77239af ("dm: introduce zone append emulation")
Cc: stable@vger.kernel.org
Signed-off-by: Kirill Tkhai &lt;ktkhai@virtuozzo.com&gt;
Reviewed-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm stats: fix too short end duration_ns when using precise_timestamps</title>
<updated>2022-04-08T12:05:28Z</updated>
<author>
<name>Mike Snitzer</name>
</author>
<published>2022-02-18T04:39:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=10b2ceee3eb291a00e779753222c4035a6dfa34f'/>
<id>urn:sha1:10b2ceee3eb291a00e779753222c4035a6dfa34f</id>
<content type='text'>
commit 0cdb90f0f306384ecbc60dfd6dc48cdbc1f2d0d8 upstream.

dm_stats_account_io()'s STAT_PRECISE_TIMESTAMPS support doesn't handle
the fact that with commit b879f915bc48 ("dm: properly fix redundant
bio-based IO accounting") io-&gt;start_time _may_ be in the past (meaning
the start_io_acct() was deferred until later).

Add a new dm_stats_recalc_precise_timestamps() helper that will
set/clear a new 'precise_timestamps' flag in the dm_stats struct based
on whether any configured stats enable STAT_PRECISE_TIMESTAMPS.
And update DM core's alloc_io() to use dm_stats_record_start() to set
stats_aux.duration_ns if stats-&gt;precise_timestamps is true.

Also, remove unused 'last_sector' and 'last_rw' members from the
dm_stats struct.

Fixes: b879f915bc48 ("dm: properly fix redundant bio-based IO accounting")
Cc: stable@vger.kernel.org
Co-developed-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>block: fix surprise removal for drivers calling blk_set_queue_dying</title>
<updated>2022-02-23T11:06:02Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2022-02-17T07:52:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0da8318e1d826f4d0df37026f3ea1a99a5fce293'/>
<id>urn:sha1:0da8318e1d826f4d0df37026f3ea1a99a5fce293</id>
<content type='text'>
commit 7a5428dcb7902700b830e912feee4e845df7c019 upstream.

Various block drivers call blk_set_queue_dying to mark a disk as dead due
to surprise removal events, but since commit 8e141f9eb803 that doesn't
work given that the GD_DEAD flag needs to be set to stop I/O.

Replace the driver calls to blk_set_queue_dying with a new (and properly
documented) blk_mark_disk_dead API, and fold blk_set_queue_dying into the
only remaining caller.

Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk")
Reported-by: Markus Blöchl &lt;markus.bloechl@ipetronik.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Link: https://lore.kernel.org/r/20220217075231.1140-1-hch@lst.de
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm: properly fix redundant bio-based IO accounting</title>
<updated>2022-02-01T16:29:06Z</updated>
<author>
<name>Mike Snitzer</name>
</author>
<published>2022-01-28T15:58:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=59274a00b13ef4352dc2e54438cddedff67c2f3e'/>
<id>urn:sha1:59274a00b13ef4352dc2e54438cddedff67c2f3e</id>
<content type='text'>
commit b879f915bc48a18d4f4462729192435bb0f17052 upstream.

Record the start_time for a bio but defer the starting block core's IO
accounting until after IO is submitted using bio_start_io_acct_time().

This approach avoids the need to mess around with any of the
individual IO stats in response to a bio_split() that follows bio
submission.

Reported-by: Bud Brown &lt;bubrown@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: stable@vger.kernel.org
Depends-on: e45c47d1f94e ("block: add bio_start_io_acct_time() to control start_time")
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Link: https://lore.kernel.org/r/20220128155841.39644-4-snitzer@redhat.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm: revert partial fix for redundant bio-based IO accounting</title>
<updated>2022-02-01T16:29:06Z</updated>
<author>
<name>Mike Snitzer</name>
</author>
<published>2022-01-28T15:58:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dc93c7ad7092329a54d99f2ccb797a76908a0739'/>
<id>urn:sha1:dc93c7ad7092329a54d99f2ccb797a76908a0739</id>
<content type='text'>
commit f524d9c95fab54783d0038f7a3e8c014d5b56857 upstream.

Reverts a1e1cb72d9649 ("dm: fix redundant IO accounting for bios that
need splitting") because it was too narrow in scope (only addressed
redundant 'sectors[]' accounting and not ios, nsecs[], etc).

Cc: stable@vger.kernel.org
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Link: https://lore.kernel.org/r/20220128155841.39644-3-snitzer@redhat.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm: make the DAX support depend on CONFIG_FS_DAX</title>
<updated>2022-01-27T11:02:33Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2021-11-29T10:21:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=121390bee73f9cc3ab3ee039c1cd34b57a641e88'/>
<id>urn:sha1:121390bee73f9cc3ab3ee039c1cd34b57a641e88</id>
<content type='text'>
[ Upstream commit 5d2a228b9e1319ff188f9ea89006fbe575561921 ]

The device mapper DAX support is all hanging off a block device and thus
can't be used with device dax.  Make it depend on CONFIG_FS_DAX instead
of CONFIG_DAX_DRIVER.  This also means that bdev_dax_pgoff only needs to
be built under CONFIG_FS_DAX now.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Link: https://lore.kernel.org/r/20211129102203.2243509-3-hch@lst.de
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dm: fix alloc_dax error handling in alloc_dev</title>
<updated>2022-01-27T11:02:33Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2021-11-29T10:21:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a30798b751277e94b36414b40df4622f3a82e23e'/>
<id>urn:sha1:a30798b751277e94b36414b40df4622f3a82e23e</id>
<content type='text'>
[ Upstream commit d751939235b9b7bc4af15f90a3e99288a8b844a7 ]

Make sure -&gt;dax_dev is NULL on error so that the cleanup path doesn't
trip over an ERR_PTR.

Reported-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Link: https://lore.kernel.org/r/20211129102203.2243509-2-hch@lst.de
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
