Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932968AbdC2VDi (ORCPT ); Wed, 29 Mar 2017 17:03:38 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:49184 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932509AbdC2VDg (ORCPT ); Wed, 29 Mar 2017 17:03:36 -0400 Date: Wed, 29 Mar 2017 22:03:23 +0100 From: Al Viro To: Linus Torvalds Cc: Vineet Gupta , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Richard Henderson , Russell King , Will Deacon , Haavard Skinnemoen , Steven Miao , Jesper Nilsson , Mark Salter , Yoshinori Sato , Richard Kuo , Tony Luck , Geert Uytterhoeven , James Hogan , Michal Simek , David Howells , Ley Foon Tan , Jonas Bonn , Helge Deller , Martin Schwidefsky , Ralf Baechle , Benjamin Herrenschmidt , Chen Liqin , "David S. Miller" , Chris Metcalf , Richard Weinberger , Guan Xuetao , Thomas Gleixner , Chris Zankel Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification Message-ID: <20170329210322.GJ29622@ZenIV.linux.org.uk> References: <20170329055706.GH29622@ZenIV.linux.org.uk> <3399faa9-795e-39db-42f5-7d1e10bbff9c@synopsys.com> <20170329202939.GI29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1687 Lines: 34 On Wed, Mar 29, 2017 at 01:37:30PM -0700, Linus Torvalds wrote: > On Wed, Mar 29, 2017 at 1:29 PM, Al Viro wrote: > > > > BTW, I wonder if inlining all of the copy_{to,from}_user() is actually a win. > > I would suggest against it. > > The only part I think is worth inlining is the compile time size > checks for kasan - and that only because of the obvious "sizes are > constant only when inlining" issue. > > We used to inline a *lot* of user accesses historically, pretty much > all of them were bogus. > > The only ones that really want inlining are the non-checking ones that > people should never use directly, but that are just helper things used > by other routines (ie the "unsafe_copy_from_user()" kind of things > that are designed for strncpy_from_user()). > > Once you start checking access ranges, and have might_fault debugging > etc, it shouldn't be inlined. FWIW, that's why I'd put those knobs (INLINE_COPY_{TO,FROM}_USER) in there; if for some architectures making those inlined is really a win, they can request the inlining; for now I'd mostly set them to match what architectures had been doing, but I also strongly suspect that in a lot of cases that inlining is counterproductive. Building it both ways is simply a matter of deleting those two lines in asm/uaccess.h in question, and if testing shows that out-of-line works better on given architecture, well... I would expect that the final variant will have those remain only on a few architectures. IMO decision whether to inline them or not is up to architecture - it's not as if having the possibility to inline them would really complicate the generic side of things...