> -----Original Message----- > From: Garrett Cooper [mailto:[email protected]] > Sent: Thursday, October 21, 2010 6:42 PM > To: Mitani > Cc: [email protected] > Subject: Re: [LTP] POSIX "aio_return/2-1" failed. > > On Mon, Oct 18, 2010 at 5:00 AM, Garrett Cooper <[email protected]> > wrote: > > On Thu, Oct 7, 2010 at 10:29 PM, Mitani <[email protected]> wrote: > >> Hi, > >> > >> > >> "conformance/interfaces/aio_return/2-1" failed with following > message: > >> ------------ > >> conformance/interfaces/aio_return/2-1: execution: FAILED: Output: > >> aio_return/2-1.c Second call to aio_return() should return -1 : 111 > >> ------------ > >> > >> Same problem occurs in "aio_return/3-2.c" and "aio_return/4-1". > >> > >> Environment is as follows: > >> - RHEL5.5 --- (x86, x86_64, ia64) > >> - RHEL4.8 --- (x86, x86_64, ia64) > >> > >> > >> This testset seems to be the error root test for "aio_return()". > >> > >> First "aio_return()" returned with 111. This return value is the > >> length of buffer of "aio_write()". > >> But second "aio_return()" returned with 111, too. It's unexpected > >> result for this test set. > >> Therefore, this test failed. > >> > >> Man page says that > >> "This function should be called only once for any given request, > >> after > >> aio_error(2) returns something other than EINPROGRESS.": > >> ------------ > >> # LANG=C man 3 aio_return > >> > >> AIO_RETURN(3) Linux Programmer's Manual > >> AIO_RETURN(3) > >> > >> NAME > >> aio_return - get return status of asynchronous I/O operation > >> > >> SYNOPSIS > >> #include <aio.h> > >> > >> ssize_t aio_return(struct aiocb *aiocbp); > >> > >> DESCRIPTION > >> The aio_return function returns the final return status for > the > >> asynchronous I/O > >> request with control block pointed to by aiocbp. > >> > >> This function should be called only once for an > y given > >> request, after > >> aio_error(2) returns something other than EINPROGRESS. > >> > >> RETURN VALUE > >> If the asynchronous I/O operation has completed, this > function > >> returns the value > >> that would have been returned in case of a > synchronous read, > >> write, or fsync > >> request. Otherwise the return value is undefined. On > error, > >> the error value is > >> returned. > >> > >> ERRORS > >> EINVAL aiocbp does not point at a control block for an > >> asynchronous I/O request > >> of which the return status has not been retrieved > yet. > >> > >> CONFORMING TO > >> POSIX 1003.1-2003 > >> > >> SEE ALSO > >> aio_cancel(3), aio_error(3), aio_fsync(3), aio_r > ead(3), > >> aio_suspend(3), > >> aio_write(3) > >> > >> 2003-11-14 > >> AIO_RETURN(3) > >> # > >> ------------ > >> > >> And, it says that > >> "If the asynchronous I/O operation has completed, this function > >> returns the value that would have been returned in case of a > >> synchronous read, write, or fsync request. Otherwise the return > >> value is undefined. On error, the error value is returned.". > >> > >> > >> It can be supposed that the return value of second "aio_return()" > is > >> undefined. > >> Therefore, it is not mistake that return value of the second > "aio_return()" > >> is one at success, I think. > >> And, I think that "UNTESTED" or "UNRESOLVED" may be is more > >> appropriate for this test. > > > > No. POSIX clearly states: > > > > "If the asynchronous I/O operation has completed, then the return > > status, as described for read(), write(), and fsync(), shall be > > returned. If the asynchronous I/O operation has not yet completed, > the > > results of aio_return() are undefined. > > > > If the aio_return() function fails, it shall return -1 and set errno > > to indicate the error." > > > > ERRORS > > > > "The aio_return() function may fail if: > > > > [EINVAL] > > The aiocbp argument does not refer to an asynchronous operation > > whose return status has not yet been retrieved." > > > > What the test implementers were looking to do was test out that > -1 > > / EINVAL were returned, and maybe that fact that they were testing > was > > in fact implementation defined, as opposed to what's stated in the > > standard, as the spec doesn't state that the behavior for aio_return > > would be s.t. the state of the AIO stream is reset when aio_return > is > > called. > > So yes, I agree this should be fixed, but let me check with the > > POSIX folks what the best course of action is. > > I've read into this a bit more, and I think that the aio_return > testcases were written incorrectly. Please try out this testcase... > if it works for you, then I'll apply necessary logic to other testcases > as well. > It worked for me at least on FreeBSD. > Thanks, > -Garrett
I confirmed that your revision worked in my environment. I also look forward to other testcases (2-1, 3-2, 4-1) being revised. Thank you-- -Tomonori Mitani ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
