, the call to close() on the fd in v9fs_post_lcreate()
fails and sets errno to EBADF. We should preserve the errno that we got from
open() and we should call close() only if we had a valid fd.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c |4 +++-
1 files changed, 3 insertions
in summary:
Mask out:
O_NOCTTY
O_ASYNC
O_CREAT
Pass-through:
O_NONBLOCK
O_CLOEXEC
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 29fc648..7f659b8 100644
with a controlling terminal, so calling open with
O_NOCTTY flag is not going to make any difference to QEMU.
The following patch makes 9P server allow O_NOCTTY flag in open().
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions
-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p-debug.c | 26 +++
hw/virtio-9p-debug.h |1
hw/virtio-9p.c | 119
+++
3 files changed, 63 insertions(+), 83 deletions(-)
Index: qemu/hw/virtio-9p-debug.h
, st_gen,
st_data_version apart from the bitmask, st_result_mask.
Signed-off-by: M. Mohan Kumar mo...@in.ibm.com
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p-debug.c | 32 ++
hw/virtio-9p.c | 112
Hi Stefan, Prerna,
I pulled down QEMU tracing code from git://repo.or.cz/qemu/stefanha.git
and tried to use it to trace something in virtio-9p code. I don't have
any knowledge of how traces are implemented and I just went with the
documentation. With help from Prerna, I was able to insert a trace
On Thu, 01 Jul 2010 11:01:15 +0530
Aneesh Kumar K. V aneesh.ku...@linux.vnet.ibm.com wrote:
On Fri, 28 May 2010 16:08:43 +0530, Sripathi Kodi sripat...@in.ibm.com
wrote:
From: M. Mohan Kumar mo...@in.ibm.com
SYNOPSIS
size[4] Tgetattr tag[2] fid[4]
size[4] Rgetattr
this
error. With this patch we get an abort message like the following, which makes
it easier to analyze:
f12-kvm login: qemu:
/data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-9p-debug.c:353:
pprint_pdu: Assertion `!(!llogfile)' failed.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw
On Wed, 30 Jun 2010 10:15:29 +0530
Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com wrote:
The arguments are wrong. Use qemu_mallocz directly
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Reviewed-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c |3 +--
1
On Sat, 05 Jun 2010 19:11:53 +0530
Aneesh Kumar K. V aneesh.ku...@linux.vnet.ibm.com wrote:
On Fri, 04 Jun 2010 07:59:42 -0700, Venkateswararao Jujjuri (JV)
jv...@linux.vnet.ibm.com wrote:
Aneesh Kumar K. V wrote:
On Thu, 3 Jun 2010 18:29:02 +0530, Sripathi Kodi sripat...@in.ibm.com
On Mon, 7 Jun 2010 16:04:17 +0530
Sripathi Kodi sripat...@in.ibm.com wrote:
There was one mistake in my patch. See below.
On Sat, 05 Jun 2010 19:11:53 +0530
Aneesh Kumar K. V aneesh.ku...@linux.vnet.ibm.com wrote:
On Fri, 04 Jun 2010 07:59:42 -0700, Venkateswararao Jujjuri (JV)
jv
On Tue, 1 Jun 2010 19:47:14 +0530
M. Mohan Kumar mo...@in.ibm.com wrote:
Compute iounit based on the host filesystem block size and pass it to
client with open/create response. Also return iounit as statfs's f_bsize
for optimal block size transfers.
Signed-off-by: M. Mohan Kumar
On Tue, 1 Jun 2010 19:47:49 +0530
M. Mohan Kumar mo...@in.ibm.com wrote:
Change the v9fs_file_readn function to limit the maximum transfer size
based on the iounit instead of msize.
Also remove the redundant check for limiting the transfer size in
v9fs_file_write. This check is done by
.
For example, doing 'ls /dev/null' on a directory with 1 files on my
laptop takes 1.088 seconds with the existing code, but only takes 0.339
seconds
with the new readdir.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku
for the file
offset[8]
offset into the next dirent.
type[1]
type of this directory entry.
name[256]
name of this directory entry.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Reviewed-by: M. Mohan Kumar mo
.
For example, doing 'ls /dev/null' on a directory with 1 files on my
laptop takes 1.088 seconds with the existing code, but only takes 0.339
seconds
with the new readdir.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku
.
For example, doing 'ls /dev/null' on a directory with 1 files on my
laptop takes 1.088 seconds with the existing code, but only takes 0.339
seconds
with the new readdir.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku
timespec[2] and pass it
down to the system directly. This will make it more generic and useful
elsewhere.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c | 37 ++---
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/hw/virtio
this is not needed.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c | 137
hw/virtio-9p.h | 23 +
2 files changed, 160 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 8c1cdfb
.
With this patch we ignore the error from free_fid(). The client cannot
use this error value anyway.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index e5d0112
remove().
Currently the client falsely thinks that the remove call has always
succeeded. For example, doing rmdir on a non-empty directory does
not return ENOTEMPTY.
With this patch we ignore the error from free_fid(). The client cannot
use this error value anyway.
Signed-off-by: Sripathi Kodi
-by: Sripathi Kodi sripat...@in.ibm.com
---
hw/virtio-9p-debug.c | 32
hw/virtio-9p.c | 82 ++
hw/virtio-9p.h | 28 +
3 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p-debug.c
entry.
name[256]
name of this directory entry.
Signed-off-by: Sripathi Kodi sripat...@in.ibm.com
Reviewed-by: M. Mohan Kumar mo...@in.ibm.com
Reviewed-by: Venkateswararao Jujjuri jv...@linux.vnet.ibm.com
---
hw/virtio-9p-debug.c | 13 ++
hw/virtio-9p.c | 110
On Fri, 21 May 2010 14:26:05 -0700
Venkateswararao Jujjuri (JV) jv...@linux.vnet.ibm.com wrote:
Hi JV,
While I agree that this patch is nice to have, why is this part of the
security model patchset? Is it required to implement the models?
Thanks,
Sripathi.
Signed-off-by: Venkateswararao
24 matches
Mail list logo
