From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, mreitz@redhat.com,
eblake@redhat.com, vsementsov@virtuozzo.com, den@openvz.org
Subject: [PATCH RFC] docs: document file-posix locking protocol
Date: Mon, 22 Mar 2021 21:27:38 +0300 [thread overview]
Message-ID: <20210322182738.60395-1-vsementsov@virtuozzo.com> (raw)
Let's document how we use file locks in file-posix driver, to allow
external programs to "communicate" in this way with Qemu.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
Hi all!
We need to access disk images from non-Qemu code and coordinate with
Qemu utilities which may use same image. So, we want to support Qemu
file locking in the external code.
So, here is a patch to document how Qemu locking works, and make this
thing "public".
This is an RFC, because I'm unsure how should we actually document
different operations we have.
For example greaph-mod is a strange thing, I think we should get rid
of it at all.. And at least, no sense in locking corresponding byte in a
raw file.
The other thing is write-unchanged.. What it means when we consider a
raw file opened in several processes? Probably we don't need it too..
docs/system/qemu-block-drivers.rst.inc | 55 ++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/docs/system/qemu-block-drivers.rst.inc b/docs/system/qemu-block-drivers.rst.inc
index b052a6d14e..3cd708b3dc 100644
--- a/docs/system/qemu-block-drivers.rst.inc
+++ b/docs/system/qemu-block-drivers.rst.inc
@@ -952,3 +952,58 @@ on host and see if there are locks held by the QEMU process on the image file.
More than one byte could be locked by the QEMU instance, each byte of which
reflects a particular permission that is acquired or protected by the running
block driver.
+
+Image locking protocol
+~~~~~~~~~~~~~~~~~~~~~~
+
+QEMU holds rd locks and never rw locks. Instead, GETLK fcntl is used with F_WRLCK
+to handle permissions as described below.
+QEMU process may rd-lock the following bytes of the image with corresponding
+meaning:
+
+Permission bytes. If permission byte is rd-locked, it means that some process
+uses corresponding permission on that file.
+
+Byte Operation
+100 read
+ Lock holder can read
+101 write
+ Lock holder can write
+102 write-unchanged
+ Lock holder can write same data
+103 resize
+ Lock holder can resize the file
+104 graph-mod
+ Undefined. QEMU sometimes locks this byte, but external programs
+ should not. QEMU will stop locking this byte in future
+
+Unshare bytes. If permission byte is rd-locked, it means that some process
+does not allow the others use corresponding options on that file.
+
+Byte Operation
+200 read
+ Lock holder don't allow read operation to other processes.
+201 write
+ Lock holder don't allow write operation to other processes.
+202 write-unchanged
+ Lock holder don't allow write-unchanged operation to other processes.
+203 resize
+ Lock holder don't allow resizing the file by other processes.
+204 graph-mod
+ Undefined. QEMU sometimes locks this byte, but external programs
+ should not. QEMU will stop locking this byte in future
+
+Handling the permissions works as follows: assume we want to open the file to do
+some operations and in the same time want to disallow some operation to other
+processes. So, we want to lock some of the bytes described above. We operate as
+follows:
+
+1. rd-lock all needed bytes, both "permission" bytes and "unshare" bytes.
+
+2. For each "unshare" byte we rd-locked, do GETLK that "tries" to wr-lock
+corresponding "permission" byte. So, we check is there any other process that
+uses the permission we want to unshare. If it exists we fail.
+
+3. For each "permission" byte we rd-locked, do GETLK that "tries" to wr-lock
+corresponding "unshare" byte. So, we check is there any other process that
+unshares the permission we want to have. If it exists we fail.
--
2.29.2
next reply other threads:[~2021-03-22 18:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 18:27 Vladimir Sementsov-Ogievskiy [this message]
2021-05-24 14:40 ` [PATCH RFC] docs: document file-posix locking protocol Vladimir Sementsov-Ogievskiy
2021-06-22 11:14 ` Vladimir Sementsov-Ogievskiy
2021-06-22 12:00 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210322182738.60395-1-vsementsov@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.