lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 21 Nov 2011 10:43:13 +1030
From:	Christopher Yeoh <cyeoh@....ibm.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-man@...r.kernel.org,
	linux-arch@...r.kernel.org,
	"Linux/m68k" <linux-m68k@...r.kernel.org>
Subject: Re: Cross Memory Attach v3

Hi Geert,

On Sun, 20 Nov 2011 11:16:17 +0100
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Mon, Jul 18, 2011 at 17:05, Christopher Yeoh <cyeoh@....ibm.com>
> wrote:
> > For arch maintainers there are some simple tests to be able to
> > quickly verify that the syscalls are working correctly here:
> 
> I'm wiring up these new syscalls on m68k.
> 
> > http://ozlabs.org/~cyeoh/cma/cma-test-20110718.tgz
> 
> The included README talks about:
> 
>     setup_process_readv_simple
>     setup_process_readv_iovec
>    setup_process_writev
> 
> while the actual test executables are called:
> 
>     setup_process_vm_readv_simple
>     setup_process_vm_readv_iovec
>     setup_process_vm_writev

Oops. Have fixed this and uploaded a new version

 http://ozlabs.org/~cyeoh/cma/cma-test-20111121.tgz

It also includes another minor change (see below)

> On m68k (ARAnyM), the first and third test succeed. The second one
> fails, though:
> 
> # Setting up target with num iovecs 10, test buffer size 100000
> Target process is setup
> Run the following to test:
> ./t_process_vm_readv_iovec 1574 10 0x800030b0 89 0x80003110 38302
> 0x8000c6b8 22423 0x80011e58 18864 0x80016810 583 0x80016a60 8054
> 0x800189e0 3417 0x80019740 368 0x800198b8 897 0x80019c40 7003
> 
> and in the other window:
> 
> # ./t_process_vm_readv_iovec 1574 10 0x800030b0 89 0x80003110 38302
> 0x8000c6b8 22423 0x80011e58 18864 0x80016810 583 0x80016a60 8054
> 0x800189e0 3417 0x80019740 368 0x800198b8 897 0x80019c40 7003
> copy_from_process failed: Invalid argument

That should say process_vm_readv instead of copy_from_process. The
error message is fixed in the just updated test.

> error code: 29
> #
> 
> Any suggestions?
> 

Given that the first and third tests succeed, I think the problem is
with the iovec parameters. The -EINVAL is most likely coming from
rw_copy_check_uvector. Any chance that something bad is
happening to lvec/liovcnt or rvec/riovcnt in the wireup? 

The iovecs are checked in process_vm_rw before the core of the
process_vm_readv/writev code is called so should be easy to confirm if
this is the problem.

The other couple of places where it could possibly come from is that
for some reason the flags parameter ends up being non zero or when
looking up the task the mm is NULL. But given that the first and second
tests succeed I think its unlikely that either of these is the cause.

Regards,

Chris
-- 
cyeoh@...ibm.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