aboutsummaryrefslogtreecommitdiffstats
path: root/hw/virtio-9p.c
diff options
context:
space:
mode:
authorM. Mohan Kumar <mohan@in.ibm.com>2010-09-08 02:19:32 +0530
committerAnthony Liguori <aliguori@us.ibm.com>2010-10-20 12:10:58 -0500
commit82cc3ee88ba238ec3ba96f4673d8a184588b82a4 (patch)
tree5c0660ba3b0dedb90ee14dcda0ec5060841f7677 /hw/virtio-9p.c
parentab03b63d7a9c7978d51e56c191f0b86888d121dc (diff)
[virto-9p] Implement TLOCK
Synopsis size[4] TLock tag[2] fid[4] flock[n] size[4] RLock tag[2] status[1] Description Tlock is used to acquire/release byte range posix locks on a file identified by given fid. The reply contains status of the lock request flock structure: type[1] - Type of lock: F_RDLCK, F_WRLCK, F_UNLCK flags[4] - Flags could be either of P9_LOCK_FLAGS_BLOCK(1) - Blocked lock request, if there is a conflicting lock exists, wait for that lock to be released. P9_LOCK_FLAGS_RECLAIM(2) - Reclaim lock request, used when client is trying to reclaim a lock after a server restrart (due to crash) start[8] - Starting offset for lock length[8] - Number of bytes to lock If length is 0, lock all bytes starting at the location 'start' through to the end of file pid[4] - PID of the process that wants to take lock client_id[4] - Unique client id status[1] - Status of the lock request, can be P9_LOCK_SUCCESS(0), P9_LOCK_BLOCKED(1), P9_LOCK_ERROR(2) or P9_LOCK_GRACE(3) P9_LOCK_SUCCESS - Request was successful P9_LOCK_BLOCKED - A conflicting lock is held by another process P9_LOCK_ERROR - Error while processing the lock request P9_LOCK_GRACE - Server is in grace period, it can't accept new lock requests in this period (except locks with P9_LOCK_FLAGS_RECLAIM flag set) Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
Diffstat (limited to 'hw/virtio-9p.c')
-rw-r--r--hw/virtio-9p.c50
1 files changed, 50 insertions, 0 deletions
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 3379a3029..20acb5b1e 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -3154,6 +3154,55 @@ out:
qemu_free(vs);
}
+/*
+ * Implement posix byte range locking code
+ * Server side handling of locking code is very simple, because 9p server in
+ * QEMU can handle only one client. And most of the lock handling
+ * (like conflict, merging) etc is done by the VFS layer itself, so no need to
+ * do any thing in * qemu 9p server side lock code path.
+ * So when a TLOCK request comes, always return success
+ */
+
+static void v9fs_lock(V9fsState *s, V9fsPDU *pdu)
+{
+ int32_t fid, err = 0;
+ V9fsLockState *vs;
+
+ vs = qemu_mallocz(sizeof(*vs));
+ vs->pdu = pdu;
+ vs->offset = 7;
+
+ vs->flock = qemu_malloc(sizeof(*vs->flock));
+ pdu_unmarshal(vs->pdu, vs->offset, "dbdqqds", &fid, &vs->flock->type,
+ &vs->flock->flags, &vs->flock->start, &vs->flock->length,
+ &vs->flock->proc_id, &vs->flock->client_id);
+
+ vs->status = P9_LOCK_ERROR;
+
+ /* We support only block flag now (that too ignored currently) */
+ if (vs->flock->flags & ~P9_LOCK_FLAGS_BLOCK) {
+ err = -EINVAL;
+ goto out;
+ }
+ vs->fidp = lookup_fid(s, fid);
+ if (vs->fidp == NULL) {
+ err = -ENOENT;
+ goto out;
+ }
+
+ err = v9fs_do_fstat(s, vs->fidp->fs.fd, &vs->stbuf);
+ if (err < 0) {
+ err = -errno;
+ goto out;
+ }
+ vs->status = P9_LOCK_SUCCESS;
+out:
+ vs->offset += pdu_marshal(vs->pdu, vs->offset, "b", vs->status);
+ complete_pdu(s, vs->pdu, err);
+ qemu_free(vs->flock);
+ qemu_free(vs);
+}
+
static void v9fs_mkdir_post_lstat(V9fsState *s, V9fsMkState *vs, int err)
{
if (err == -1) {
@@ -3416,6 +3465,7 @@ static pdu_handler_t *pdu_handlers[] = {
[P9_TXATTRCREATE] = v9fs_xattrcreate,
[P9_TMKNOD] = v9fs_mknod,
[P9_TRENAME] = v9fs_rename,
+ [P9_TLOCK] = v9fs_lock,
[P9_TMKDIR] = v9fs_mkdir,
[P9_TVERSION] = v9fs_version,
[P9_TLOPEN] = v9fs_open,