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 DC378C433FE for ; Mon, 14 Feb 2022 21:01:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229913AbiBNVBT (ORCPT ); Mon, 14 Feb 2022 16:01:19 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:36480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbiBNVBS (ORCPT ); Mon, 14 Feb 2022 16:01:18 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6ABAA7A9A0; Mon, 14 Feb 2022 13:01:09 -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 85B276114B; Mon, 14 Feb 2022 19:46:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB7E9C36AE5; 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-f41.google.com with SMTP id u1so14852926wrg.11; Mon, 14 Feb 2022 11:46:09 -0800 (PST) X-Gm-Message-State: AOAM530+hUo7NYph3CoxZKeAS43/bo2W3QPt8WJJKe7U6Fn0KDR5F9k4 RArsrLOi1yqH17m35h1qJUJXZtctpKBtOdHzC0c= 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" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org 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