From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933924AbdC3N1t (ORCPT <rfc822;w@1wt.eu>);
        Thu, 30 Mar 2017 09:27:49 -0400
Received: from mail-qt0-f196.google.com ([209.85.216.196]:33821 "EHLO
        mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933816AbdC3N1p (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 30 Mar 2017 09:27:45 -0400
MIME-Version: 1.0
In-Reply-To: <CACVxJT8+fQqvpSPb9rTWFy6g7moqUqxi+Ewjcg0ykuqo=vm4Ow@mail.gmail.com>
References: <CACVxJT8+fQqvpSPb9rTWFy6g7moqUqxi+Ewjcg0ykuqo=vm4Ow@mail.gmail.com>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Thu, 30 Mar 2017 16:27:43 +0300
Message-ID: <CACVxJT8XeP37yivEP1k-8DSA_oUcpD4vhwYtud-Vdoy4tdJyNg@mail.gmail.com>
Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux Kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

[cc linux-kernel]

On Thu, Mar 30, 2017 at 4:25 PM, Alexey Dobriyan <adobriyan@gmail.com> wrote:
>> void *to, const void *from, unsigned long size
>
> Type of the last argument should be "unsigned int",
> for the following reasons:
> * on x86_64 actual copying is done as 32-bit: types flip to "unsigned"
>   at some point and 32-bit registers are used in assembly
>
> * 4GB+ copies simply do not exist:
>   kernel doesn't have data structures that big,
>
>   huge copies are done with cond_resched() in between
>   (with or without proxy pages),
>
>   even if they exist, they do not work on x86_64 now and can be
>   trivially wrapped as copy_from_user64() or something.
>
>   VFS truncates everything at INT_MAX exactly to not deal with all
>   the bugs associated with implicit type conversions.
>
> * Binary code becomes smaller: it doesn't matter for constant sizes,
>   but people tend to maintain type "safety" by using size_t and
>   do 64-bit arithmetic where it is unnecessary. I've sent some
>   patches to networking people already and have much more
>   which exterminate "size_t" from net/ and they give smaller code
>   size overall.
>
> Same arguments apply to kmalloc(), strlen(), memcpy() and
> all functions which are "size_t len".
>
> There was one time when Xen(?) people asked for 64-bit memcpy(),
> I can't remember any other example.
>
>     A