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 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 4819EC07E99 for ; Mon, 5 Jul 2021 13:42:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 155FE61206 for ; Mon, 5 Jul 2021 13:42:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 155FE61206 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=v7WnOngIa9v3t9+fpsxgSqzU0JFKdD6G5IhkC4one6c=; b=lVZHmPc5XJoaph YWgSET1qnWM6G7hyQSQcTNnXpCrjyQr89rK3R9M79IS/O+vn0JiL7FRfWgoWDDDtVJXUxQATeethQ OZE0dtrefluKmZ+ZISKoo763p5uObQhEOTSdGDBtOyB7onUL4ZpY0Nc03NqnOly29o+WkGD81niWV 82RtPrUNjce+IlpL1yIo2cXCGt5aa000ozDGLX94JA3b0ND6MHjR4dm9p+9Mq2IsBqYk7WoXpt5JQ rTnigZQtWHUT/ONOBs1WFOMl2poy67ZZOpsN2dPb6xZVrTObeCpEcX5g69KCIHetpadQR7+s5/bVV idCLIvxKRXTaEmM/cuug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m0Oq4-0091zj-Hb; Mon, 05 Jul 2021 13:40:44 +0000 Received: from mout.kundenserver.de ([212.227.17.13]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m0Oq0-0091z7-Ii for linux-arm-kernel@lists.infradead.org; Mon, 05 Jul 2021 13:40:42 +0000 Received: from mail-wr1-f50.google.com ([209.85.221.50]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MS3rB-1lbT2X0sdX-00TRC3 for ; Mon, 05 Jul 2021 15:40:34 +0200 Received: by mail-wr1-f50.google.com with SMTP id v5so22150698wrt.3 for ; Mon, 05 Jul 2021 06:40:34 -0700 (PDT) X-Gm-Message-State: AOAM533mM4ujT83wGj79DHxr2ilH1ilyOsl4l1HdU3FWYpfVlA21V5fh lI4DIee6YquzGqz0As2zlJ82XjiU0b6y0x4CUJo= X-Google-Smtp-Source: ABdhPJyNk0E58GdhdijG+SWnLfymVKXZ/4Aj/5fDKjXY6B+nWTKh9KhTnS5biw+IyDgpCND/EK/0PkvZ8uhiQ+fkLjc= X-Received: by 2002:adf:fd8e:: with SMTP id d14mr16484625wrr.361.1625492433851; Mon, 05 Jul 2021 06:40:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Mon, 5 Jul 2021 15:40:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131) To: Yury Norov Cc: Catalin Marinas , "linux-audit/audit-kernel" , "linux-audit/audit-kernel" , Mention , Xiongfeng Wang , Wang ShaoBo , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-doc@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-api@vger.kernel.org" , Adam Borowski , Alexander Graf , Alexey Klimov , Andreas Schwab , Andrew Pinski , Bamvor Zhangjian , Chris Metcalf , Christoph Muellner , Dave Martin , "David S . Miller" , Florian Weimer , Geert Uytterhoeven , Heiko Carstens , James Hogan , James Morse , Joseph Myers , Lin Yongting , Manuel Montezelo , Mark Brown , Martin Schwidefsky , Maxim Kuvyrkov , Nathan_Lynch , Philipp Tomsich , Prasun Kapoor , Ramana Radhakrishnan , Steve Ellcey , Szabolcs Nagy X-Provags-ID: V03:K1:n/F8w2LIGVmazdeIt5QwOTLCdbAJIbhwrvPvddlnaL9gt0dzBbn k0bZ8WngrA9r33AGl+36tMFQRk4AetPZg7rFThSeobU7gpjz4FspI3bCRbVqVA3aRdD/dKx Aalm5/1lFB7sBy3jb30z9g5YG1w2IOYJ089itkTh96lzoLJxY1cUHndxIHkpJAaFkXTk9W6 WuW+47RQu0hEeA0o+M76w== X-UI-Out-Filterresults: notjunk:1;V03:K0:CRuqmDl5Ry8=:CNg6S5Ni5RSRSiDOUhBdbC zW2If9nbjAeuS5b1Nh39ChG9pIcCm6wyvqftL8+BlQmPCfA/pXLNUcXb+BQCtZBBn9PhVyRFo 0giXTZkOuxLs1tVRFdcCZ3oOjOX6s4QYZ+n2QbV9SKVKaxB2BynH+QX9k80heCOQTeCiVaJmp qQ6VgZrMApvXhNi4fhfc/k7pLF5qeBR4x4HncNBIZ2rpWelq2qroX8s95LHSyiar2QNOApe54 N8C7gm6Hv2zYRXEhh1fszqpQHvD3BAqM2McFEM1EVjAmE64ZmlT28tAmclhXecmvwgmQvdY2o XA/cmQC9wUCQ6iE86R8PTI7EbnGcunfSVlLhyxZRzgsDYpPY5Tz+RttgZljd0Ps0Hrwwx1abx HmZcYGvUcdmVNOszP1BjDqo7nFK4Gd8Raf0avOc/BhxxKuNXyaPRQMPYbQjJh+eyjjPsxD0fs 9FlJXJJX61hkupdg3XCDEdq/83wGz6yPDWBP9YZMd1x/paD+ahWsqbne8YNigM7vof1U9FFf3 uT4cdOAFQ8ki2RahjXt7vwWMYmQJBWXa8UEaYuWljy9H9P5xEIYCUZHFkgrjwqrq+WE8pa5tJ TNyTkrvXj6t3y34hTsdEiKmKmZRJ9+f9PKP2xuMRZzZ6sAA+EwUaiX3iJ7TcCcoNp1mDJ1+Lt AGfEkdW1nkCMR2f+v3qcYmL9pMkxfnpC/xaYHl3YsfJQbWezNXXNMh1QfrlCZB4SkuEr49qZo oESvxVRmzrILky7tYxY53+akWPr9vOL+SkMImUZgmnRBZAkYDfOPXKSkdf9AeyQ2ZBC6kpVRV qO6fFF8P8ux8wdF0JaI1OY73yArdynPMlP+rt+X2pEYmj4+vPa10YJj6MONVSWdO71uwStC2+ RtQ1H+rT1l9fcH+3RahRhln274tv/Ru+OJohIuxmJLf5Y8n63n4uh1F2fvDKpyUwtitJnXNiV Ab8OgO7DB/NvwRaMMOYyazpQqsXI8tvaHmjopVGAHCNTUpBc6ZlQP X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210705_064040_939973_542DFB02 X-CRM114-Status: GOOD ( 23.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 2, 2021 at 8:07 PM Yury Norov wrote: > On Thu, Jul 01, 2021 at 05:08:45AM -0700, Paul Moore wrote: > > To Catalin, Arnd: > > At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer > actively use and develop arm64/ilp32. I receive feedback / bugrepotrs > on ilp32 every 4-6 month. Is that enough for you to reconsider > including the project into the mainline? > > For me, having different versions of ILP32 is more dangerous in this > situation, than upstreaming the project and fixing 2-3 bugs a year. I think the overall tradeoff is not that different from what it was in the past. Keeping it out of the tree clearly creates extra work both for you and the users, but reduces the overhead for everyone else, who can ignore that corner case. We have tried removing both x86-x32 support and arm64 big-endian support from the kernel not that long ago. Both have considerably more impact on kernel maintenance than your aarch64-ilp32 work, and they probably even have fewer users, but we always ended up keeping the status quo. However, there are clearly some changes that happened over the past few years that may be relevant here: - The expectation in the past was that ilp32 support would eventually go away as users move on to full 64-bit support. It has survived a lot longer than I would have guessed, but I still find it hard to tell whether this would continue. What's more important than the current number of users is how many of those you expect to run linux-6.x or linux-7.x with aarch64-ilp32 in the future. - Another thing that has changed is that we now have a rough timeline for aarch32 support to be removed from future Arm processors. If no Armv9 processors after 2022 support Aarch32 mode, we may see interest in ilp32 mode go up between 2025 and 2030 when those processors make it into more markets. - On the other hand, interest in not just 32-bit hardware running Linux but also in 32-bit user space is already declining overall. We'll probably still see some 10 to 20 years of 32-bit user space deployments on (mostly) memory constrained systems, but this is getting increasingly obscure as more applications run into virtual memory space restrictions (3GB or 4GB typically) before they exceed the available RAM. On RV64 and ARCv3, there is already a conclusion that they will not support 32-bit user space, neither ilp32 style on 64-bit instructions nor with hardware support for RV32/ARC32 binaries. I expect the same for Loongarch. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel