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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3F0EC433EF for ; Mon, 14 Feb 2022 19:46:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 542756B007B; Mon, 14 Feb 2022 14:46:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CBDC6B007D; Mon, 14 Feb 2022 14:46:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 345F96B007E; Mon, 14 Feb 2022 14:46:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id 22A566B007B for ; Mon, 14 Feb 2022 14:46:15 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CAA1E944F7 for ; Mon, 14 Feb 2022 19:46:14 +0000 (UTC) X-FDA: 79142416668.14.0AE770C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf12.hostedemail.com (Postfix) with ESMTP id 2DF6640012 for ; Mon, 14 Feb 2022 19:46:14 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id 5C14AB8167A for ; Mon, 14 Feb 2022 19:46:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F33D7C340F8 for ; Mon, 14 Feb 2022 19:46:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644867970; bh=kZ0Ha+ZttRWbRYErkpKyuJC1dyK+QrO2i6Uu5KgHMvM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Y0tFdEItPyIpX9Q57aljIliTeAqJEjfsGhV5sRnV7cHDKUAHBtZxnjnJQ0aG/E0DY ntmMdawRiR6T8SjqmJRkg+eiX9WIai06zkYCR7faiov+1eO6KA28Xd0WJ3G4HzZ7Ki PswrJdfwevWrM+GcXzzieldjGJJj+F38X56atyYmYHaGjvacQFUxk+Q3y53FA51+T8 ZklKna1hQALqex7ucGzH+u+kKR6+AMMF6Gi34rWhxaWoueN0V5gBdQpdknscuvJdj6 4dVyfkX9O/n11Gjix37hL+YmaFTxTy2u9mOy0+3ugdzfzd4uf88HSfSBljtkByDhnd ubPSK5lCMcVZQ== Received: by mail-wr1-f49.google.com with SMTP id j26so17762194wrb.7 for ; Mon, 14 Feb 2022 11:46:09 -0800 (PST) X-Gm-Message-State: AOAM532xVWHPmCWwAKS8YIEwz6L+yK0TwBl1OcqnBgT9kW4mFIud1+fK pu1Kqv6PHTC1bGX2E1vnAvb5pl1QdWR1FWVlvBU= X-Google-Smtp-Source: ABdhPJyfeYwWpAfp1t9O1z8BIiteD6oMiQUhUFLNHvAQyjgPbxD0FyJauHtAzbL5TNr8UyIGWRM1U9VPuoeyXIyyYo0= X-Received: by 2002:adf:f6ce:: with SMTP id y14mr445399wrp.219.1644867968239; Mon, 14 Feb 2022 11:46:08 -0800 (PST) MIME-Version: 1.0 References: <20220214163452.1568807-1-arnd@kernel.org> <20220214163452.1568807-5-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 14 Feb 2022 20:45:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 04/14] x86: use more conventional access_ok() definition To: Christoph Hellwig Cc: Linus Torvalds , Christoph Hellwig , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Mark Rutland , Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Peter Zijlstra , Max Filippov , Guo Ren , sparclinux , "open list:QUALCOMM HEXAGON..." , linux-riscv , Will Deacon , Ard Biesheuvel , linux-s390 , Brian Cain , Helge Deller , "the arch/x86 maintainers" , Russell King - ARM Linux , linux-csky@vger.kernel.org, Ingo Molnar , Geert Uytterhoeven , "open list:SYNOPSYS ARC ARCHITECTURE" , "open list:TENSILICA XTENSA PORT (xtensa)" , Heiko Carstens , alpha , linux-um , linux-m68k , Openrisc , Greentime Hu , Stafford Horne , Linux ARM , Michal Simek , Thomas Bogendoerfer , Parisc List , Nick Hu , "open list:BROADCOM NVRAM DRIVER" , Dinh Nguyen , "Eric W . Biederman" , Richard Weinberger , Andrew Morton , linuxppc-dev , David Miller , Al Viro Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2DF6640012 X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y0tFdEIt; spf=pass (imf12.hostedemail.com: domain of arnd@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=arnd@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 44wmpk63ow9bgwscsmyuj9rdf3nfcwqe X-HE-Tag: 1644867974-257349 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 14, 2022 at 6:02 PM Christoph Hellwig wrote: > > On Mon, Feb 14, 2022 at 05:34:42PM +0100, Arnd Bergmann wrote: > > +#define __range_not_ok(addr, size, limit) (!__access_ok(addr, size)) > > +#define __chk_range_not_ok(addr, size, limit) (!__access_ok((void __user *)addr, size)) > > Can we just kill these off insted of letting themm obsfucate the code? As Al pointed out, they turned out to be necessary on sparc64, but the only definitions are on sparc64 and x86, so it's possible that they serve a similar purpose here, in which case changing the limit from TASK_SIZE to TASK_SIZE_MAX is probably wrong as well. So either I need to revert the original definition as I did on sparc64, or they can be removed completely. Hopefully Al or the x86 maintainers can clarify. Arnd