Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [PATCH] include/linux: avoid narrowing length parameter values
From: Louis Langholtz <lou_langholtz@me.com>
In-reply-to: <20150518155631.GX7232@ZenIV.linux.org.uk>
Date: Mon, 18 May 2015 14:43:39 -0600
Cc: linux-kernel@vger.kernel.org
Content-transfer-encoding: 8BIT
Message-id: <6BBC53A4-FEB2-44DA-BA80-B7780921FC59@me.com>
References: <45D183F5-DFCC-4FBF-833E-E738E098CF1D@me.com>
 <20150518155631.GX7232@ZenIV.linux.org.uk>
To: Al Viro <viro@zeniv.linux.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1954
Lines: 34

On May 18, 2015, at 9:56 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:

> On Mon, May 18, 2015 at 09:33:10AM -0600, Louis Langholtz wrote:
>> memcpy_from_msg() and memcpy_to_msg() functions previously called
>> memcpy_fromiovec() and memcpy_toiovec() functions respectively. The
>> memcpy_fromiovec() and memcpy_toiovec() functions took a length parameter
>> of type int. memcpy_from_msg() and memcpy_to_msg() now call
>> copy_from_iter() and copy_to_iter() functions respectively which take a length
>> parameter of type size_t. Most code calling the memcpy_from_msg() and
>> memcpy_to_msg() functions currently pass a length value of type size_t.
>> This patch updates the memcpy_from_msg() and memcpy_to_msg() functions
>> concordantly to take the length parameter of type size_t. This also avoids a potential
>> for data narrowing.
> 
> iov_iter for sendmsg or recvmsg *can't* have more than 2Gb of data; if it
> ever does, it's a serious bug.
> 
> IOW, NAK - that's pointless.

I understand that operationally the change is a no-op given the 2Gb limit you
point out. I still don't understand how using size_t instead of int is pointless
however. The change still increases consistency and adds semantically by
using the type (size_t) established for holding the size of an object.

If the position is that weak-typing is better, I can understand that; I just disagree
then. If the position is that u32 would be better (than int because it more closely
matches the 2Gb design limit presuming that the value also can't ever be
negative), I'd also understand not applying this patch and would agree with that
argument (although I'd be bothered then that so much of the relevant code is
already using size_t).--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/