When client has multiple threads that issue io requests
all the time, and the server has a very good performance,
it may cause cpu is running in the irq context for a long
time because it can check virtqueue has buf in the *while*
loop.
So we should keep chan->lock in the whole loop.
Signed-off-b
On 2018/7/23 20:19, Tomas Bortoli wrote:
> A double list_del(&req->req_list) is possible in p9_fd_cancel() as
> shown by Syzbot. To prevent it we have to ensure that we have the
> client->lock when deleting the list. Furthermore, we have to update
> the status of the request before releasing the lo
On 2018/7/12 5:02, Matthew Wilcox wrote:
> Return NULL instead of ERR_PTR when we can't allocate a FID. The ENOSPC
> return value was getting all the way back to userspace, and that's
> confusing for a userspace program which isn't expecting read() to tell it
> there's no space left on the filesys
On 2018/7/12 5:02, Matthew Wilcox wrote:
> The p9_idpool being used to allocate the IDs uses an IDR to allocate
> the IDs ... which we then keep in a doubly-linked list, rather than in
> the IDR which allocated them. We can use an IDR directly which saves
> two pointers per p9_fid, and a tiny memo
When client has multiple threads that issue io requests all the
time, and the server has a very good performance, it may cause
cpu is running in the irq context for a long time because it can
check virtqueue has buf in the *while* loop.
So we should keep chan->lock in the whole loop.
Signed-off-b
On 2018/7/14 17:05, Dominique Martinet wrote:
> jiangyiwen wrote on Sat, Jul 14, 2018:
>> When client has multiple threads that issue io requests all the
>> time, and the server has a very good performance, it may cause
>> cpu is running in the irq context for a long time be
On 2018/7/14 20:47, Dominique Martinet wrote:
> jiangyiwen wrote on Sat, Jul 14, 2018:
>> On 2018/7/14 17:05, Dominique Martinet wrote:
>>> jiangyiwen wrote on Sat, Jul 14, 2018:
>>>> When client has multiple threads that issue io requests all the
>>>
On 2018/3/10 4:41, Greg Kurz wrote:
> If it was interrupted by a signal, the 9p client may need to send some
> more requests to the server for cleanup before returning to userspace.
>
> To avoid such a last minute request to be interrupted right away, the
> client memorizes if a signal is pending,
User use some syscall, for example mmap(v9fs_file_mmap), it will not
update atime even if user's mnt_flags without MNT_NOATIME, because
v9fs default set SB_NOATIME in v9fs_set_super.
For supporting access time is updated when user mount with relatime,
we should not set SB_NOATIME by default.
Sign
On 2018/7/10 14:56, piaojun wrote:
> In p9_client_getattr_dotl(), we should add '\n' at the end of printing
> log.
>
> Signed-off-by: Jun Piao
Reviewed-by: Yiwen Jiang
> ---
> net/9p/client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/9p/client.c b/net/9p/cl
On 2018/7/11 8:43, piaojun wrote:
> We should return -ENOMEM to upper user when kmalloc failed to indicate
> accurate errno.
>
> Signed-off-by: Jun Piao
Reviewed-by: Yiwen Jiang
> ---
> net/9p/protocol.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/9p/protocol
On 2018/7/10 3:26, Tomas Bortoli wrote:
> The pdu_read() function suffers from an integer underflow.
> When pdu->offset is greater than pdu->size, the length calculation will have
> a wrong result, resulting in an out-of-bound read.
> This patch modifies also pdu_write() in the same way to prevent
On 2018/7/6 17:42, piaojun wrote:
>>From my test, the second mount will fail after umounting successfully.
> The reason is that we put refcount of trans_mod in the correct case rather
> than the error case in parse_opts() at last. That will cause the refcount
> decrease to -1, and when we try to ge
On 2018/7/16 21:38, Dominique Martinet wrote:
> jiangyiwen wrote on Mon, Jul 16, 2018:
>> You're right, this wake up operation should be put after the unlocking,
>> I will resend it. In addition, whether I should resend this patch based
>> on your 9p-next branch?
>
When client has multiple threads that issue io requests
all the time, and the server has a very good performance,
it may cause cpu is running in the irq context for a long
time because it can check virtqueue has buf in the *while*
loop.
So we should keep chan->lock in the whole loop.
Signed-off-b
correct.
>
Hi Dominique,
If cpu is running in the irq context for a long time,
NMI watchdog will detect the hard lockup in the cpu,
and then it will cause kernel panic. So I use this
subject to underline the scenario.
> jiangyiwen wrote on Tue, Jul 17, 2018:
>> When client has multipl
On 2018/7/17 21:07, Dominique Martinet wrote:
> jiangyiwen wrote on Tue, Jul 17, 2018:
>> On 2018/7/17 19:42, Dominique Martinet wrote:
>>>
>>>> Subject: net/9p: Fix a deadlock case in the virtio transport
>>>
>>> I hadn't noticed in the v1,
On 2018/3/28 7:15, Andrew Morton wrote:
> On Tue, 27 Mar 2018 09:50:47 +0800 jiangyiwen wrote:
>
>> User use some syscall, for example mmap(v9fs_file_mmap), it will not
>> update atime even if user's mnt_flags without MNT_NOATIME, because
>> v9fs default set
Hi everyone,
Currently, I found virtio-9p in VirtFS don't support "O_DIRECT + aio"
mode, both v9fs and qemu. So when user use "O_DIRECT + aio" mode and
increase iodepths, they can't get higher IOPS.
I want to know why v9fs don't implement this mode? And I will try to
implement this mode from now
commit 8af1954d172a("blkdev: Do not return -EOPNOTSUPP if discard
is supported") only solve the situation of discard, because When
applications issue a discard request to device, they can't expect
deterministic behaviour. However, WRITE SAME should not ignore error
with EOPNOTSUPP, because if appli
User use some syscall, for example mmap(v9fs_file_mmap), it will not
update atime even if user's mnt_flags have MNT_NOATIME, because
v9fs default set SB_NOATIME in v9fs_set_super.
For supporting access time is updated when user mount with relatime,
we should clear SB_NOATIME by default.
Signed-of
Hi Eric and Greg,
I encountered the similar problem with create-unlink-getattr idiom.
I use the testcase that create-unlink-setattr idiom, and I see the
bug is reported at https://bugs.launchpad.net/qemu/+bug/1336794.
Then I also see you already fix the issue and push the patch to upstream.
https:
On 2018/2/9 19:33, Greg Kurz wrote:
> On Fri, 9 Feb 2018 15:10:46 +0800
> jiangyiwen wrote:
>
>> Hi Eric and Greg,
>>
>> I encountered the similar problem with create-unlink-getattr idiom.
>> I use the testcase that create-unlink-setattr idiom, and I se
On 2018/2/9 14:13, jiangyiwen wrote:
> User use some syscall, for example mmap(v9fs_file_mmap), it will not
> update atime even if user's mnt_flags have MNT_NOATIME, because
> v9fs default set SB_NOATIME in v9fs_set_super.
>
> For supporting access time is updated when user
On 2018/2/24 10:47, jiangyiwen wrote:
> On 2018/2/9 14:13, jiangyiwen wrote:
>> User use some syscall, for example mmap(v9fs_file_mmap), it will not
>> update atime even if user's mnt_flags have MNT_NOATIME, because
>> v9fs default set SB_NOATIME in v9fs_set_super.
>&g
Hi all,
I found v9fs always set SB_NOATIME into sb->s_flags in v9fs_fill_super,
even if user use mount option relatime, I am very curious about this
thing, can anyone tell me?
Thanks,
Yiwen Jiang.
Hi Al,
I totally agree the Greg's suggestion, I think v9fs is the direction
as the VirtFS in the virtualization field, that it still deserves to
be used and developed, so I also suggestion you can apply (or nack)
the patch as v9fs maintainer, I hope you won't refuse.
Thanks,
Yiwen.
On 2018/2/21
Hi all,
I test a scenario that will cause the difference of inode blocks
between client and host, the scenario as follows:
Precondition:
1) use VirtFS(virtio-9p) to connect guest and host.
2) 9p dir in guest is /mnt/9p, host is /9p-host.
3) server fs is ext4 and block size is 4096.
Test steps:
1
28 matches
Mail list logo
