]> git.proxmox.com Git - mirror_qemu.git/commit
preallocate: Don't poll during permission updates
authorKevin Wolf <kwolf@redhat.com>
Mon, 11 Sep 2023 09:46:02 +0000 (11:46 +0200)
committerKevin Wolf <kwolf@redhat.com>
Wed, 20 Sep 2023 15:46:00 +0000 (17:46 +0200)
commitedcce17b1590d0e785d303d31a7b08182a1bdb1e
tree61e192325fdb37f21e28a3045ad3cd35c3329e7c
parent01e28f6006e689fc4d0ce0f7246ce1e5cbdef758
preallocate: Don't poll during permission updates

When the permission related BlockDriver callbacks are called, we are in
the middle of an operation traversing the block graph. Polling in such a
place is a very bad idea because the graph could change in unexpected
ways. In the future, callers will also hold the graph lock, which is
likely to turn polling into a deadlock.

So we need to get rid of calls to functions like bdrv_getlength() or
bdrv_truncate() there as these functions poll internally. They are
currently used so that when no parent has write/resize permissions on
the image any more, the preallocate filter drops the extra preallocated
area in the image file and gives up write/resize permissions itself.

In order to achieve this without polling in .bdrv_check_perm, don't
immediately truncate the image, but only schedule a BH to do so. The
filter keeps the write/resize permissions a bit longer now until the BH
has executed.

There is one case in which delaying doesn't work: Reopening the image
read-only. In this case, bs->file will likely be reopened read-only,
too, so keeping write permissions a bit longer on it doesn't work. But
we can already cover this case in preallocate_reopen_prepare() and not
rely on the permission updates for it.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20230911094620.45040-4-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block/preallocate.c