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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 203B3C433F5 for ; Tue, 15 Feb 2022 10:02:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236099AbiBOKCu (ORCPT ); Tue, 15 Feb 2022 05:02:50 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:36458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231605AbiBOKCj (ORCPT ); Tue, 15 Feb 2022 05:02:39 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CF89196; Tue, 15 Feb 2022 02:02:29 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 00CC16126D; Tue, 15 Feb 2022 10:02:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58D8BC340F5; Tue, 15 Feb 2022 10:02:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644919348; bh=6OaJO5k8UStns9fCBustiYnW4Ue2uRRTBF363T6I8Z8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k2alkJqCK4tThaquDhNMTCGzfSPJoQ/+kF6M31KhrupjfCY12mmaxZXQGDR3lVlkH I3AKKVuIX4a/FRC22RpWas1peagK6eMoDIlyq/ClCx3eqN7pdZO4RnCoXP+Rla8Qps u0DMrsVXgSMbwt/E4fMYfx0BtSveveP9mpXMJ3ArTH8wBnn2Y+sb+V+b2EIOmZT06Q pqY4i7TzPYRkDpl6oeg7C5aWzjOIEZQJwAOn1lGP06V+D6ioRPTC25sJYFiILImHhL qmhL3MzhySo3dCg7GZz660sn4LBcHXU/aI3EOc+V67irk32eHunmx+R8h5+ABBl4dy P5O52Q7zn4hlg== Received: by mail-wm1-f43.google.com with SMTP id q198-20020a1ca7cf000000b0037bb52545c6so1084170wme.1; Tue, 15 Feb 2022 02:02:28 -0800 (PST) X-Gm-Message-State: AOAM532qqzCeQzcec0sQIYk1ABbpPvp/JSvMDHclGOr0VoAwlTqsh8cU gINZBJM5+GYCcBrV/wZSgZNPMlowy1jq3qxvuxU= X-Google-Smtp-Source: ABdhPJxXhF5oN8HK5+/UBfeNSuYxeBNAH3pN7Z2cMEK019oVoVAxn2dH7YUg+eieAXhNWJaJdsC0aGcEXS3C4UXMT34= X-Received: by 2002:a05:600c:2108:b0:34e:870:966e with SMTP id u8-20020a05600c210800b0034e0870966emr2332972wml.173.1644919346591; Tue, 15 Feb 2022 02:02:26 -0800 (PST) MIME-Version: 1.0 References: <20220214163452.1568807-1-arnd@kernel.org> <20220214163452.1568807-10-arnd@kernel.org> <20220215062942.GA12551@lst.de> In-Reply-To: From: Arnd Bergmann Date: Tue, 15 Feb 2022 11:02:10 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 09/14] m68k: drop custom __access_ok() To: Al Viro Cc: Christoph Hellwig , Linus Torvalds , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Russell King - ARM Linux , Will Deacon , Guo Ren , Brian Cain , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Nick Hu , Greentime Hu , Dinh Nguyen , Stafford Horne , Helge Deller , Michael Ellerman , Peter Zijlstra , Ingo Molnar , Mark Rutland , Heiko Carstens , Rich Felker , David Miller , Richard Weinberger , "the arch/x86 maintainers" , Max Filippov , "Eric W . Biederman" , Andrew Morton , Ard Biesheuvel , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , linux-csky@vger.kernel.org, "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , "open list:BROADCOM NVRAM DRIVER" , Openrisc , Parisc List , linuxppc-dev , linux-riscv , linux-s390 , Linux-sh list , sparclinux , linux-um , "open list:TENSILICA XTENSA PORT (xtensa)" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 15, 2022 at 8:13 AM Al Viro wrote: > On Tue, Feb 15, 2022 at 07:29:42AM +0100, Christoph Hellwig wrote: > > On Tue, Feb 15, 2022 at 12:37:41AM +0000, Al Viro wrote: > > > Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES > > > (and trim the comment down to "coldfire and 68000 will pick generic > > > variant")? > > > > I wonder if we should invert CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE, > > select the separate address space config for s390, sparc64, non-coldfire > > m68k and mips with EVA and then just have one single access_ok for > > overlapping address space (as added by Arnd) and non-overlapping ones > > (always return true). > > parisc is also such... How about > > select ALTERNATE_SPACE_USERLAND > > for that bunch? Either of those works for me. My current version has this keyed off TASK_SIZE_MAX==ULONG_MAX, but a CONFIG_ symbol does look more descriptive. > While we are at it, how many unusual access_ok() instances are > left after this series? arm64, itanic, um, anything else? x86 adds a WARN_ON_IN_IRQ() check in there. This could be made generic, but it's not obvious what exactly the exceptions are that other architectures need. The arm64 tagged pointers could probably also get integrated into the generic version. > FWIW, sparc32 has a slightly unusual instance (see uaccess_32.h there); it's > obviously cheaper than generic and I wonder if the trick is legitimate (and > applicable elsewhere, perhaps)... Right, a few others have the same, but I wasn't convinced that this is actually safe for call possible cases: it's trivial to construct a caller that works on other architectures but not this one, if you pass a large enough size value and don't access the contents in sequence. Also, like the ((addr | (addr + size)) & MASK) check on some other architectures, it is less portable because it makes assumptions about the actual layout beyond a fixed address limit. Arnd