From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: io_uring vs in_compat_syscall() Date: Mon, 20 Jul 2020 11:02:19 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: Christoph Hellwig , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, io-uring-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-arch.vger.kernel.org On 7/20/20 10:58 AM, Andy Lutomirski wrote: > >> On Jul 20, 2020, at 9:37 AM, Jens Axboe wrote: >> >> On 7/20/20 12:10 AM, Christoph Hellwig wrote: >>> Hi Jens, >>> >>> I just found a (so far theoretical) issue with the io_uring submission >>> offloading to workqueues or threads. We have lots of places using >>> in_compat_syscall() to check if a syscall needs compat treatmenet. >>> While the biggest users is iocttl(), we also have a fair amount of >>> places using in_compat_task() in read and write methods, and these >>> will not do the wrong thing when used with io_uring under certain >>> conditions. I'm not sure how to best fix this, except for making sure >>> in_compat_syscall() returns true one way or another for these cases. >> >> We can probably propagate this information in the io_kiocb via a flag, >> and have the io-wq worker set TS_COMPAT if that's the case. >> > > Is TS_COMPAT actually a cross-arch concept for which this is safe? > Having a real arch helper for “set the current syscall arch for the > current kernel thread” seems more sensible to me. Sure, I'd consider that implementation detail for the actual patch(es) for this issue. -- Jens Axboe From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730579AbgGTRCW (ORCPT ); Mon, 20 Jul 2020 13:02:22 -0400 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 003B4C061794 for ; Mon, 20 Jul 2020 10:02:21 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id q3so13913541ilt.8 for ; Mon, 20 Jul 2020 10:02:21 -0700 (PDT) Subject: Re: io_uring vs in_compat_syscall() References: From: Jens Axboe Message-ID: Date: Mon, 20 Jul 2020 11:02:19 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Christoph Hellwig , linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org Message-ID: <20200720170219.UsdjmZaAAC5xBtWyVDDrQ7v_IuIrMAKBPeNX9OD9V8o@z> On 7/20/20 10:58 AM, Andy Lutomirski wrote: > >> On Jul 20, 2020, at 9:37 AM, Jens Axboe wrote: >> >> On 7/20/20 12:10 AM, Christoph Hellwig wrote: >>> Hi Jens, >>> >>> I just found a (so far theoretical) issue with the io_uring submission >>> offloading to workqueues or threads. We have lots of places using >>> in_compat_syscall() to check if a syscall needs compat treatmenet. >>> While the biggest users is iocttl(), we also have a fair amount of >>> places using in_compat_task() in read and write methods, and these >>> will not do the wrong thing when used with io_uring under certain >>> conditions. I'm not sure how to best fix this, except for making sure >>> in_compat_syscall() returns true one way or another for these cases. >> >> We can probably propagate this information in the io_kiocb via a flag, >> and have the io-wq worker set TS_COMPAT if that's the case. >> > > Is TS_COMPAT actually a cross-arch concept for which this is safe? > Having a real arch helper for “set the current syscall arch for the > current kernel thread” seems more sensible to me. Sure, I'd consider that implementation detail for the actual patch(es) for this issue. -- Jens Axboe