Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp642987pxy; Wed, 28 Apr 2021 11:05:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKaWRVmSducvTWlg7zeFEDxoSEE/Ron9iNl0s4MDfd2SQRB60kkZ5oZA/7cRzlw6h+8B+d X-Received: by 2002:a63:6d04:: with SMTP id i4mr27904725pgc.97.1619633106408; Wed, 28 Apr 2021 11:05:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619633106; cv=none; d=google.com; s=arc-20160816; b=a7cUOtmSnbCmXjA/KC68YHLl+ZuplVmebCEjKHhXpogRupuB0FDUVOIhfj6dwnU8xd TH3PBYQBDLJP5jPUiCCiA/Jdk6bAcEglel6/f7EpGl0GFSjGTHHkoits7p/r9HFiDPlT DCfzqsnKBnf5OtuJPWna2X1qBLS8pevhPFXhsqkEm30cyXtpefcIRwgpthsDGpSe+T6K UI5I+zzhtACkKgIk2pU5Gwt5c51RWIha1Wt7tyYyYvEYqmiPUlkI6N+ufB/a7BeHkxB7 qX+fUiJWLPKWVte+uqNjGzk1zeUK6EJc5dFVfq5ULvCNXFv4cQRVguS6B/71awSuHTso zMXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=E6hz3YR6yH9IvC5ygVzOjzQEfVG2g6hAGVcKYshS+bM=; b=vU/5qZ0NglvliBhcJ5Z9CG6CuklUITyySgke1ku6oIUMCF/408Ucu9bv88mVwaWf12 VjcGcx1aQuEKr2KeyrfotmX+J0up4S6wxFT7rLwIhVtr/gNhXOxGVQl35j3pytVmAcWq ncYSkzlK92xgDOV5lrSztRrTV1zpe1EhZ/1qhH8glU8cjw5UT8JxDHwLTPVjzJx8XTFW OQoYuZMSLUYKObqfIujPxswUssuP8Swj905izk12FVqAXVxxMHV0L9lcGqkLkwB0ksSS RHvPzqCJvrwnwuWl5LXQ7+AMbTAf0+nRvroLg0EsutpbVdwScFFrn/54DXtY9sWrSp1l Y1tw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c17si372511pgv.34.2021.04.28.11.04.46; Wed, 28 Apr 2021 11:05:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231218AbhD1Ntx (ORCPT + 99 others); Wed, 28 Apr 2021 09:49:53 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:39201 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238444AbhD1Ntu (ORCPT ); Wed, 28 Apr 2021 09:49:50 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Mdv2u-1l4KgT2ejG-00b09Q; Wed, 28 Apr 2021 15:49:03 +0200 Received: by mail-wr1-f48.google.com with SMTP id a4so63164915wrr.2; Wed, 28 Apr 2021 06:49:03 -0700 (PDT) X-Gm-Message-State: AOAM530uAp/LCL/eqZMGrVBLi8LTegYVODwwEwoa6iJVbQO3GrjCLJ3U ooV4APg0MWOToXzK6fWpE5/BmHut9FOp5z0X80E= X-Received: by 2002:a5d:6dc4:: with SMTP id d4mr37595126wrz.105.1619617743312; Wed, 28 Apr 2021 06:49:03 -0700 (PDT) MIME-Version: 1.0 References: <1618995255-91499-1-git-send-email-guoren@kernel.org> <20210428031807.GA27619@roeck-us.net> <20210428124946.GA1976154@infradead.org> In-Reply-To: <20210428124946.GA1976154@infradead.org> From: Arnd Bergmann Date: Wed, 28 Apr 2021 15:48:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] csky: uaccess.h: Coding convention with asm generic To: Christoph Hellwig Cc: Guo Ren , Guenter Roeck , Linux Kernel Mailing List , linux-csky@vger.kernel.org, linux-arch , Guo Ren Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:dTNYuGf/bvjL1/vBcUqA84N+2PSTHBRjrnCFO1sEjBfhjLfRrFM ik29EUnDS/2CDpEpQBS1zSiZrJ8DgxjPeOVoKtgSYm9pK6f+MAhpB8VmIbJhWljcx6BkLzC RrcTa6U0hgzk9rIZxIQBGU46fn2K3tOVq2bydtMjrRvpC4C4c0PRTpFEioicHaot/fm4UsL rI9u88RJn9RLb+N5b1Rkg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:6NC2b99wojw=:Mt30fKiy7lF31UI1DLD+c8 xzmGRzOZYmpfwdhoJsRp9VtJhM3qAumf8nDTp9i/6zJQJPmrwHSZftVp1z+5iHVNBqJ6chKod ifN3nyuJPxj1AXzrNUqRtZmRziVMrJbbGRaYX6hI2BQhyDenvL7q56YXlxBgawlBZzyz2DnwG mB95YO5+oBCgMwzxlYbr6JJ/YoHrTlB8psdvKTh4MzcXazGeRgdP9WQGVMBoqDqUjdCMo3oFJ sF+Rw/HC5VZ+Gqr0nUNDp/U441JJV37oXVdwdopXAzdtvj5FlO8Hne3hW3nFgnSvUZnFa+zEK 7jzqw6NtN7p69av0/h7vY40E0fHIA/UbUPKc9DPommxigKCpQ/bfblH5dpu2IzBcVqA9wbGVF TxuQA2D+slSwAD78Om6Kf+QDcD7CTbQiPszjcWjRWFk0XVdP8RRfF3li7OQu2Sg+zaY4TEvkj UUK8mPivoPPxlOIx5CdW5mkDylG9+mRzDvyUquYkC4CV8gZkDAwfvxs5YwWggccKZ/DMHuSv+ nBwjdgZyruLaivqkZr4DZI= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 28, 2021 at 2:49 PM Christoph Hellwig wrote: > On Wed, Apr 28, 2021 at 11:25:29AM +0200, Arnd Bergmann wrote: > > We might want to come up with a new version of asm-generic/uaccess.h > > that actually makes it easier to have a sane per-architecture > > implementation of the low-level accessors without set_fs(). > > > > I've added Christoph to Cc here, he probably has some ideas > > on where we should be heading. > > I think asm-generic/uaccess.h pretty much only makes sense for > nommu. For that case we can just kill the __{get,put}_user_fn > indirection. I actually have work for that in an old branch. > > Trying to use any of asm-generic/uaccess.h for MMU based kernel is > just asking for trouble. The one thing I'd like to see is a generic implementation of the outer bit that implements handling the variable-length arguments, there are so many ways that people have gotten that wrong in the past, and it would be nice if architectures only had to implement a set of fixed-size accessors that contain the architecture specific inline asm. There is now a new version for x86 that based on asm-goto with output, which should in theory provide a better implementation for any architecture when using gcc-11/clang-11 or higher. > > One noteworthy aspect is that almost nothing users the low-level > > __get_user()/__put_user() helpers any more outside of architecture > > specific code, so we may not need to have separate versions > > for much longer. > > Al has been trying to kill them off entirely for a while, and I hope > he'll eventually succeed. That being said the difference should be > that the __ versions just skip the access_ok, so having both is > fairly trivial to implement. That is the difference in the interface, but in some of architectures there is another difference in that the __ version is completely inlined while the normal version calls an external function. I could never quite figure out the reason for this difference. Arnd