Re: [PATCH 05/18] Add io_uring IO interface

quoted

quoted

On Jan 28, 2019, at 5:20 PM, Jens Axboe [off-list ref] wrote:

On 1/28/19 5:47 PM, Andy Lutomirski wrote:
On Mon, Jan 28, 2019 at 6:57 AM Christoph Hellwig [off-list ref] wrote:

[please make sure linux-api and linux-man are CCed on new syscalls
so that we get API experts to review them]

quoted

quoted

+static int io_import_iovec(struct io_ring_ctx *ctx, int rw,
+                        const struct io_uring_sqe *sqe,
+                        struct iovec **iovec, struct iov_iter *iter)
+{
+     void __user *buf = u64_to_user_ptr(sqe->addr);
+
+#ifdef CONFIG_COMPAT
+     if (ctx->compat)
+             return compat_import_iovec(rw, buf, sqe->len, UIO_FASTIOV,
+                                             iovec, iter);
+#endif

I think we can just check in_compat_syscall() here, which means we
can kill the ->compat member, and the separate compat version of the
setup syscall.

Since this whole API is new, I don't suppose you could introduce a
struct iovec64 or similar and just make the ABI be identical for
64-bit and 32-bit code?

Sure, that would be straight forward. Is there a strong reason to do
so outside of "that would be nice"? It's not like it's a huge amount
of code.

Here are some minor-ish benefits:

 - It avoids having a code path that is only used with 32 bit code on
64 bit kernels and is therefore rarely tested.  (In this particular
case, the code path doesn't diverge much, but for most compat
syscalls, it's almost an entirely separate implementation of the main
syscall code.)

 - It makes life easier for tools like strace.

 - It minimizes the chance of making a giant mess on x32, which isn't
really native or compat.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>