Re: Cross Memory Attach v3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christopher,

On Mon, Nov 21, 2011 at 01:13, Christopher Yeoh <cyeoh@xxxxxxxxxxx> wrote:
On Sun, 20 Nov 2011 11:16:17 +0100
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
On Mon, Jul 18, 2011 at 17:05, Christopher Yeoh <cyeoh@xxxxxxxxxxx>
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.

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.

It turned out the flags parameter was non-zero, due to syscall() only supporting
up to 5 parameters in the glibc I was using for testing.

I checked the eglibc sources (2.11.1-0ubuntu7.8), and it's still not
fixed there,
although I could find a fix for a similar issue in klibc
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334917).

When forcing flags to zero, it works ;-)
So sorry for bothering you.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux