[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200722063050.GA24968@lst.de>
Date: Wed, 22 Jul 2020 08:30:50 +0200
From: Christoph Hellwig <hch@....de>
To: Andy Lutomirski <luto@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
linux-arch <linux-arch@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, io-uring@...r.kernel.org
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@....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.
Powered by blists - more mailing lists