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 DA2DAC4727D for ; Tue, 22 Sep 2020 16:20:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 82BD82395C for ; Tue, 22 Sep 2020 16:20:23 +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 S1726711AbgIVQUR (ORCPT ); Tue, 22 Sep 2020 12:20:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726526AbgIVQUO (ORCPT ); Tue, 22 Sep 2020 12:20:14 -0400 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7255C0613D5 for ; Tue, 22 Sep 2020 09:20:13 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id l126so12912674pfd.5 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=SFNawAXyBUzeqEae2UMI+BpA/LJsRwQLHg+2HAJlWHWIS6bq8aVFz8R3NnC1C64By/ od9cqKmmmeJHML0J+nsiCGXBVlBTqnfWr/eIOr+eE13hA8xQkJuM/MSrMU5XxOTkKeZU hcLQRGW8Pj46OPyuEhD+Cile3q2ThzzzF6GUD1RvOIfLBWqJkSbl45mcHgz/V39L3Hlr zmAplz9kvgii3MDpSF1Rkek2N4ARLPZb8GogM+8Auw7/DNeBsjFp3oHBeAVc8wISndAG TrXSdfgmRM9JugHDozIC8EP40pMBvRrH9Iqa9pL2iI30U+bISZTsqibrpvFsz9rQ9DpN 2/7w== X-Gm-Message-State: AOAM532q9AHrEWDDyCKnUovyuiXDQ87OSeMJoMLm33NMqWnnV5pAdanS ZJ6HEAgWH2lJodjbUo9tBmX9Og== 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-block@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.= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Date: Tue, 22 Sep 2020 16:20:07 +0000 Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag Message-Id: <446566DF-ECBC-449C-92A1-A7D5AEBE9935@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit List-Id: References: In-Reply-To: To: Arnd Bergmann 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 > On Sep 22, 2020, at 2:01 AM, Arnd Bergmann wrote: > > 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? > > I don’t have any real preference wrt SQPOLL, and it may be that we have a problem even without SQPOLL when IO gets punted without one of the fixes discussed. But banning the mismatched io_uring and io_uring_enter seems like it may be worthwhile regardless. 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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 6C4B1C4363D for ; Tue, 22 Sep 2020 16:24:58 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 663492395C for ; Tue, 22 Sep 2020 16:24:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="vkrTbtOH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 663492395C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BwmqV3hd9zDqWn for ; Wed, 23 Sep 2020 02:24:54 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=amacapital.net (client-ip=2607:f8b0:4864:20::544; helo=mail-pg1-x544.google.com; envelope-from=luto@amacapital.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.a=rsa-sha256 header.s=20150623 header.b=vkrTbtOH; dkim-atps=neutral Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BwmkF308xzDqW3 for ; Wed, 23 Sep 2020 02:20:16 +1000 (AEST) Received: by mail-pg1-x544.google.com with SMTP id o25so7424788pgm.0 for ; Tue, 22 Sep 2020 09:20:16 -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=rkWYaLex2PBCiJkWNZ/TQQ433hpqxw/iy1UwdgZiycLs/i9o5JHpNEEglomBHR9wee b3mvc4Vq6hCvuPy9LiGR6puOPDvV3vQcmA60bujCtNPujDu3NHoXUHf7UHkw2wO/CE2s DtfGH40BYR3srpk5AEtxmJPralNYEXksUOmT+5DaOQDtl9n3L0C1yUFPCYn3QfyxGeL2 EmOthA8mC6RerJhgaThZl48thZQrxQqNrd0/gkkiUrgSQmNfwez5PcgujBIaH4OEWqFR RQFO1QDqrvJyhz1LWVA2IxfU1hb0r1RxfYyyhNlu6hvFD37YrDP8lWhdgcGkXdVvrKHy ppIA== X-Gm-Message-State: AOAM531epeXYG2arc62hkED66M655wAn/3zCbjrM44R0sxfz3d74fcHI H1nqIF0TCXZAVHM7RFqvIHc+cA== 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: In-Reply-To: To: Arnd Bergmann X-Mailer: iPhone Mail (18A373) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-aio , "open list:MIPS" , David Howells , Linux-MM , keyrings@vger.kernel.org, sparclinux , Christoph Hellwig , linux-arch , linux-s390 , Linux SCSI List , X86 ML , linux-block , Al Viro , Andy Lutomirski , io-uring@vger.kernel.org, linux-arm-kernel , Jens Axboe , Parisc List , Network Development , LKML , LSM List , Linux FS Devel , Andrew Morton , linuxppc-dev , Pavel Begunkov Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" > 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.= 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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 C0720C4363D for ; Tue, 22 Sep 2020 16:22:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 266EE2395C for ; Tue, 22 Sep 2020 16:22:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="yFhD9IwE"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="vkrTbtOH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 266EE2395C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:In-Reply-To:References:Message-Id:Date:Subject: Mime-Version:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VMN1G/qHJf2baH4SuDAwuEFO1GJkQMBJcJwy0jHGoPs=; b=yFhD9IwE5+UfYUs5LWaN1lUcN FZABDXNdMvlA2Bdw51Fxk4h4QA5w2lDFaAnSviLss/0XYfhmxuSyxift6tnjgnUhe12c0JEsLDC2h 1vPPYERwXaW7TEhO4woKNPJDIeXMjU8NzbNHwraLQefx2RAG0oPbcilIAdEJT52QQVaE5lw9kO8ae yBQ2KpwkqQye0pFytnJjGQL086coDhYlFQ2SdqGY/WyG4dYGx0v0M0l9oTXq+m9KFoO8KUBniTDW3 WB3XdDA7ut24Mb1WcRrAovazoiZd2b4Tr9wepnEqAjvDi+tmN3IrC+9UwvA30kXHKm7NP3aDuJOlI DhHm2mhUw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKl1j-0002gl-4Y; Tue, 22 Sep 2020 16:20:23 +0000 Received: from mail-pg1-x544.google.com ([2607:f8b0:4864:20::544]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKl1d-0002el-6h for linux-arm-kernel@lists.infradead.org; Tue, 22 Sep 2020 16:20:18 +0000 Received: by mail-pg1-x544.google.com with SMTP id g29so12387325pgl.2 for ; Tue, 22 Sep 2020 09:20:14 -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=BwgiurkAdexECxYyHLAZeTPerETeFSY/5GH4L1yX6z4HPTfCe6qfyFMDDX9cq1YSRT rmr09VkZqyYspe1QQvoJM8iosq8uNL1Bw5FI5F5RT9+4ihUkrDqvgM+Cj4zVg4cMPnR+ CC32/sPeSCRHUrxaBmd+O1UaH5Cl5/cYH4DVv1j2xZuuRbXXUUV52024eG5R6yqqZMJw zdTmv6z+rFWTtstqEiRJgoJI7bTkWjdswKnpZ9dsSC/LEuEB3asGfqg2QipBMjtcbo64 /bzcNdBcWuLBr1RE146t5jtzSHBlHh4U2nj0vrpXYoqQ+d8dTlsFVf3f1APpJBUI74IN 8W+Q== X-Gm-Message-State: AOAM530aICfON4HMyL/lOGGpat8zOQXkODxdb5W4Anmn/obfTe1jntni 2ITFHY0JS+ZaGkWl79hnviNupA== 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) 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: In-Reply-To: To: Arnd Bergmann X-Mailer: iPhone Mail (18A373) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200922_122017_337019_129CDE7E X-CRM114-Status: GOOD ( 22.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-aio , "open list:MIPS" , David Howells , Linux-MM , keyrings@vger.kernel.org, sparclinux , Christoph Hellwig , linux-arch , linux-s390 , Linux SCSI List , X86 ML , linux-block , Al Viro , Andy Lutomirski , io-uring@vger.kernel.org, linux-arm-kernel , Jens Axboe , Parisc List , Network Development , LKML , LSM List , Linux FS Devel , Andrew Morton , linuxppc-dev , Pavel Begunkov Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Cgo+IE9uIFNlcCAyMiwgMjAyMCwgYXQgMjowMSBBTSwgQXJuZCBCZXJnbWFubiA8YXJuZEBhcm5k Yi5kZT4gd3JvdGU6Cj4gCj4g77u/T24gVHVlLCBTZXAgMjIsIDIwMjAgYXQgOTo1OSBBTSBQYXZl bCBCZWd1bmtvdiA8YXNtbC5zaWxlbmNlQGdtYWlsLmNvbT4gd3JvdGU6Cj4+PiBPbiAyMi8wOS8y MDIwIDEwOjIzLCBBcm5kIEJlcmdtYW5uIHdyb3RlOgo+Pj4gT24gVHVlLCBTZXAgMjIsIDIwMjAg YXQgODozMiBBTSBQYXZlbCBCZWd1bmtvdiA8YXNtbC5zaWxlbmNlQGdtYWlsLmNvbT4gd3JvdGU6 Cj4+Pj4gT24gMjIvMDkvMjAyMCAwMzo1OCwgQW5keSBMdXRvbWlyc2tpIHdyb3RlOgo+Pj4+PiBP biBNb24sIFNlcCAyMSwgMjAyMCBhdCA1OjI0IFBNIFBhdmVsIEJlZ3Vua292IDxhc21sLnNpbGVu Y2VAZ21haWwuY29tPiB3cm90ZToKPj4+Pj4gSSBtYXkgYmUgbG9va2luZyBhdCBhIGRpZmZlcmVu dCBrZXJuZWwgdGhhbiB5b3UsIGJ1dCBhcmVuJ3QgeW91Cj4+Pj4+IHByZXZlbnRpbmcgY3JlYXRp bmcgYW4gaW9fdXJpbmcgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIFNRUE9MTCBpcwo+Pj4+PiByZXF1 ZXN0ZWQ/Cj4+Pj4gCj4+Pj4gSSBkaWZmZWQgYSBub3Qtc2F2ZWQgZmlsZSBvbiBhIHNsZWVweSBo ZWFkLCB0aGFua3MgZm9yIG5vdGljaW5nLgo+Pj4+IEFzIHlvdSBzYWlkLCB0aGVyZSBzaG91bGQg YmUgYW4gU1FQT0xMIGNoZWNrLgo+Pj4+IAo+Pj4+IC4uLgo+Pj4+IGlmIChjdHgtPmNvbXBhdCAm JiAocC0+ZmxhZ3MgJiBJT1JJTkdfU0VUVVBfU1FQT0xMKSkKPj4+PiAgICAgICAgZ290byBlcnI7 Cj4+PiAKPj4+IFdvdWxkbid0IHRoYXQgbWVhbiB0aGF0IG5vdyAzMi1iaXQgY29udGFpbmVycyBi ZWhhdmUgZGlmZmVyZW50bHkKPj4+IGJldHdlZW4gY29tcGF0IGFuZCBuYXRpdmUgZXhlY3V0aW9u Pwo+Pj4gCj4+PiBJIHRoaW5rIGlmIHlvdSB3YW50IHRvIHByZXZlbnQgMzItYml0IGFwcGxpY2F0 aW9ucyBmcm9tIHVzaW5nIFNRUE9MTCwKPj4+IGl0IG5lZWRzIHRvIGJlIGRvbmUgdGhlIHNhbWUg d2F5IG9uIGJvdGggdG8gYmUgY29uc2lzdGVudDoKPj4gCj4+IFRoZSBpbnRlbnRpb24gd2FzIHRv IGRpc2FibGUgb25seSBjb21wYXQgbm90IG5hdGl2ZSAzMi1iaXQuCj4gCj4gSSdtIG5vdCBmb2xs b3dpbmcgd2h5IHRoYXQgd291bGQgYmUgY29uc2lkZXJlZCBhIHZhbGlkIG9wdGlvbiwKPiBhcyB0 aGF0IGNsZWFybHkgYnJlYWtzIGV4aXN0aW5nIHVzZXJzIHRoYXQgdXBkYXRlIGZyb20gYSAzMi1i aXQKPiBrZXJuZWwgdG8gYSA2NC1iaXQgb25lLgo+IAo+IFRha2luZyBhd2F5IHRoZSBmZWF0dXJl cyBmcm9tIHVzZXJzIHRoYXQgYXJlIHN0aWxsIG9uIDMyLWJpdCBrZXJuZWxzCj4gYWxyZWFkeSBz ZWVtcyBxdWVzdGlvbmFibGUgdG8gbWUsIGJ1dCBiZWluZyBpbmNvbnNpc3RlbnQKPiBhYm91dCBp dCBzZWVtcyBtdWNoIHdvcnNlLCBpbiBwYXJ0aWN1bGFyIHdoZW4gdGhlIHJlZ3Jlc3Npb24KPiBp cyBvbiB0aGUgdXBncmFkZSBwYXRoLgo+IAo+Pj4gQ2FuIHdlIGV4cGVjdCBhbGwgZXhpc3Rpbmcg YW5kIGZ1dHVyZSB1c2VyIHNwYWNlIHRvIGhhdmUgYSBzYW5lCj4+PiBmYWxsYmFjayB3aGVuIElP UklOR19TRVRVUF9TUVBPTEwgZmFpbHM/Cj4+IAo+PiBTUVBPTEwgaGFzIGEgZmV3IGRpZmZlcmVu Y2VzIHdpdGggbm9uLVNRUE9MTCBtb2RlcywgYnV0IGl0J3MgZWFzeQo+PiB0byBjb252ZXJ0IGJl dHdlZW4gdGhlbS4gQW55d2F5LCBTUVBPTEwgaXMgYSBwcml2aWxlZ2VkIHNwZWNpYWwKPj4gY2Fz ZSB0aGF0J3MgaGVyZSBmb3IgcGVyZm9ybWFuY2UvbGF0ZW5jeSByZWFzb25zLCBJIGRvbid0IHRo aW5rCj4+IHRoZXJlIHdpbGwgYmUgYW55IG5vbi1hY2NpZGVudGFsIHVzZXJzIG9mIGl0Lgo+IAo+ IE9rLCBzbyB0aGUgYmVoYXZpb3Igb2YgMzItYml0IHRhc2tzIHdvdWxkIGJlIHRoZSBzYW1lIGFz IHJ1bm5pbmcKPiB0aGUgc2FtZSBhcHBsaWNhdGlvbiBhcyB1bnByaXZpbGVnZWQgNjQtYml0IHRh c2tzLCB3aXRoIGFwcGxpY2F0aW9ucwo+IGFscmVhZHkgaGF2aW5nIHRvIGltcGxlbWVudCB0aGF0 IGZhbGxiYWNrLCByaWdodD8KPiAKPiAKCkkgZG9u4oCZdCBoYXZlIGFueSByZWFsIHByZWZlcmVu Y2Ugd3J0IFNRUE9MTCwgYW5kIGl0IG1heSBiZSB0aGF0IHdlIGhhdmUgYSBwcm9ibGVtIGV2ZW4g d2l0aG91dCBTUVBPTEwgd2hlbiBJTyBnZXRzIHB1bnRlZCB3aXRob3V0IG9uZSBvZiB0aGUgZml4 ZXMgZGlzY3Vzc2VkLgoKQnV0IGJhbm5pbmcgdGhlIG1pc21hdGNoZWQgaW9fdXJpbmcgYW5kIGlv X3VyaW5nX2VudGVyIHNlZW1zIGxpa2UgaXQgbWF5IGJlIHdvcnRod2hpbGUgcmVnYXJkbGVzcy4K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJt LWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3Jn Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtl cm5lbAo=