Considering the (changed) source-code of fs/9p/vfs_file.c::v9fs_file_read_iter() in commit 80105ed2fd2715fb09a8fdb0655a8bdc86c120db.
Prior to the commit there was a code path specifically for O_NONBLOCK (as well as for p9L_DIRECT). Now there is only a code-path for P9L_DIRECT.
kernel.36.log shows that within this function the p9L_DIRECT path is taken since there is no debug message from the final debug message:
if (fid->mode & P9L_DIRECT) return netfs_unbuffered_read_iter(iocb, to);
p9_debug(P9_DEBUG_VFS, "(cached)\n"); return netfs_file_read_iter(iocb, to); }
I'm not familiar enough with the netfs layer to understand if O_NONBLOCK is being handled (correctly) there - if special handling is indeed required?
Considering the (changed) source-code of fs/9p/vfs_ file.c: :v9fs_file_ read_iter( ) in commit 80105ed2fd2715f b09a8fdb0655a8b dc86c120db.
Prior to the commit there was a code path specifically for O_NONBLOCK (as well as for p9L_DIRECT). Now there is only a code-path for P9L_DIRECT.
kernel.36.log shows that within this function the p9L_DIRECT path is taken since there is no debug message from the final debug message:
if (fid->mode & P9L_DIRECT)
return netfs_unbuffere d_read_ iter(iocb, to);
return netfs_file_
}
I'm not familiar enough with the netfs layer to understand if O_NONBLOCK is being handled (correctly) there - if special handling is indeed required?