[LTP] aio_error/3-1.c

[LTP] aio_error/3-1.c

[Cyril Hrubis]

Hi!
I've been reading POSIX documentation for some time now and even reading
glibc source code and the result is that aio_error/3-1.c doesn't test
anyting and should be removed.

The test is trying to assert EINVAL from aio_error accordingly to:

http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html

...

The aio_error() function may fail if:

	[EINVAL]
            The aiocbp argument does not refer to an asynchronous
	    operation whose return status has not yet been retrieved.

...


As far as I understand this, it's says you may get EINVAL if you call
aio_error() on finished aiocb second (and more) times.

This is implemented on linux as "return aiocb->__error_code" so IMHO
there is no way to test this.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] aio_error/3-1.c

[Cyril Hrubis]

Hi!
> > I've been reading POSIX documentation for some time now and even reading
> > glibc source code and the result is that aio_error/3-1.c doesn't test
> > anyting and should be removed.
> >
> > The test is trying to assert EINVAL from aio_error accordingly to:
> >
> > http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html
> >
> > ...
> >
> > The aio_error() function may fail if:
> >
> >        [EINVAL]
> >            The aiocbp argument does not refer to an asynchronous
> >            operation whose return status has not yet been retrieved.
> >
> > ...
> >
> >
> > As far as I understand this, it's says you may get EINVAL if you call
> > aio_error() on finished aiocb second (and more) times.
> >
> > This is implemented on linux as "return aiocb->__error_code" so IMHO
> > there is no way to test this.
> 
>     I think that the original developers misinterpreted the test
> requirements. aio_error is _always_ supposed to return errno values,
> not -1 and set the global errno. Otherwise it wouldn't make sense
> because asynchronous I/O would be more synchronous than anything else.

This is not the only problem here. Accordinly to POSIX aio_error() output is
defined only when you pass correct aiocb (that means struct aiocb that is
already used for some aio_{write,read,fsync,...}) and the value may not be
stored pernamently, so if you read it once, it could return EINVAL second time.


...

memset (&aiocb, 0, sizeof (struct aiocb));

aiocb.aio_fildes = fd;
aiocb.aio_buf = buf;
aiocb.aio_reqprio = -1;
aiocb.aio_nbytes = BUF_SIZE;

/*
 * Here return from aio_error() is not defined as
 * there was no aio operation done on aiocb.
 *
 * On linux you get value that is stored in struct aiocb->__error_code
 * and as aiocb is filled with zeroes on the beginning, this
 * returns also zero. 
 */
ret = aio_error(&aiocb);

if (aio_write(&aiocb) == -1) {
	/* quening write operation has failed */
	return 1;
}

/*
 * Wait for completion.
 */
while ((ret = aio_error(&aiocb)) == EINPROGRESS)
	sleep(1);

/* Here we have status from aio_write in ret */

/*
 * And here we may get EINVAL instead of status from previous
 * aio_write()
 */
ret = aio_error(&aiocb);


So what I'm saying is that if you really want to write correct test for 3-1.c
you need to:

1. Create aio data transfer
2. Wait for completion
3. Get aio return status by aio_error()
4. Get it once more and it should either be EINVAL or same value that you got first time.

Which seems to be a little dumb to test to me, so I vote for removing 3-1.c from ltp.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] aio_error/3-1.c

[Cyril Hrubis]

