Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3758434pxk; Tue, 22 Sep 2020 01:32:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVPd6VBuc03HNNCDQcEw+3967qtjRIoNgoo+cDtFCjVt5IhsGQoXG/wajg1SlKsFyLq1eM X-Received: by 2002:aa7:cd06:: with SMTP id b6mr2677690edw.196.1600763568665; Tue, 22 Sep 2020 01:32:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600763568; cv=none; d=google.com; s=arc-20160816; b=0N3bAZ32IkvqKlVJsigp2M/rViVzB2AebJUti/GnQT6BdNRFv13sBZqDnJjWoRkkQj pvLO99ta/lMnnpeS950lcEOhVR3wiyln+HgEdG0B8g4Wx39V71yqqUyqNcaEstWDGX3K 1EVpeRI8w6Bgtde69Br0tV7A4pSczUtok93RlCnQzeEI6JzXbvS2PT7ZwyPayAsHIeid ej12CszmdzLG3Uiwm28RJxtbWZW+d3a1rdlR8djqegzoPot+vxOZsaihPsfP9uz2VBAa SbEzGRClzrzRYATME1gCweq4VrbxZ1OmBxR3cBKMUZOEMU8Co+lfYCtX3bX1wB3zQU/x mKWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=V3iS/PUscLWwct4FEqbcensqudg/HeTan6lpaqXThSM=; b=xD0YCymewr43MXOV13jBpbW0ihQ4eSYTgG0PRS7Pgvy9deyIH8bTym6/QhJ0KBA1To R5ossMXEeLu4tYTzeuzzC6W9huYNFG8sR4/gp4bVhqG5uOBj/AcVbS3ERzT4R+RQss6W 5U1yqr98rN4bBiMqYD2xV/uKQagWwvUza7qO7WLebODSTAwI9TX7SC0otAxLROwHB+Pv Ca7IXjMf12LLEdeELvF7BZ9FoW4Bfh/3tgwn+9HyE/ALbOHbquLkGWQxljwhFEfBbJ6A OB/Qd3FQ2Y7EQmhg6ShlVTZuS2iUicsUw1voarkwdSYFQcGdLPptEXjBvWvoRm27SI22 z3Ww== ARC-Authentication-Results: i=1; mx.google.com; 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 g1si7342924ejf.109.2020.09.22.01.32.25; Tue, 22 Sep 2020 01:32:48 -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; 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 S1729902AbgIVHYA (ORCPT + 99 others); Tue, 22 Sep 2020 03:24:00 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:49235 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729735AbgIVHX7 (ORCPT ); Tue, 22 Sep 2020 03:23:59 -0400 Received: from mail-qv1-f46.google.com ([209.85.219.46]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MgzWP-1kwjIH0sNp-00hNUS; Tue, 22 Sep 2020 09:23:56 +0200 Received: by mail-qv1-f46.google.com with SMTP id cy2so9001474qvb.0; Tue, 22 Sep 2020 00:23:54 -0700 (PDT) X-Gm-Message-State: AOAM530Ji4p6SqJlsqlAIhXa/mehEohMOm/qYFKdMQf1jU7KsXMjThoF zhEaydElHAkD1HY8suM9/IFXSKaiuthCjdj0j8g= X-Received: by 2002:ad4:4594:: with SMTP id x20mr4471122qvu.4.1600759433835; Tue, 22 Sep 2020 00:23:53 -0700 (PDT) MIME-Version: 1.0 References: <563138b5-7073-74bc-f0c5-b2bad6277e87@gmail.com> <486c92d0-0f2e-bd61-1ab8-302524af5e08@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Tue, 22 Sep 2020 09:23:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag To: Pavel Begunkov Cc: Andy Lutomirski , Christoph Hellwig , Al Viro , Andrew Morton , Jens Axboe , David Howells , linux-arm-kernel , X86 ML , LKML , "open list:MIPS" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , Linux SCSI List , Linux FS Devel , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Network Development , keyrings@vger.kernel.org, LSM List Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:AjHYUanKdOfbecE9w+B9Z4N6BZ2b/6C3GC/ZT1GJo80TVMT1TiT B7v2YHekGwErZe59Y8I5SN6nA+wzRAtAzQV1alKD4cIBzMUtp+uCtDl7yXziqEx66eHXl+8 5YaL/7KLJywdo7o6ruzdrm03FhbTCMOpxp+6Gjsv8I+DI1w9YYa5HKbByc2HjGMgB5rmpQw GI2KocTAr9puH1Zbmwgvw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:9U7HyB6Ug10=:7VkgnZRSuXPXxCph3JiICU vGLCkcH/ucwoA0af9e3nwxzDrSU4qHHl5LbVNZE9fwRlf3BxRnIxChhoUWY/pbGK9kbUMnPn6 iOxC7987sYhrLc/wR5FOOl9AmSFlJBCSkq0ECTVJJpJ1zAxFuSujqohHO71ms6fcLmkaP+68S a0y2dx03p+yQJTxCFfxZOllLfzHK80WYos1HroZHejUrF2/VDsLfCxxtFN6y520PH/aUVeNvX l/r1mWP7DXSVu7yUeClrfFvYtyE6idWsIDiC+H5wv241L9aUyE9A1wYt26cS3oRTT1aDX3vMZ lF5PgAd9+uS16D5p+mk7jnRYYYSNrgwHLffuwCYE2JUBFqA2ujr4MluvOT2GRH9b6unq2dzUt 517RcTi/d6VNGTxLnkFU+xqDBgZ1yVXhchRfVaiepT1jCj8BgkHRkV9OoGDBdyP1nmyz0sll2 VQ2xFLSS96OSw2POSPIhQsLbgTDcNO1bJhekhO3rGilcenA0dj9a+7SWVb/8O+ZUaB/SmF73C H3ua4oRbYBwYWG4ccj0SutXeHYh6UzX5exeOaMAbrFEBOHq90MPJxZr9OpBKopwpfZg7TSiRi zSapc09tG64gvk/y30gK+i9n1y1+Z0hVsj881DVR15Z8IRzOaiwsXHPRYtDWn/5Id1OXfXYUM GQLtid6DrtgYOV0t1yQLdUOtxCEHIcKjbkyzeUWon4rvW/O2PJ+LPGuX+cT3Y0mJX/3TaOO54 m56BSGeq93F8uHja3JT2cGnNBOb+bVlrVofywZOAznpqgdVcbwKfyV9CySRC23EhkF1Ux3+P4 ZUOrZnEIgtbSpmA2VFcNm2AcUo/kCY3kPrBkDXiWyRHUmv7uuCFJ1dmKR0zxr3hNe7SRSUTeV e6nWK/ehurPAIaliTaLQ6/+QvEa//1a77RtpYjE1Mq+j6mZVIEO8F7N+t+EVsiOGMFjG5zlvk 7US7In7QKaLgmPwktYFz4b9g/6ZdT94cvaUrc7hXk0N9in6iyc/wh Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov wrote: > On 22/09/2020 03:58, Andy Lutomirski wrote: > > On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov wrote: > > I may be looking at a different kernel than you, but aren't you > > preventing creating an io_uring regardless of whether SQPOLL is > > requested? > > I diffed a not-saved file on a sleepy head, thanks for noticing. > As you said, there should be an SQPOLL check. > > ... > if (ctx->compat && (p->flags & IORING_SETUP_SQPOLL)) > goto err; Wouldn't that mean that now 32-bit containers behave differently between compat and native execution? I think if you want to prevent 32-bit applications from using SQPOLL, it needs to be done the same way on both to be consistent: if ((!IS_ENABLED(CONFIG_64BIT) || ctx->compat) && (p->flags & IORING_SETUP_SQPOLL)) goto err; I don't really see how taking away SQPOLL from 32-bit tasks is any better than just preventing access to the known-broken files as Al suggested, or adding the hack to make it work as in Christoph's original patch. Can we expect all existing and future user space to have a sane fallback when IORING_SETUP_SQPOLL fails? Arnd