Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933924AbdC3N1t (ORCPT ); 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 ); Thu, 30 Mar 2017 09:27:45 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Alexey Dobriyan Date: Thu, 30 Mar 2017 16:27:43 +0300 Message-ID: Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification To: Al Viro Cc: Andrew Morton , Linus Torvalds , Linux Kernel 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: 1369 Lines: 36 [cc linux-kernel] On Thu, Mar 30, 2017 at 4:25 PM, Alexey Dobriyan 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