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 0759EC433F5 for ; Fri, 18 Feb 2022 09:21:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93F956B0075; Fri, 18 Feb 2022 04:21:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9169C6B0078; Fri, 18 Feb 2022 04:21:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 805DE6B007B; Fri, 18 Feb 2022 04:21:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id 748A36B0075 for ; Fri, 18 Feb 2022 04:21:01 -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 315ED18099212 for ; Fri, 18 Feb 2022 09:21:01 +0000 (UTC) X-FDA: 79155356322.28.1CF8984 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf01.hostedemail.com (Postfix) with ESMTP id 7E8A140006 for ; Fri, 18 Feb 2022 09:21:00 +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 6FCBBB825BF for ; Fri, 18 Feb 2022 09:20:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC600C340EF for ; Fri, 18 Feb 2022 09:20:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645176056; bh=iKhg0GBIaPe+CQxdRyb4Yd6fYvnOL1KGipyOpowy2ho=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=kGX6zbKnx1V58BNNLylZKoAuSF4ReIgBQqBt4dNQXGvgg2oi0HA/f9LUZVuwHyBWV mg5pCM9Rt+spQyje33QEp0c+aCuC8aKFt2FMZfRqn/7AXaofnUHDU/0en8KkeKXLv6 KABjo84/BhTe0Q0VHw7YDA7ZU0kHzYDUskwkfFWrQ37aBtp2SUFFlhvxE4zEdq3C6Y n20bhElsCWhy3qU9eja5s1kteeZAzqxIiwZZ6bEY9ZjBGZj4RXBRkBjrfFIX1l86n4 fwF6xBW0jhnf04cIEV6bo6qDfBixXNSEwg23XQj0Tfg9+ioxxTNxiurSMLHoQgfEhB wrFbaCMlSRtoA== Received: by mail-wr1-f47.google.com with SMTP id m27so1641198wrb.4 for ; Fri, 18 Feb 2022 01:20:56 -0800 (PST) X-Gm-Message-State: AOAM532Mwvofd57c2IQwFZvb0w8+5K04PCR0D6HAAYARMjVV8RbHdCS+ VEk0bRNGN0a8xnWNYRIahZdzlcGG4fnGfEj9fHY= X-Google-Smtp-Source: ABdhPJyGR3PQRCwNo0b6q27n8W/CBFQ1qGTyO2eZuzZDzHloL87fpnteJNso35Jub1TB9UHbj8TuXAAIoiRTkKAAdXc= X-Received: by 2002:a5d:59a3:0:b0:1e9:542d:1a35 with SMTP id p3-20020a5d59a3000000b001e9542d1a35mr816366wrr.192.1645176055050; Fri, 18 Feb 2022 01:20:55 -0800 (PST) MIME-Version: 1.0 References: <20220216131332.1489939-1-arnd@kernel.org> <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> In-Reply-To: From: Arnd Bergmann Date: Fri, 18 Feb 2022 10:20:38 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good To: Al Viro Cc: Christophe Leroy , Linus Torvalds , Christoph Hellwig , "linux-arch@vger.kernel.org" , "linux-mm@kvack.org" , "linux-api@vger.kernel.org" , "arnd@arndb.de" , "linux-kernel@vger.kernel.org" , "mark.rutland@arm.com" , "dalias@libc.org" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "peterz@infradead.org" , "jcmvbkbc@gmail.com" , "guoren@kernel.org" , "sparclinux@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "will@kernel.org" , "ardb@kernel.org" , "linux-s390@vger.kernel.org" , "bcain@codeaurora.org" , "deller@gmx.de" , "x86@kernel.org" , "linux@armlinux.org.uk" , "linux-csky@vger.kernel.org" , "mingo@redhat.com" , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , "hca@linux.ibm.com" , "linux-alpha@vger.kernel.org" , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "green.hu@gmail.com" , "shorne@gmail.com" , "monstr@monstr.eu" , "tsbogend@alpha.franken.de" , "linux-parisc@vger.kernel.org" , "nickhu@andestech.com" , "linux-mips@vger.kernel.org" , "dinguyen@kernel.org" , "ebiederm@xmission.com" , "richard@nod.at" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" , "davem@davemloft.net" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kGX6zbKn; spf=pass (imf01.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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7E8A140006 X-Stat-Signature: q7pz3kw5ddjxcbfopt4her7yuao7rszi X-HE-Tag: 1645176060-100073 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: n Fri, Feb 18, 2022 at 3:21 AM Al Viro wrote: > > On Thu, Feb 17, 2022 at 08:49:59AM +0100, Arnd Bergmann wrote: > > > Same here: architectures can already provide a __put_user_fn() > > and __get_user_fn(), to get the generic versions of the interface, > > but few architectures use that. You can actually get all the interfaces > > by just providing raw_copy_from_user() and raw_copy_to_user(), > > but the get_user/put_user versions you get from that are fairly > > inefficient. > > FWIW, __{get,put}_user_{8,16,32,64} would probably make it easier to > unify. That's where the really variable part tends to be, anyway. > IMO __get_user_fn() had been a mistake. I've prototyped this now, to see what this might look like, see https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=generic-get_user-prototype This adds generic inline version of {__get,get,__put,put}_user() and converts x86 to (optionally) use it. This builds with gcc-5 through gcc-11 on 32-bit and 64-bit x86, using asm-goto with outputs where possible, and requiring a minimum set of macro definitions from the architecture. Compiling with clang produces no warnings but does cause a linker issue at the moment, so there is probably at least one bug in it. Aside from compile-testing, I have not tried to verify if this is correct or efficient, but let me know if you think this is headed in the right direction. > One thing I somewhat dislike about the series is the boilerplate in > asm/uaccess.h instances - #include in > a lot of them might make sense as a transitory state, but getting > stuck with those indefinitely... Christoph also complained about it, the problem for now is that asm-generic/access_ok.h must first see the macro definitions for architectures that override any of the contents, but access_ok() itself is used at least in some of the asm/uaccess.h files as well, so it must be included in the middle of it, until more of the uaccess.h implementation is moved to linux/uaccess.h in an architecture independent way. Would you prefer having an asm/access_ok.h that falls back to the asm-generic version but can have an architecture specific override when needed (ia64, arm64, x86, um)? > BTW, do we need user_addr_max() anymore? The definition in > asm-generic/access-ok.h is the only one, so ifndef around it is pointless. Right, the v2 changes got rid of the last override, so it could get hardcoded to TASK_SIZE_MAX, or we can convert the five references to just use that instead and remove it altogether: arch/arm64/kernel/traps.c: if (address >= user_addr_max()) { \ arch/parisc/kernel/signal.c: if (start >= user_addr_max() - sigframe_size) arch/parisc/kernel/signal.c: if (A(&usp[0]) >= user_addr_max() - 5 * sizeof(int)) lib/strncpy_from_user.c: max_addr = user_addr_max(); lib/strnlen_user.c: max_addr = user_addr_max(); user_addr_max() first showed up in architecture-independent code in c5389831cda3 ("sparc: Fix user_addr_max() definition."), and from that I think the original intent is no longer useful. Arnd