[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x49k1wg1tp9.fsf@segfault.boston.devel.redhat.com>
Date: Wed, 17 Jan 2018 08:49:22 -0500
From: Jeff Moyer <jmoyer@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: Al Viro <viro@...IV.linux.org.uk>, Avi Kivity <avi@...lladb.com>,
linux-aio@...ck.org, linux-fsdevel@...r.kernel.org,
netdev@...r.kernel.org, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 32/32] aio: implement io_pgetevents
Christoph Hellwig <hch@....de> writes:
> On Wed, Jan 17, 2018 at 04:27:21AM +0000, Al Viro wrote:
>> On Tue, Jan 16, 2018 at 07:41:24PM -0500, Jeff Moyer wrote:
>> > if (sigmask) {
>> > - if (copy_from_user(&ksigmask, sigmask, sizeof(ksigmask)))
>> > + if (!access_ok(VERIFY_READ, sigmask,
>> > + sizeof(void *) + sizeof(size_t)) ||
>> > + __get_user(up, (sigset_t __user * __user *)sigmask) ||
>> > + __get_user(sigsetsize,
>> > + (size_t __user *)(sigmask + sizeof(void *))))
>> > return -EFAULT;
>>
>> How about copy_from_user() on a struct? Making eyes bleed is fun, but
>> people tend to get annoyed when you do it to them...
>
> Above is the copy & paste version from pselect. I've got both copy_from_user
> and that horrible version in my tree, and if we really need this awfull
> calling convention copy_from_user certainly is much better. pselect
> also should be switched to explicit struct + copy_from_user while
> we're at it. In fact glibc defines a struct for the userland version
> to start with.
Yeah, I did both, but stuck with this variant as that's what pselect
did. I'm fine with switching to the struct variant.
-Jeff
Powered by blists - more mailing lists