[Devel] [PATCH hci-8.1 v5 10/11] dm-ploop: reload metadata on resume

[Alexander Ivanov]

> [Severity: Medium]
> ploop_wait_prealloc() discards the return value of wait_event_killable().
> If the suspending task is killed while the old allocator is still inside
> ploop_preallocate_cluster(), ploop_postsuspend() carries on and marks
> the device suspended:
> ...

This race predates the patch: before it, postsuspend didn't wait for the
allocator at all, so a late truncate could shrink the file under the new
ploop on any suspend. The patch narrows it to a killed wait or standby,
so it doesn't make things worse.

> The comment above says the prealloc wait is skipped in standby and made
> killable so that dm_replace() of libploop can suspend a device whose
> backing file is dead.  Is the new wait_event() on inflight_md_wq missing
> the same escape? ...
A BAT write that is tied to user I/O can't stall postsuspend: data and
discard pios are completed in ploop_bat_write_finish() only after the
BAT write is done, so a stuck BAT write already blocks the interruptible
dm_wait_for_completion() before postsuspend. By then only the non-blocking
window up to ploop_dec_inflight_md() is left, and in standby the I/O fails
  with an error, which drains inflight_md as well.

> On a reloaded table, the new ploop never runs ploop_postsuspend(), and 
> ploop_ctr() never initializes ->suspended, so it stays false from 
> kzalloc. If ploop_reload_metadata() fails (-ENOMEM, -EIO, -EBADSLT) or 
> noresume is set, ploop_preresume() returns an error and skips 
> ploop_set_suspended(ti, false), while DM keeps the device suspended. ...

Fixed.


> This is the only place ploop->standby is written, and nothing in
> drivers/md/dm-ploop-*.c clears it.  The queue bit, by contrast, is
> cleared in ploop_ctr(): ...
The flag is intentionally sticky: the old instance's files stay dead,
so reloading on them would hang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/devel/attachments/20261013/cfc471fc/attachment-0001.html>