On 12/3/24 13:49, Bernd Schubert wrote:
On 12/3/24 14:24, Pavel Begunkov wrote:
On 11/27/24 13:40, Bernd Schubert wrote:
This adds basic support for ring SQEs (with opcode=IORING_OP_URING_CMD).
For now only FUSE_URING_REQ_FETCH is handled to register queue entries.
...
+ /*
+ * Direction for buffer access will actually be READ and WRITE,
+ * using write for the import should include READ access as well.
+ */
+ ret = import_iovec(WRITE, uiov, FUSE_URING_IOV_SEGS,
+ FUSE_URING_IOV_SEGS, &iov, &iter);
You're throwing away the iterator, I'd be a bit cautious about it.
FUSE_URING_IOV_SEGS is 2, so it should avoid ITER_UBUF, but Jens
can say if it's abuse of the API or not.
Fwiw, it's not the first place I know of that just want to get
an iovec avoiding playing games with different iterator modes.
Shall I create new exported function like import_iovec_from_user()
that duplicates all the parts from __import_iovec()? I could also
let __import_iovec() use that new function, although there will be
less inlining with -02.
I'd say we can just leave it as is for now and deal later. That is
unless someone complains.
+int fuse_uring_cmd(struct io_uring_cmd *cmd, unsigned int issue_flags)
+{
+ struct fuse_dev *fud;
+ struct fuse_conn *fc;
+ u32 cmd_op = cmd->cmd_op;
+ int err;
+
+ /* Disabled for now, especially as teardown is not implemented
yet */
+ pr_info_ratelimited("fuse-io-uring is not enabled yet\n");
+ return -EOPNOTSUPP;
Do compilers give warnings about such things? Unreachable code, maybe.
I don't care much, but if they do to avoid breaking CONFIG_WERROR you
might want to do sth about it. E.g. I'd usually mark the function
__maybe_unused and not set it into fops until a later patch.
I don't get any warning, but I can also do what you suggest.
Got it, no preference then.
--
Pavel Begunkov
