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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8BAB5C433F5 for ; Mon, 21 Feb 2022 14:32:40 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4K2PsK5nbwz3cPP for ; Tue, 22 Feb 2022 01:32:37 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=kzJ4oJ7u; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=arnd@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=kzJ4oJ7u; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4K2PrV5p6Rz2xsc for ; Tue, 22 Feb 2022 01:31:54 +1100 (AEDT) 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 4C73A60F4E for ; Mon, 21 Feb 2022 14:31:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B958DC340F5 for ; Mon, 21 Feb 2022 14:31:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645453911; bh=12Bbx9GqAhHL6qqDyToeCYzPAWe2m8+m6+gTGV+hFTw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kzJ4oJ7uqkQlH8HKP59hga7BxTSd9yAv9G83J3PE9Vxo9wgwCF55WEif4JDuq66Es xJHgiAYKMSMrCA+rbeIjmKJKM3SV0fBLyOZsQa95vK8cdEppsgKEikoB+c9hrTgPD6 N3/wnjEuF/+t+ByBpKQN3Dzq1OrIxHrSb4YNAPOcfEv6v4f/QcpswnD2hOYaY7e5ZR P2yzCaocscWCwjSY0LU/aagBUySQOBShLiiZAXM9rLdNx4Mpjcu34oGUvRfmZEBPw+ VjJykXvvmkBWqCNmRXcJeDSqWyibRwN4/9udBAhduxi7qzsuFLGNxd5SxW6ohLqgwt B42/CscfKu6MA== Received: by mail-ej1-f46.google.com with SMTP id qx21so33682694ejb.13 for ; Mon, 21 Feb 2022 06:31:51 -0800 (PST) X-Gm-Message-State: AOAM530012n7qsQ4WuI25XpBiWYbG8yA8VB8ft6KHTsdZX2Nq6fY6HiW +rkBu5R4EivevQq0g/CtSqBp6bfGTdrtV4vgyok= X-Google-Smtp-Source: ABdhPJwkamQNFHYmlXBqgC6u1r1MKNMeB6x6hm57ILAz8yVFLOW/Qf4lv8t2aLUhrb2kSK2FAx/PKmoUpYjfFDbRcw0= X-Received: by 2002:adf:90c1:0:b0:1e4:ad27:22b9 with SMTP id i59-20020adf90c1000000b001e4ad2722b9mr16170850wri.219.1645453899581; Mon, 21 Feb 2022 06:31:39 -0800 (PST) MIME-Version: 1.0 References: <20220216131332.1489939-1-arnd@kernel.org> <20220216131332.1489939-10-arnd@kernel.org> <20220221132456.GA7139@alpha.franken.de> In-Reply-To: <20220221132456.GA7139@alpha.franken.de> From: Arnd Bergmann Date: Mon, 21 Feb 2022 15:31:23 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok() To: Thomas Bogendoerfer Content-Type: text/plain; charset="UTF-8" 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: Mark Rutland , Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Peter Zijlstra , "open list:BROADCOM NVRAM DRIVER" , Linux-MM , Guo Ren , sparclinux , "open list:QUALCOMM HEXAGON..." , linux-riscv , Will Deacon , Christoph Hellwig , linux-arch , linux-s390 , Brian Cain , Helge Deller , the arch/x86 maintainers , Russell King - ARM Linux , linux-csky@vger.kernel.org, Ard Biesheuvel , Ingo Molnar , Geert Uytterhoeven , "open list:SYNOPSYS ARC ARCHITECTURE" , "open list:TENSILICA XTENSA PORT \(xtensa\)" , Arnd Bergmann , Heiko Carstens , alpha , linux-um , linuxppc-dev , linux-m68k , Openrisc , Al Viro , Stafford Horne , Michal Simek , Parisc List , Nick Hu , Max Filippov , Linux API , Linux Kernel Mailing List , Dinh Nguyen , "Eric W . Biederman" , Richard Weinberger , Andrew Morton , Linus Torvalds , David Miller , Greentime Hu Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer wrote: > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote: > > > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h > > index db9a8e002b62..d7c89dc3426c 100644 > > this doesn't work. For every access above maximum implemented virtual address > space of the CPU an address error will be issued, but not a TLB miss. > And address error isn't able to handle this situation. Ah, so the __ex_table entry only catches TLB misses? Does this mean it also traps for kernel memory accesses, or do those work again? If the addresses on mips64 are separate like on sparc64 or s390, the entire access_ok() step could be replaced by a fixup code in the exception handler. I suppose this depends on CONFIG_EVA and you still need a limit check at least when EVA is disabled. > With this patch > > diff --git a/arch/mips/kernel/unaligned.c b/arch/mips/kernel/unaligned.c > index df4b708c04a9..3911f1481f3d 100644 > --- a/arch/mips/kernel/unaligned.c > +++ b/arch/mips/kernel/unaligned.c > @@ -1480,6 +1480,13 @@ asmlinkage void do_ade(struct pt_regs *regs) > prev_state = exception_enter(); > perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, > 1, regs, regs->cp0_badvaddr); > + > + /* Are we prepared to handle this kernel fault? */ > + if (fixup_exception(regs)) { > + current->thread.cp0_baduaddr = regs->cp0_badvaddr; > + return; > + } > + > /* > * Did we catch a fault trying to load an instruction? > */ > > I at least get my simple test cases fixed, but I'm not sure this is > correct. > > Is there a reason to not also #define TASK_SIZE_MAX __UA_LIMIT like > for the 32bit case ? > For 32-bit, the __UA_LIMIT is a compile-time constant, so the check ends up being trivial. On all other architectures, the same thing can be done after the set_fs removal, so I was hoping it would work here as well. I suspect doing the generic (size <= limit) && (addr <= (limit - size)) check on mips64 with the runtime limit ends up slightly slower than the current code that checks a bit mask instead. If you like, I'll update it this way, otherwise I'd need help in form of a patch that changes the exception handling so __get_user/__put_user also return -EFAULT for an address error. Arnd