Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp67784ybh; Mon, 20 Jul 2020 10:29:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwM/RR23qkuZH3of+T8F6rce0R6q2nztmVDQU3tzN2sakoFfhvb/v4CPWWbRsqVjl1lvwEN X-Received: by 2002:a17:906:2b0e:: with SMTP id a14mr21116908ejg.459.1595266182228; Mon, 20 Jul 2020 10:29:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595266182; cv=none; d=google.com; s=arc-20160816; b=OpdT+417CtqmA5ekV3VFfp/IEyU0btH1r3f0pG5zuXzl+q2rkul4PVkX4pahl5HQCJ laE+4q+jKejG2lwW/T47NhUG3ZzrGiY5oaEm4inu2c6lpvJpDJsEOLACCz0V8IAvx0vn fkNDMNgFNZakobspIrvLaGKXeOlRO6mPqHSfdIApWREpaymsFJtFE0UkuWiorxFmiPib 16/Ez87p36rnqzOwzw5TGCCtilc9LdPM382Nk+hDrvTTjQtwKcUvvyWyYcM1Xcxm66Pu WS3aVW8AZZBduR39pZCEFoiIZ+KqJ8JOSMA4k/ELrfn4MTCyEzBNAvVe7EjJxVRqp7Rc 47pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:in-reply-to:cc:references:message-id :date:subject:mime-version:from:content-transfer-encoding :dkim-signature; bh=xHiR/oaIUa5pbgNSUHGq5QFpcwnJQsNkMFGVCEqO8so=; b=XTdMclY14TdsR1OrqdzP630LLBamG5JDoUGbYSAES9SpAIE5KE77jlcb9uxAHx+Bpp MuQHa+6219OOOE7zw4Ae+hGlscbJbbm9jBSiW4vfbYbC4VwNj4RgV6WXUmFiAiBirad3 kWSfyME9qQe6ERcOkYOBDoBJPk+iEHrCShnKlHolcTzQ0dNcSy7HPU7ahPQVtAgJTYyv VwINxxQXuExGTRNe6jY0jyDWULt5SkJzY2i16fUDrrNxbIaGRBmmnhxQyxZH42u7FkU2 QP9QTdCxahKbUEgqydA4P9jDspIh144CpGnwd5rMjiITXhdvpRCNytMK6RZ0D3X0kpZg EXMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=a1MsoLna; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw22si10279823ejb.61.2020.07.20.10.29.18; Mon, 20 Jul 2020 10:29:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=a1MsoLna; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728939AbgGTR27 (ORCPT + 99 others); Mon, 20 Jul 2020 13:28:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729307AbgGTR26 (ORCPT ); Mon, 20 Jul 2020 13:28:58 -0400 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33774C0619D4 for ; Mon, 20 Jul 2020 10:28:58 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id e8so10593100pgc.5 for ; Mon, 20 Jul 2020 10:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=xHiR/oaIUa5pbgNSUHGq5QFpcwnJQsNkMFGVCEqO8so=; b=a1MsoLnahfulhQyk3sQsJrIU0k/+OszU3zBP0cJH82Ram+mo+waJkr1NTjIeMwkiqn ed9V1qkSCCh7AMcPedy3Ec5w+9GPs5vum5IXSsQiRy0zdzFN2oktRwyJ9S6bOkASAJHQ J5kbITP0bxBBJHKljVCnY5OzhNgXH3IUG8QTLjr5GGwIPYblTMvorMwFOZKX3pQptQuD Z9cwzEtJcIoupOadWfvGjTH/UfcgqbRTo4EUQvX/KTyygXaGUF9ELU2D7595CYK/IHW7 bgV+8Btko85b47omINODDlL7L+UfFa38WNmSs01PM2yzgR9sl/M5bNlUXAtUa4NsGF1y Pzjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=xHiR/oaIUa5pbgNSUHGq5QFpcwnJQsNkMFGVCEqO8so=; b=i9Rzxkn2DXHqYVP3hfOTCakx/ugAonpFrmFFTBBdcAZ/HyZxOlGRX4oXh+w5iao8Yg ezqiZ9dXNRpqZo2ZCJEeHl0/JNE/FnWUzzD0X1L5FpVkCHkPoGOrfIGz3uIQmOeUqUus IOsyx8RJwGfYASTgqu52Fl7XnoC7Mf3lyHSpwgl2Z9OvSZ/km72F40xjO+qzl+Z/N8aD T2BthLpI0B7BwMlZXkAYvaxH8hFAeapY8dpvP29sUCI7fCq6RTRjWAoFSNNijengLZ8M AGRp515J38MDkyQbL8zow6Vw2ux+PsmX6pzOeulYigAHPI8AofdKPHxKX/ooUZpFKIth 3yVQ== X-Gm-Message-State: AOAM530rWXxcmKh21zt+kF7hTU373tAoLvfueyrA5MWt0CpLQCXXIMGT RQ/RbSiY38COrmoyQ5XuwxSWIg== X-Received: by 2002:a62:3744:: with SMTP id e65mr21637646pfa.20.1595266137524; Mon, 20 Jul 2020 10:28:57 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:600f:2f5b:3d86:4df5? ([2601:646:c200:1ef2:600f:2f5b:3d86:4df5]) by smtp.gmail.com with ESMTPSA id ji2sm189425pjb.1.2020.07.20.10.28.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2020 10:28:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: io_uring vs in_compat_syscall() Date: Mon, 20 Jul 2020 10:28:55 -0700 Message-Id: <8987E376-6B13-4798-BDBA-616A457447CF@amacapital.net> References: Cc: Christoph Hellwig , linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org In-Reply-To: To: Jens Axboe X-Mailer: iPhone Mail (17F80) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jul 20, 2020, at 10:02 AM, Jens Axboe wrote: >=20 > =EF=BB=BFOn 7/20/20 10:58 AM, Andy Lutomirski wrote: >>=20 >>>> On Jul 20, 2020, at 9:37 AM, Jens Axboe wrote: >>>=20 >>> =EF=BB=BFOn 7/20/20 12:10 AM, Christoph Hellwig wrote: >>>> Hi Jens, >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> Is TS_COMPAT actually a cross-arch concept for which this is safe? >> Having a real arch helper for =E2=80=9Cset the current syscall arch for t= he >> current kernel thread=E2=80=9D seems more sensible to me.=20 >=20 > Sure, I'd consider that implementation detail for the actual patch(es) > for this issue. There=E2=80=99s a corner case, though: doesn=E2=80=99t io_uring submission f= requently do the work synchronously in the context of the calling thread? I= f so, can a thread do a 64-bit submit with 32-bit work or vice versa? Sometimes I think that in_compat_syscall() should have a mode in which calli= ng it warns (e.g. not actually in a syscall when doing things in io_uring). = And the relevant operations should be properly wired up to avoid global sta= te like this. >=20 > --=20 > Jens Axboe >=20