From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933186AbdC3A1q (ORCPT ); Wed, 29 Mar 2017 20:27:46 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:34426 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752253AbdC3A1m (ORCPT ); Wed, 29 Mar 2017 20:27:42 -0400 MIME-Version: 1.0 In-Reply-To: <09ead054-f62a-76e2-88e0-8d18592d2604@synopsys.com> References: <20170329055706.GH29622@ZenIV.linux.org.uk> <3399faa9-795e-39db-42f5-7d1e10bbff9c@synopsys.com> <20170329202939.GI29622@ZenIV.linux.org.uk> <32129bc4-0e0a-c21d-0e94-67f73a09ac6e@synopsys.com> <20170329234246.GL29622@ZenIV.linux.org.uk> <09ead054-f62a-76e2-88e0-8d18592d2604@synopsys.com> From: Linus Torvalds Date: Wed, 29 Mar 2017 17:27:40 -0700 X-Google-Sender-Auth: plQr3vsZmz4Vy3NfFTg5ne23zNU Message-ID: Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification To: Vineet Gupta Cc: Al Viro , "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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 29, 2017 at 5:02 PM, Vineet Gupta wrote: > > I guess I can in next day or two - but mind you the inline version for ARC is kind > of special vs. other arches. We have this "manual" constant propagation to elide > the unrolled LD/ST for 1-15 byte stragglers, when @sz is constant. I don't think that's special. We do that on x86 too, and I suspect ARC copied it from there (or from somebody else who did it). But at least on x86 is is limited entirely to the "__" versions, and it's almost entirely pointless. We actually removed some of that kind of code because it was *do* pointless, and it had just been copied around into the "atomic" versions too. See for example commit bd28b14591b9 ("x86: remove more uaccess_32.h complexity"), which did that. The basic "__" versions still do that constant-size thing, but they really are questionable. Exactly because it's just the "__" versions - the *regular* "copy_to/from_user()" is an unconditional function call, because inlining it isn't just the access operations, it's the size check, and on modern x86 it's also the "set AC to mark the user access as safe". .. and many distros enable some of the might_sleep() debugging code etc. With any of that, inlining is simply a *bad* choice. Linus