Hi!
> >>> > I've been reading POSIX documentation for some time now and even reading
> >>> > glibc source code and the result is that aio_error/3-1.c doesn't test
> >>> > anyting and should be removed.
> >>> >
> >>> > The test is trying to assert EINVAL from aio_error accordingly to:
> >>> >
> >>> > http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html
> >>> >
> >>> > ...
> >>> >
> >>> > The aio_error() function may fail if:
> >>> >
> >>> >        [EINVAL]
> >>> >            The aiocbp argument does not refer to an asynchronous
> >>> >            operation whose return status has not yet been retrieved.
> >>> >
> >>> > ...
> >>> >
> >>> >
> >>> > As far as I understand this, it's says you may get EINVAL if you call
> >>> > aio_error() on finished aiocb second (and more) times.
> >>> >
> >>> > This is implemented on linux as "return aiocb->__error_code" so IMHO
> >>> > there is no way to test this.
> >>>
> >>>     I think that the original developers misinterpreted the test
> >>> requirements. aio_error is _always_ supposed to return errno values,
> >>> not -1 and set the global errno. Otherwise it wouldn't make sense
> >>> because asynchronous I/O would be more synchronous than anything else.
> >>
> >> This is not the only problem here. Accordinly to POSIX aio_error() output is
> >> defined only when you pass correct aiocb (that means struct aiocb that is
> >> already used for some aio_{write,read,fsync,...}) and the value may not be
> >> stored pernamently, so if you read it once, it could return EINVAL second time.
> >>
> >>
> >> ...
> >>
> >> memset (&aiocb, 0, sizeof (struct aiocb));
> >>
> >> aiocb.aio_fildes = fd;
> >> aiocb.aio_buf = buf;
> >> aiocb.aio_reqprio = -1;
> >> aiocb.aio_nbytes = BUF_SIZE;
> >>
> >> /*
> >>  * Here return from aio_error() is not defined as
> >>  * there was no aio operation done on aiocb.
> >>  *
> >>  * On linux you get value that is stored in struct aiocb->__error_code
> >>  * and as aiocb is filled with zeroes on the beginning, this
> >>  * returns also zero.
> >>  */
> >> ret = aio_error(&aiocb);
> >>
> >> if (aio_write(&aiocb) == -1) {
> >>        /* quening write operation has failed */
> >>        return 1;
> >> }
> >>
> >> /*
> >>  * Wait for completion.
> >>  */
> >> while ((ret = aio_error(&aiocb)) == EINPROGRESS)
> >>        sleep(1);
> >>
> >> /* Here we have status from aio_write in ret */
> >>
> >> /*
> >>  * And here we may get EINVAL instead of status from previous
> >>  * aio_write()
> >>  */
> >> ret = aio_error(&aiocb);
> >>
> >>
> >> So what I'm saying is that if you really want to write correct test for 3-1.c
> >> you need to:
> >>
> >> 1. Create aio data transfer
> >> 2. Wait for completion
> >> 3. Get aio return status by aio_error()
> >> 4. Get it once more and it should either be EINVAL or same value that you got first time.
> >>
> >> Which seems to be a little dumb to test to me, so I vote for removing 3-1.c from ltp.
> >
> >    I'll do some comparison with other existing testcases, as well as
> > look at the requirements for 3-1 further tonight -- but my initial
> > look at your argument seems sound.
> 
>     Looking at the tort again in SUSv4, the logic that you're arguing
> seems incorrect:
> 
>     The aio_error() function may fail if:
> 
>     [EINVAL]
>         The aiocbp argument does not refer to an asynchronous
> operation whose return status has not yet been retrieved.
> 
>     It's pretty blatant that EINVAL should apply to aio_error when
> aiocbp is passed in which doesn't point to a valid file descriptor
> linked to some sort of aio operation. If Linux is improperly caching
> the aio_error, then Linux needs to be corrected to meet the POSIX
> requirements if the test is supposed to pass and the behavior isn't
> already documented in the OS specific documentation (manpages,
> whatever). Same thing applies for all OSes trying to meet the golden
> POSIX standard.
>     The ERROR clause's wording is lousy though, so I'll bring this up
> with opengroup.

I'm not native english speaker, so when arguing about wording, my
understanding may not be correct. But I personally understand this as:

aio_error() may fail => it's not hard requirment and it's upon implementation what would happen

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] aio_error/3-1.c

[Cyril Hrubis]

Hi!
>     I'll have it returned PTS_UNRESOLVED instead of PTS_FAIL instead.

Okay.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list