A proper way to handle O_NONBLOCK would be making the requests and
responses happen asynchronously, but this would require serious code
refactoring.
Signed-off-by: Sergey Alirzaev <[email protected]>
---
fs/9p/vfs_file.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
index fe7f0bd2048e..92cd1d80218d 100644
--- a/fs/9p/vfs_file.c
+++ b/fs/9p/vfs_file.c
@@ -388,7 +388,10 @@ v9fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
p9_debug(P9_DEBUG_VFS, "count %zu offset %lld\n",
iov_iter_count(to), iocb->ki_pos);
- ret = p9_client_read(fid, iocb->ki_pos, to, &err);
+ if (iocb->ki_filp->f_flags & O_NONBLOCK)
+ ret = p9_client_read_once(fid, iocb->ki_pos, to, &err);
+ else
+ ret = p9_client_read(fid, iocb->ki_pos, to, &err);
if (!ret)
return err;
--
2.25.0
Sergey Alirzaev wrote on Wed, Feb 05, 2020:
> A proper way to handle O_NONBLOCK would be making the requests and
> responses happen asynchronously, but this would require serious code
> refactoring.
FWIW I do have some async 9p code waiting (it's been sent to the list
ages ago but I never took the time to properly test it due to lack of
interest manifested), the problem here is more the caching model than a
synchronous issue, since in nocache mode (where this is used) there is
nowhere to fetch the data ahead of time.
If you're interested in that then please have a look at
https://lore.kernel.org/lkml/[email protected]/
> Signed-off-by: Sergey Alirzaev <[email protected]>
That aside, I guess, why not?
Will take when other patch gets addressed.
Thanks,
--
Dominique