linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed
@ 2020-10-26 22:55 Kyle Huey
  2020-10-26 23:56 ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Kyle Huey @ 2020-10-26 22:55 UTC (permalink / raw)
  To: open list, Christoph Hellwig
  Cc: Robert O'Callahan, Alexander Viro, Andrew Morton, Jens Axboe,
	Arnd Bergmann, David Howells, moderated list:ARM PORT,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-mips, linux-parisc, linuxppc-dev, linux-s390, sparclinux,
	linux-block, linux-scsi,
	open list:FILESYSTEMS (VFS and infrastructure),
	linux-aio, io-uring, linux-arch, linux-mm, netdev, keyrings,
	linux-security-module, Linus Torvalds

A test program from the rr[0] test suite, vm_readv_writev[1], no
longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
on a 64 bit kernel. The first process_vm_readv call (on line 35) now
fails with EFAULT. I have bisected this to
c3973b401ef2b0b8005f8074a10e96e3ea093823.

It should be fairly straightforward to extract the test case from our
repository into a standalone program.

- Kyle

[0] https://rr-project.org/
[1] https://github.com/mozilla/rr/blob/master/src/test/vm_readv_writev.c

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed
  2020-10-26 22:55 [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed Kyle Huey
@ 2020-10-26 23:56 ` Jens Axboe
  2020-10-27  0:05   ` Al Viro
  0 siblings, 1 reply; 4+ messages in thread
From: Jens Axboe @ 2020-10-26 23:56 UTC (permalink / raw)
  To: Kyle Huey, open list, Christoph Hellwig
  Cc: Robert O'Callahan, Alexander Viro, Andrew Morton,
	Arnd Bergmann, David Howells, moderated list:ARM PORT,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-mips, linux-parisc, linuxppc-dev, linux-s390, sparclinux,
	linux-block, linux-scsi,
	open list:FILESYSTEMS (VFS and infrastructure),
	linux-aio, io-uring, linux-arch, linux-mm, netdev, keyrings,
	linux-security-module, Linus Torvalds

On 10/26/20 4:55 PM, Kyle Huey wrote:
> A test program from the rr[0] test suite, vm_readv_writev[1], no
> longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
> on a 64 bit kernel. The first process_vm_readv call (on line 35) now
> fails with EFAULT. I have bisected this to
> c3973b401ef2b0b8005f8074a10e96e3ea093823.
> 
> It should be fairly straightforward to extract the test case from our
> repository into a standalone program.

Can you check with this applied?

diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index fd12da80b6f2..05676722d9cd 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -273,7 +273,8 @@ static ssize_t process_vm_rw(pid_t pid,
 		return rc;
 	if (!iov_iter_count(&iter))
 		goto free_iov_l;
-	iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r, false);
+	iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r,
+				in_compat_syscall());
 	if (IS_ERR(iov_r)) {
 		rc = PTR_ERR(iov_r);
 		goto free_iov_l;

-- 
Jens Axboe


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed
  2020-10-26 23:56 ` Jens Axboe
@ 2020-10-27  0:05   ` Al Viro
  2020-10-27  0:09     ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Al Viro @ 2020-10-27  0:05 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Kyle Huey, open list, Christoph Hellwig, Robert O'Callahan,
	Andrew Morton, Arnd Bergmann, David Howells,
	moderated list:ARM PORT,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-mips, linux-parisc, linuxppc-dev, linux-s390, sparclinux,
	linux-block, linux-scsi,
	open list:FILESYSTEMS (VFS and infrastructure),
	linux-aio, io-uring, linux-arch, linux-mm, netdev, keyrings,
	linux-security-module, Linus Torvalds

On Mon, Oct 26, 2020 at 05:56:11PM -0600, Jens Axboe wrote:
> On 10/26/20 4:55 PM, Kyle Huey wrote:
> > A test program from the rr[0] test suite, vm_readv_writev[1], no
> > longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
> > on a 64 bit kernel. The first process_vm_readv call (on line 35) now
> > fails with EFAULT. I have bisected this to
> > c3973b401ef2b0b8005f8074a10e96e3ea093823.
> > 
> > It should be fairly straightforward to extract the test case from our
> > repository into a standalone program.
> 
> Can you check with this applied?
> 
> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
> index fd12da80b6f2..05676722d9cd 100644
> --- a/mm/process_vm_access.c
> +++ b/mm/process_vm_access.c
> @@ -273,7 +273,8 @@ static ssize_t process_vm_rw(pid_t pid,
>  		return rc;
>  	if (!iov_iter_count(&iter))
>  		goto free_iov_l;
> -	iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r, false);
> +	iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r,
> +				in_compat_syscall());

_ouch_

There's a bug, all right, but I'm not sure that this is all there is to it.
For now it's probably the right fix, but...  Consider the fun trying to
use that from 32bit process to access the memory of 64bit one.  IOW, we
might want to add an explicit flag for "force 64bit addresses/sizes
in rvec".

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed
  2020-10-27  0:05   ` Al Viro
@ 2020-10-27  0:09     ` Jens Axboe
  0 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2020-10-27  0:09 UTC (permalink / raw)
  To: Al Viro
  Cc: Kyle Huey, open list, Christoph Hellwig, Robert O'Callahan,
	Andrew Morton, Arnd Bergmann, David Howells,
	moderated list:ARM PORT,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-mips, linux-parisc, linuxppc-dev, linux-s390, sparclinux,
	linux-block, linux-scsi,
	open list:FILESYSTEMS (VFS and infrastructure),
	linux-aio, io-uring, linux-arch, linux-mm, netdev, keyrings,
	linux-security-module, Linus Torvalds

On 10/26/20 6:05 PM, Al Viro wrote:
> On Mon, Oct 26, 2020 at 05:56:11PM -0600, Jens Axboe wrote:
>> On 10/26/20 4:55 PM, Kyle Huey wrote:
>>> A test program from the rr[0] test suite, vm_readv_writev[1], no
>>> longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
>>> on a 64 bit kernel. The first process_vm_readv call (on line 35) now
>>> fails with EFAULT. I have bisected this to
>>> c3973b401ef2b0b8005f8074a10e96e3ea093823.
>>>
>>> It should be fairly straightforward to extract the test case from our
>>> repository into a standalone program.
>>
>> Can you check with this applied?
>>
>> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
>> index fd12da80b6f2..05676722d9cd 100644
>> --- a/mm/process_vm_access.c
>> +++ b/mm/process_vm_access.c
>> @@ -273,7 +273,8 @@ static ssize_t process_vm_rw(pid_t pid,
>>  		return rc;
>>  	if (!iov_iter_count(&iter))
>>  		goto free_iov_l;
>> -	iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r, false);
>> +	iov_r = iovec_from_user(rvec, riovcnt, UIO_FASTIOV, iovstack_r,
>> +				in_compat_syscall());
> 
> _ouch_
> 
> There's a bug, all right, but I'm not sure that this is all there is
> to it. For now it's probably the right fix, but...  Consider the fun
> trying to use that from 32bit process to access the memory of 64bit
> one.  IOW, we might want to add an explicit flag for "force 64bit
> addresses/sizes in rvec".

Ouch yes good point, nice catch.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-10-27  0:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-26 22:55 [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed Kyle Huey
2020-10-26 23:56 ` Jens Axboe
2020-10-27  0:05   ` Al Viro
2020-10-27  0:09     ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).