- 28 2月, 2017 2 次提交
-
-
由 Pradeep Jagadeesh 提交于
This patchset adds the throttle support for the 9p-local driver. For now this functionality can be enabled only through qemu cli options. QMP interface and support to other drivers need further extensions. To make it simple for other 9p drivers, the throttle code has been put in separate files. Signed-off-by: NPradeep Jagadeesh <pradeep.jagadeesh@huawei.com> Reviewed-by: NAlberto Garcia <berto@igalia.com> (pass extra NULL CoMutex * argument to qemu_co_queue_wait(), added options to qemu-options.hx, Greg Kurz) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Paolo Bonzini 提交于
In this case, we are marshaling an error status instead of the errno value. Reorganize the out and out_nofid labels to look like all the other cases. Coverity reports this because the "err = -ENOENT" and "err = -EINVAL" assignments above are dead, overwritten by the call to pdu_marshal. (Coverity issues CID1348512 and CID1348513) Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (also open-coded the success path since locking is a nop for us, Greg Kurz) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
- 21 2月, 2017 1 次提交
-
-
由 Paolo Bonzini 提交于
All that CoQueue needs in order to become thread-safe is help from an external mutex. Add this to the API. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Message-id: 20170213181244.16297-6-pbonzini@redhat.com Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 25 1月, 2017 4 次提交
-
-
由 Greg Kurz 提交于
The current code tries to copy `read_count' bytes starting at offset `offset' from a `read_count`-sized iovec. This causes v9fs_pack() to fail with ENOBUFS. Since the PDU iovec is already partially filled with `offset' bytes, let's skip them when creating `qiov_full' and have v9fs_pack() to copy the whole of it. Moreover, this is consistent with the other places where v9fs_init_qiov_from_pdu() is called. This fixes commit "bcb8998f 9pfs: call v9fs_init_qiov_from_pdu before v9fs_pack". Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
-
由 Greg Kurz 提交于
The server can handle MAX_REQ - 1 PDUs at a time and the virtio-9p device has a MAX_REQ sized virtqueue. If the client manages to fill up the virtqueue, pdu_alloc() will fail and the request won't be processed without any notice to the client (it actually causes the linux 9p client to hang). This has been there since the beginning (commit 9f107513 "virtio-9p: Add a virtio 9p device to qemu"), but it needs an agressive workload to run in the guest to show up. We actually allocate MAX_REQ PDUs and I see no reason not to link them all into the free list, so let's fix the init loop. Reported-by: NTuomas Tynkkynen <tuomas@tuxera.com> Suggested-by: NAl Viro <viro@ZenIV.linux.org.uk> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Ashijeet Acharya 提交于
If a migration is already in progress and somebody attempts to add a migration blocker, this should rightly fail. Add an errp parameter and a retcode return value to migrate_add_blocker. Signed-off-by: NJohn Snow <jsnow@redhat.com> Signed-off-by: NAshijeet Acharya <ashijeetacharya@gmail.com> Message-Id: <1484566314-3987-5-git-send-email-ashijeetacharya@gmail.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Acked-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Merged with recent 'Allow invtsc migration' change
-
- 04 1月, 2017 5 次提交
-
-
由 Greg Kurz 提交于
If the user passes -device virtio-9p without the corresponding -fsdev, QEMU dereferences a NULL pointer and crashes. This is a 2.8 regression introduced by commit 702dbcc2. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NLi Qiang <liq3ea@gmail.com>
-
由 Stefano Stabellini 提交于
Not all 9pfs transports share memory between request and response. For those who don't, it is necessary to know how much memory is required in the response. Split the existing init_iov_from_pdu function in two: init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads). init_in_iov_from_pdu takes an additional size parameter to specify the memory required for the response message. Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Stefano Stabellini 提交于
v9fs_xattr_read should not access VirtQueueElement elems directly. Move v9fs_init_qiov_from_pdu up in the file and call v9fs_init_qiov_from_pdu before v9fs_pack. Use v9fs_pack on the new iovec. Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Stefano Stabellini 提交于
Don't call virtio functions from 9pfs generic code, use generic function callbacks instead. Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Stefano Stabellini 提交于
pdus are initialized and used in 9pfs common code. Move the array from V9fsVirtioState to V9fsState. Signed-off-by: NStefano Stabellini <sstabellini@kernel.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
- 23 11月, 2016 2 次提交
-
-
由 Li Qiang 提交于
Currently, the backend of VirtFS doesn't have a cleanup function. This will lead resource leak issues if the backed driver allocates resources. This patch addresses this issue. Signed-off-by: NLi Qiang <liq3ea@gmail.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
Unrealize should undo things that were set during realize in reverse order. So should do in the error path in realize. Signed-off-by: NLi Qiang <liq3ea@gmail.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
- 01 11月, 2016 6 次提交
-
-
由 Greg Kurz 提交于
The virtfs_reset() function is called either when the virtio-9p device gets reset, or when the client starts a new 9P session. In both cases, if it finds fids from a previous session, the following is printed in the monitor: 9pfs:virtfs_reset: One or more uncluncked fids found during reset For example, if a linux guest with a mounted 9P share is reset from the monitor with system_reset, the message will be printed. This is excessive since these fids are now clunked and the state is clean. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Greg Kurz 提交于
A buggy or malicious guest could pass the id of an already opened fid and cause QEMU to abort. Let's return EINVAL to the guest instead. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Greg Kurz 提交于
The xattrcreate operation only makes sense on a freshly cloned fid actually, since any open state would be leaked because of the fid_type change. This is indeed what the linux kernel client does: fid = clone_fid(fid); [...] retval = p9_client_xattrcreate(fid, name, value_len, flags); This patch also reverts commit ff55e94d since we are sure that a fid with type P9_FID_NONE doesn't have a previously allocated xattr. Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
We shouldn't allow guests to create extended attribute with arbitrary sizes. On linux hosts, the limit is XATTR_SIZE_MAX. Let's use it. Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
The v9fs_xattr_read() and v9fs_xattr_write() are passed a guest originated offset: they must ensure this offset does not go beyond the size of the extended attribute that was set in v9fs_xattrcreate(). Unfortunately, the current code implement these checks with unsafe calculations on 32 and 64 bit values, which may allow a malicious guest to cause OOB access anyway. Fix this by comparing the offset and the xattr size, which are both uint64_t, before trying to compute the effective number of bytes to read or write. Suggested-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-By: NGuido Günther <agx@sigxcpu.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
Currently, 9pfs sets the 'copied_len' field in V9fsXattr to -1 to tag xattr walk fid. As the 'copied_len' is also used to account for copied bytes, this may make confusion. This patch add a bool 'xattrwalk_fid' to tag the xattr walk fid. Suggested-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
- 17 10月, 2016 10 次提交
-
-
由 Li Qiang 提交于
If an error occurs when marshalling the transfer length to the guest, the v9fs_write() function doesn't free an IO vector, thus leading to a memory leak. This patch fixes the issue. Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Reviewed-by: NGreg Kurz <groug@kaod.org> [groug, rephrased the changelog] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
The v9fs_link() function keeps a reference on the source fid object. This causes a memory leak since the reference never goes down to 0. This patch fixes the issue. Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Reviewed-by: NGreg Kurz <groug@kaod.org> [groug, rephrased the changelog] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
The 'fs.xattr.value' field in V9fsFidState object doesn't consider the situation that this field has been allocated previously. Every time, it will be allocated directly. This leads to a host memory leak issue if the client sends another Txattrcreate message with the same fid number before the fid from the previous time got clunked. Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Reviewed-by: NGreg Kurz <groug@kaod.org> [groug, updated the changelog to indicate how the leak can occur] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
9pfs uses g_malloc() to allocate the xattr memory space, if the guest reads this memory before writing to it, this will leak host heap memory to the guest. This patch avoid this. Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
Virtio devices should implement the VirtIODevice->reset() function to perform necessary cleanup actions and to bring the device to a quiescent state. In the case of the virtio-9p device, this means: - emptying the list of active PDUs (i.e. draining all in-flight I/O) - freeing all fids (i.e. close open file descriptors and free memory) That's what this patch does. The reset handler first waits for all active PDUs to complete. Since completion happens in the QEMU global aio context, we just have to loop around aio_poll() until the active list is empty. The freeing part involves some actions to be performed on the backend, like closing file descriptors or flushing extended attributes to the underlying filesystem. The virtfs_reset() function already does the job: it calls free_fid() for all open fids not involved in an ongoing I/O operation. We are sure this is the case since we have drained the PDU active list. The current code implements all backend accesses with coroutines, but we want to stay synchronous on the reset path. We can either change the current code to be able to run when not in coroutine context, or create a coroutine context and wait for virtfs_reset() to complete. This patch goes for the latter because it results in simpler code. Note that we also need to create a dummy PDU because it is also an API to pass the FsContext pointer to all backend callbacks. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Greg Kurz 提交于
If a PDU has a flush request pending, the current code calls pdu_free() twice: 1) pdu_complete()->pdu_free() with pdu->cancelled set, which does nothing 2) v9fs_flush()->pdu_free() with pdu->cancelled cleared, which moves the PDU back to the free list. This works but it complexifies the logic of pdu_free(). With this patch, pdu_complete() only calls pdu_free() if no flush request is pending, i.e. qemu_co_queue_next() returns false. Since pdu_free() is now supposed to be called with pdu->cancelled cleared, the check in pdu_free() is dropped and replaced by an assertion. Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
Out of the three users of pdu_free(), none ever passes a NULL pointer to this function. Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
All these functions either call the v9fs_co_* functions which have the coroutine_fn annotation, or pdu_complete() which calls qemu_co_queue_next(). Let's mark them to make it obvious they execute in coroutine context. Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
In 9pfs read dispatch function, it doesn't free two QEMUIOVector object thus causing potential memory leak. This patch avoid this. Signed-off-by: NLi Qiang <liqiang6-s@360.cn> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Li Qiang 提交于
If a guest sends an empty string paramater to any 9P operation, the current code unmarshals it into a V9fsString equal to { .size = 0, .data = NULL }. This is unfortunate because it can cause NULL pointer dereference to happen at various locations in the 9pfs code. And we don't want to check str->data everywhere we pass it to strcmp() or any other function which expects a dereferenceable pointer. This patch enforces the allocation of genuine C empty strings instead, so callers don't have to bother. Out of all v9fs_iov_vunmarshal() users, only v9fs_xattrwalk() checks if the returned string is empty. It now uses v9fs_string_size() since name.data cannot be NULL anymore. Signed-off-by: NLi Qiang <liqiang6-s@360.cn> [groug, rewritten title and changelog, fix empty string check in v9fs_xattrwalk()] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
- 19 9月, 2016 1 次提交
-
-
由 Greg Kurz 提交于
If the call to fid_to_qid() returns an error, we will call v9fs_path_free() on uninitialized paths. It is a regression introduced by the following commit: 56f101ec 9pfs: handle walk of ".." in the root directory Let's fix this by initializing dpath and path before calling fid_to_qid(). Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCédric Le Goater <clg@kaod.org> [groug: updated the changelog to indicate this is regression and to provide the offending commit SHA1] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
- 16 9月, 2016 2 次提交
-
-
由 Greg Kurz 提交于
This helper is similar to v9fs_string_sprintf(), but it includes the terminating NUL character in the size field. This is to avoid doing v9fs_string_sprintf((V9fsString *) &path) and then bumping the size. Affected users are changed to use this new helper. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCédric Le Goater <clg@kaod.org>
-
由 Greg Kurz 提交于
The v9fs_string_null() function just calls v9fs_string_free(). Also it only has 4 users, whereas v9fs_string_free() has 87. This patch converts users to call directly v9fs_string_free() and drops the useless function. Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NCédric Le Goater <clg@kaod.org>
-
- 31 8月, 2016 3 次提交
-
-
由 Greg Kurz 提交于
The 9P spec at http://man.cat-v.org/plan_9/5/intro says: All directories must support walks to the directory .. (dot-dot) meaning parent directory, although by convention directories contain no explicit entry for .. or . (dot). The parent of the root directory of a server's tree is itself. This means that a client cannot walk further than the root directory exported by the server. In other words, if the client wants to walk "/.." or "/foo/../..", the server should answer like the request was to walk "/". This patch just does that: - we cache the QID of the root directory at attach time - during the walk we compare the QID of each path component with the root QID to detect if we're in a "/.." situation - if so, we skip the current component and go to the next one Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Greg Kurz 提交于
According to the 9P spec http://man.cat-v.org/plan_9/5/open about the create request: The names . and .. are special; it is illegal to create files with these names. This patch causes the create and lcreate requests to fail with EINVAL if the file name is either "." or "..". Even if it isn't explicitly written in the spec, this patch extends the checking to all requests that may cause a directory entry to be created: - mknod - rename - renameat - mkdir - link - symlink The unlinkat request also gets patched for consistency (even if rmdir("foo/..") is expected to fail according to POSIX.1-2001). The various error values come from the linux manual pages. Suggested-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Greg Kurz 提交于
Empty path components don't make sense for most commands and may cause undefined behavior, depending on the backend. Also, the walk request described in the 9P spec [1] clearly shows that the client is supposed to send individual path components: the official linux client never sends portions of path containing the / character for example. Moreover, the 9P spec [2] also states that a system can decide to restrict the set of supported characters used in path components, with an explicit mention "to remove slashes from name components". This patch introduces a new name_is_illegal() helper that checks the names sent by the client are not empty and don't contain unwanted chars. Since 9pfs is only supported on linux hosts, only the / character is checked at the moment. When support for other hosts (AKA. win32) is added, other chars may need to be blacklisted as well. If a client sends an illegal path component, the request will fail and ENOENT is returned to the client. [1] http://man.cat-v.org/plan_9/5/walk [2] http://man.cat-v.org/plan_9/5/introSuggested-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 13 7月, 2016 1 次提交
-
-
由 Paolo Bonzini 提交于
In practice the entry argument is always known at creation time, and it is confusing that sometimes qemu_coroutine_enter is used with a non-NULL argument to re-enter a coroutine (this happens in block/sheepdog.c and tests/test-coroutine.c). So pass the opaque value at creation time, for consistency with e.g. aio_bh_new. Mostly done with the following semantic patch: @ entry1 @ expression entry, arg, co; @@ - co = qemu_coroutine_create(entry); + co = qemu_coroutine_create(entry, arg); ... - qemu_coroutine_enter(co, arg); + qemu_coroutine_enter(co); @ entry2 @ expression entry, arg; identifier co; @@ - Coroutine *co = qemu_coroutine_create(entry); + Coroutine *co = qemu_coroutine_create(entry, arg); ... - qemu_coroutine_enter(co, arg); + qemu_coroutine_enter(co); @ entry3 @ expression entry, arg; @@ - qemu_coroutine_enter(qemu_coroutine_create(entry), arg); + qemu_coroutine_enter(qemu_coroutine_create(entry, arg)); @ reentry @ expression co; @@ - qemu_coroutine_enter(co, NULL); + qemu_coroutine_enter(co); except for the aforementioned few places where the semantic patch stumbled (as expected) and for test_co_queue, which would otherwise produce an uninitialized variable warning. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
- 06 6月, 2016 3 次提交
-
-
由 Greg Kurz 提交于
This patch changes the 9p code to use readdir() again instead of readdir_r(), which is deprecated in glibc 2.24. All the locking was put in place by a previous patch. Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
If several threads concurrently call readdir() with the same directory stream pointer, it is possible that they all get a pointer to the same dirent structure, whose content is overwritten each time readdir() is called. We must thus serialize accesses to the dirent structure. This may be achieved with a mutex like below: lock_mutex(); readdir(); // work with the dirent unlock_mutex(); This patch adds all the locking, to prepare the switch to readdir(). Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
If we are to switch back to readdir(), we need a more complex type than DIR * to be able to serialize concurrent accesses to the directory stream. This patch introduces a placeholder type and fixes all users. Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
-