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 45C91C433FE for ; Mon, 21 Feb 2022 14:31:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C10E8D0005; Mon, 21 Feb 2022 09:31:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 648528D0002; Mon, 21 Feb 2022 09:31:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EA7D8D0005; Mon, 21 Feb 2022 09:31:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 3CE2A8D0002 for ; Mon, 21 Feb 2022 09:31:44 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id F2DFD181CAEDF for ; Mon, 21 Feb 2022 14:31:43 +0000 (UTC) X-FDA: 79167025728.28.3C646E0 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 4FC044000C for ; Mon, 21 Feb 2022 14:31:43 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 6793561023 for ; Mon, 21 Feb 2022 14:31:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A5B7C340F6 for ; Mon, 21 Feb 2022 14:31:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645453901; bh=12Bbx9GqAhHL6qqDyToeCYzPAWe2m8+m6+gTGV+hFTw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dWMiI8z7xtZHkIlGi7baHffVMjwIn0mdLtr8w3vUAA5dDZqhK8ZI+KhxrCTrxvery mRfleZO0SSscQ7KVHRUh2QGlGW5v/gw6LGH9t2vGIJ9GkNRHieJ694s+DQVSh8xG3o 1QAKmXJLcJTGwkGYaV1wYGfF51PnInRtSU+fVsx8t4J76oPDgdmMoUbmKLWffZoAAd kmIbWlsuSubrQtmT6agHzwSbb3tqK56Q4BV05Zptd15vS9GZroHUtkz4s+wh3Rty9l 7L/rHU3TLbzMVdK84DCafmUJBj3eUYCSTyyb3m9KPwB8ieX+FNQVnZHH0l+/WrTztv U44sZb72pp5dg== Received: by mail-wr1-f53.google.com with SMTP id u1so27398509wrg.11 for ; Mon, 21 Feb 2022 06:31:41 -0800 (PST) X-Gm-Message-State: AOAM533lov7GTV2pclFFzcDozHoGtFt1WGDYpchHp7xYtZU4V94fUvNA WyeMPyXetXYnRJ2y7CK1IvB1t2NKEekrk8c89iA= 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 Cc: Linus Torvalds , Christoph Hellwig , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Al Viro , Russell King - ARM Linux , Will Deacon , Guo Ren , Brian Cain , Geert Uytterhoeven , Michal Simek , 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-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" X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dWMiI8z7; spf=pass (imf17.hostedemail.com: domain of arnd@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=arnd@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4FC044000C X-Stat-Signature: xhy8u7bsz4mnmsdczygu6oodkn97pfto X-HE-Tag: 1645453903-359291 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 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