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,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 35D57C4741F for ; Tue, 22 Sep 2020 16:20:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE52F2086A for ; Tue, 22 Sep 2020 16:20:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="vkrTbtOH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726696AbgIVQUO (ORCPT ); Tue, 22 Sep 2020 12:20:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbgIVQUO (ORCPT ); Tue, 22 Sep 2020 12:20:14 -0400 Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2518C0613D4 for ; Tue, 22 Sep 2020 09:20:13 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id 34so12355517pgo.13 for ; Tue, 22 Sep 2020 09:20:13 -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=OuYZ36WnxwIp9b6camA1INonBCd7PS5F7n5lbvDtQoE=; b=vkrTbtOH4vHnR/84aYqVDHrQ5AGvI5gJZ+epaaRbPDginNWZ7IQOaHp0KiQGLoRIqK lCtpCBfEppwh5xdm5Fg2E09yGBsQ1omUh0FsVnB0AGbc0KabsZevsMs5kdugIv8CVE5/ WA4g4A2X6yhuybhLsZ26G3b/9jK9koGpq3H8xumPWJXJrnSzbLUYbfDR++IgN0bKoBQq n0DG/oDelKPnE35WpGCvEELD66Jz17cs7lC56sr6mITihQA1DVJ1mt9BGhniHUyWF6Lh zzYPOu4uBf4nQ34xtWqSlA6XpnJ8NFviCNNpjE2H0nhrpatshwJ5hPmeTiRqtrX3VMpc QmhQ== 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=OuYZ36WnxwIp9b6camA1INonBCd7PS5F7n5lbvDtQoE=; b=T3P9K5jadobq7o0Cz8tcTXWegC3I3NEy8uBjBvL4I/1UdqToZ8FOU/0WTvbAUuR3Wx S5TOgLRrjZe1szVFSDtwk4X7Kf/nPD0VmpIkMs3ZImEh1gMxXHoqqYNe7+lIx+0ltFrV HiQH1H/Zk5o2iW6NEBfINoZkvQ21YGD/QaJTm6/PQeowg4+vK3gQS59wzEr7U68naSp0 WJWcRZEbOMbBvJcIPbMQSq+2TVj7FPi4Z8Xh0wqkg/YsrHZEW9nrtQYhiHXweK3n3+pM st3afkFizk4pvOlOTKO6G0171aT90upgq0G0Ec3G/3iv/42FJnAN1H6qQsZ40aWPJWVo R/vw== X-Gm-Message-State: AOAM532523lCsMHQWrFBITHYIWN+fuXNNfjcp/E8d8P+0a6ATPwIXmrd ZAkcB8dC12jnypTZ5GRV479Ctw== X-Google-Smtp-Source: ABdhPJzVdW+N5Ufbpna8vjsXyt2h2YPelrT15cDlhJa791IGnC+04vroQZTdEBrKNKjccVmTF6OthA== X-Received: by 2002:a17:902:fe88:b029:d2:2a16:254 with SMTP id x8-20020a170902fe88b02900d22a160254mr5598643plm.23.1600791613205; Tue, 22 Sep 2020 09:20:13 -0700 (PDT) Received: from localhost.localdomain ([2601:646:c200:1ef2:f4bd:fe2:85ed:ea92]) by smtp.gmail.com with ESMTPSA id gk14sm2982522pjb.41.2020.09.22.09.20.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2020 09:20:12 -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: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag Date: Tue, 22 Sep 2020 09:20:07 -0700 Message-Id: <446566DF-ECBC-449C-92A1-A7D5AEBE9935@amacapital.net> References: Cc: Pavel Begunkov , 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 In-Reply-To: To: Arnd Bergmann X-Mailer: iPhone Mail (18A373) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org > On Sep 22, 2020, at 2:01 AM, Arnd Bergmann wrote: >=20 > =EF=BB=BFOn 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 w= rote: >>>> 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? >>>>=20 >>>> I diffed a not-saved file on a sleepy head, thanks for noticing. >>>> As you said, there should be an SQPOLL check. >>>>=20 >>>> ... >>>> if (ctx->compat && (p->flags & IORING_SETUP_SQPOLL)) >>>> goto err; >>>=20 >>> Wouldn't that mean that now 32-bit containers behave differently >>> between compat and native execution? >>>=20 >>> 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: >>=20 >> The intention was to disable only compat not native 32-bit. >=20 > 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. >=20 > 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. >=20 >>> Can we expect all existing and future user space to have a sane >>> fallback when IORING_SETUP_SQPOLL fails? >>=20 >> 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. >=20 > 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? >=20 >=20 I don=E2=80=99t have any real preference wrt SQPOLL, and it may be that we h= ave a problem even without SQPOLL when IO gets punted without one of the fix= es discussed. But banning the mismatched io_uring and io_uring_enter seems like it may be w= orthwhile regardless.=