Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932906AbdC2VZD (ORCPT ); Wed, 29 Mar 2017 17:25:03 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:33081 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752050AbdC2VYj (ORCPT ); Wed, 29 Mar 2017 17:24:39 -0400 MIME-Version: 1.0 In-Reply-To: <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> <20170329210322.GJ29622@ZenIV.linux.org.uk> From: Linus Torvalds Date: Wed, 29 Mar 2017 14:24:37 -0700 X-Google-Sender-Auth: UZPrQL3lySsdfuuZ3-kEfxKfx8g Message-ID: Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification To: Al Viro 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 943 Lines: 26 On Wed, Mar 29, 2017 at 2:03 PM, Al Viro wrote: > > it's not as if having the possibility to inline them > would really complicate the generic side of things... I disagree. I think one of the biggest problems with our current uaccess.h mess is just how illegible the header files are, and the INLINE_COPY_{TO,FROM}_USER thing is not helping. I think it would be much better if the header file just had extern unsigned long _copy_from_user(void *, const void __user *, unsigned long); and nothing else. No unnecessary noise. The same goes for things like [__]copy_in_user() - why is that thing still inlined? If it was a *macro*, it might be useful due to the might_fault() thing giving the caller information, but that's not even the case here, so we'd actually be much better off without any of that inlining stuff. Do it all in lib/usercopy.c, and move the might_fault() in there too. Linus