From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42959C4727F for ; Tue, 22 Sep 2020 09:02:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EFA32239D4 for ; Tue, 22 Sep 2020 09:02:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726531AbgIVJB4 (ORCPT ); Tue, 22 Sep 2020 05:01:56 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:48239 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726353AbgIVJBz (ORCPT ); Tue, 22 Sep 2020 05:01:55 -0400 Received: from mail-qk1-f174.google.com ([209.85.222.174]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1M8QJq-1kP1tX30wS-004R66; Tue, 22 Sep 2020 11:01:51 +0200 Received: by mail-qk1-f174.google.com with SMTP id 16so18290762qkf.4; Tue, 22 Sep 2020 02:01:50 -0700 (PDT) X-Gm-Message-State: AOAM531+93v+0pc6Wi7zIypNe7Vgpz/NCT5EEwScNq/ES31+DcqqIzIF wjBHiQJRNRN0efUxhQeFDvY1TrHFTG/Dy6uuW7w= X-Google-Smtp-Source: ABdhPJyRqkNrv5vljO58DCgwZZgH8gYzn8Pg1f10DkzXAekHvwLoBvZT9T4MCMOwP2QMtNaCPo1tGJEV8E4gZYbkeUE= X-Received: by 2002:ae9:c30d:: with SMTP id n13mr3794670qkg.138.1600765309262; Tue, 22 Sep 2020 02:01:49 -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 11:01:32 +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:8U3QhqUgQssKpQivIurx1QhO0HcizCTbv9FM2dYjR7qI/BYtgBT aXnBt+gH3i7BkW4ORLrCt4H46/pNjWBK/mpqCyumcjcVfj1/zotel3weBob9uElfz3DwR7K SD73O72POJ3pwjD8gWBnHZGyAwt1MpkpQv9XkBHvto4Q+XAgPzYoa4EjGe8Z/x39gDR9cGO QujCKw+EEJbaSeenNDMzw== X-UI-Out-Filterresults: notjunk:1;V03:K0:lxgMs8VhhiM=:l+UfaADbxVKseh338rQzK0 QfABKRk1uOM8j+TCS6sCwMVp7ftwkOoJIGxGdG6L6VzI7cEX/MhwRXSQNk8YlDVPqekFAwqsJ K748wMagnWb5anQxTXdEkOBo0uWtUSAEwztEdQ2OBKdjwEG1J6pIlrCcDyitdMMoAz861eF0u z2iEwNTG7KaprxuPyh3LpnSFr4t9fNgbzFOS7H+wEZEnC9CeAWNx5wP0L6sE37HsEVzBj0klw rCdMwj/xQX550kfGtz5Tst5P+5qFFcpSycGh7yxzuA7IfUTo0Jtcxxq8Nsoy2hdLMsRB5AeEU hTJ1KV0t+ZNP/UDzzsqu7H5kqZnJRYF/Z8Ji6rftWofkhI6uKJJ8Cfjq8tWrO/UeP3XIf9v2i DQj5nXdMHge7GHqPvPrsVFMyAkUL1J4r8j1ePLIXjlpNWnjVBfzHviGfTGbMYidP8nHyfMUv4 hEG02hwSHv9Zn7QmlN72PGM4XbtnD7nIM85CCGS+B86CUtmOfBWj5gRwwocYygk0Mfzi0STau 9lBglupWtfGYz14JMgT+7eEGaMn3WNy19TESYPhKMsyiDYRSSu38/SERTgtuUQo8ptjsjNOMw hMWuBgTKGkOX+0SeCUD2zOGOi/+ubpkvRVlttuUSAIEUl1xdqDzZNS6siOVdInCDtDO3VcOwL tz/kxsgWRCy7enDEmiF8nZGkmBV+bcNr8kAHKqyZDkcgcSxHstfrPlSvQ8eU70sysdob1c6pH o6m1IdiLADPf36SBZ2b/E1EXaXU5wEKpga7xW5vj4MkINkTWIONy6jvzXbTYJ5RaLNmyXl2Xq CcmZaAJaQnOwp55YtAfNvehwZlUtix7GjXWpSVDKul5QTnf8MdHSUm66q7etTCD1nugbL5krf nX96T+FtWTicJ8P6Rd2wiUyg+fLf10H8SOm4BOpcrhYne4qDBpHCkC3Wl4ydqivn66oeOEyJ9 sHgF+76xRs7ep05tWnMmeiHdPlcAupShCEbkpfyQnpooyIq1sTbAL Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov wrote: > On 22/09/2020 10:23, Arnd Bergmann wrote: > > 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: > > The intention was to disable only compat not native 32-bit. I'm not following why that would be considered a valid option, as that clearly breaks existing users that update from a 32-bit kernel to a 64-bit one. Taking away the features from users that are still on 32-bit kernels already seems questionable to me, but being inconsistent about it seems much worse, in particular when the regression is on the upgrade path. > > Can we expect all existing and future user space to have a sane > > fallback when IORING_SETUP_SQPOLL fails? > > SQPOLL has a few differences with non-SQPOLL modes, but it's easy > to convert between them. Anyway, SQPOLL is a privileged special > case that's here for performance/latency reasons, I don't think > there will be any non-accidental users of it. Ok, so the behavior of 32-bit tasks would be the same as running the same application as unprivileged 64-bit tasks, with applications already having to implement that fallback, right? Arnd