Messages in this thread | | | Date | Wed, 22 Jul 2020 08:30:50 +0200 | From | Christoph Hellwig <> | Subject | Re: io_uring vs in_compat_syscall() |
| |
On Tue, Jul 21, 2020 at 10:25:24AM -0700, Andy Lutomirski wrote: > On Tue, Jul 21, 2020 at 7:34 AM Christoph Hellwig <hch@lst.de> wrote: > > > > On Tue, Jul 21, 2020 at 07:31:02AM -0700, Andy Lutomirski wrote: > > > > What do you mean with "properly wired up". Do you really want to spread > > > > ->compat_foo methods everywhere, including read and write? I found > > > > in_compat_syscall() a lot small and easier to maintain than all the > > > > separate compat cruft. > > > > > > I was imagining using a flag. Some of the net code uses > > > MSG_CMSG_COMPAT for this purpose. > > > > Killing that nightmarish monster is what actually got me into looking > > io_uring and starting this thread. > > I agree that MSG_CMSG_COMPAT is nasty, but I think the concept is > sound -- rather than tracking whether we're compat by using a > different function or a per-thread variable, actually explicitly > tracking the mode seems sensible.
I very strongly disagree. Two recent projects I did was to remove the compat_exec mess, and the compat get/setsockopt mess, and each time it removed hundreds of lines of code duplicating native functionality, often in slightly broken ways. We need a generic out of band way to transfer the information down and just check in in a few strategic places, and in_compat_syscall() does the right thing for that.
> If we're going to play in_compat_syscall() games, let's please make > io_uring_enter() return -EINVAL if in_compat_syscall() != ctx->compat.
That sounds like a plan, but still doesn't help with submissions from the offload WQ or the sqpoll thread.
| |