I've worked on creating kernel side patch about this fix. > > > io_submit case always failed on ppc64. > > > > > > ---------- > > > [EMAIL PROTECTED] cvs_ltp]# uname -a > > > Linux ovislp1.upt.austin.ibm.com 2.6.18-92.el5 #1 SMP Tue Apr 29 > > > 13:21:29 EDT > > > 2008 ppc64 ppc64 ppc64 GNU/Linux > > > [EMAIL PROTECTED] cvs_ltp]# rpm -qa | grep libaio > > > libaio-0.3.106-3.2 > > > libaio-0.3.106-3.2 > > > libaio-devel-0.3.106-3.2 > > > libaio-devel-0.3.106-3.2 > > > [EMAIL PROTECTED] cvs_ltp]# > > > testcases/kernel/syscalls/io_submit/io_submit01 > > > io_submit01 1 PASS : expected failure - returned value = 22 : > > > Invalid argument > > > io_submit01 2 FAIL : unexpected returned value - -22 - expected > > > -14 > > > io_submit01 3 PASS : expected failure - returned value = 9 : Bad > > > file descriptor > > > > > > There could be an issue with the test case here. What is done is " > > > io_submit(ctx, 0, (void*)-1 ) ".So in compat_sys_io_submit(), we > > > allocate memory on the user space stack using > > > compat_alloc_user_space. > > > We then copy from the address specified in the syscall to the address > > > allocated via the compat_alloc_user_space call. Now, if the size > > > field > > > is zero, no copy takes place. This valid address (stack pointer or > > > an address close to it) is then used in sys_io_submit and we dont see > > > the EFAULT. In order to see this fault, we would have to set nr>0 and > > > copy_iocb() catches the invalid address specified in the system call. > > > Retrying the test with nr>0 results in an EFAULT. > > > > > > Signed-off-by: Sridhar Vinay <[EMAIL PROTECTED]> > > > Signed-off-by: Jin Bing Guo <[EMAIL PROTECTED]> > > I've understood the explanation and I've confirmed the correctness. > But I think the behavior of io_submit(ctx, 0, (void*)-1 ) on ppc64 is > interesting. So I don't like to throw io_submit(ctx, 0, (void*)-1 ) > test case away <A>. Also I'd like to dig the kernel more <B>. > > For <B> I'd like to submit following patch to lkml in the future: > diff --git a/fs/compat.c b/fs/compat.c > index 5f9ec44..5bfa69f 100644 > --- a/fs/compat.c > +++ b/fs/compat.c > @@ -584,6 +584,16 @@ compat_sys_io_submit(aio_context_t ctx_id, int nr, u32 > __user *iocb) > if (nr > MAX_AIO_SUBMITS) > nr = MAX_AIO_SUBMITS; > > + /* sys_io_submit() uses newly allocated buffer(iocb64) from safety > + area. But access_ok checking is needed to make the behavior > + of compat_sys_io_submit same to sys_io_submit. > + > + Without the checking > + comapt_sys_io_submit(ctx, 0, (void*)-1 ) returns -EINVAL. > + sys_io_submit(ctx, 0, (void*)-1 ) returns -EFAULT. */ > + if (unlikely(!access_ok(VERIFY_READ, iocb, (nr*sizeof(*iocb))))) > + return -EFAULT; > + > iocb64 = compat_alloc_user_space(nr * sizeof(*iocb64)); > ret = copy_iocb(nr, iocb, iocb64); > if (!ret) >
After taking much of my spare time, I've found above patch is meaningless because address pointed by iocb is always accessible. compat_sys_io_submit is invoked from 32bit context. Therefore, iocb passed to compat_sys_io_submit takes a value with range from 0x0000000 to 0xffffffff. However, compat_sys_io_submit is executed in 64bit context. So the value with the range is always valid. As the result access_ok always returns true. So no patch for kernel is needed. The io_submit test case in ltp is good enough. Masatake YAMATO ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
