libaio 0.3.92 test release

libaio 0.3.92 test release

[Benjamin LaHaise]

Hello folks,

I've just uploaded the libaio 0.3.92 test release to kernel.org.  Most 
notably, this release passes a few basic tests on ia64, and should work 
on x86-64 too (but isn't tested).  An updated kernel patch can be found
in /pub/linux/kernel/people/bcrl/aio/patches/testing/aio-20020916.diff 
which uses the registered syscall ABI (no more dynamic syscalls), fixes 
a bug in io_submit that allowed iocbs to be read from kernel memory 
(that bug is not present in RH 2.1AS; the fix was lost in the 2.4.18 
merge), fixes an occasional hang caused by timers not being unregistered 
in io_getevents, and probably introduces a few other bugs.  This is a 
test release as I still have to split up the patches into -stable, 
-alpha and -developement to prevent people from shipping experimental 
code that was never meant to be used on production machines.  In any 
case, if people could give this a whirl and submit reports to 
linux-aio@kvack.org, it would be appreciated.  My hit list still 
includes getting ARM, PPC, S/390, SPARC and m68k support merged into 
libaio, so if anyone cares to provide patches, I'd appreciate it.  Cheers,

		-ben

Re: libaio 0.3.92 test release

[Arnd Bergmann]

On Tuesday 17 September 2002 04:12, Benjamin LaHaise wrote:

> linux-aio@kvack.org, it would be appreciated.  My hit list still
> includes getting ARM, PPC, S/390, SPARC and m68k support merged into
> libaio, so if anyone cares to provide patches, I'd appreciate it.  Cheers,

Hi,

I've been meaning to send this earlier, but somehow forgot about it.
Unfortunately, I have not been able to make all the test cases work,
but that might be because it used a patched 2.4-aa kernel, not the
latest 2.5.

	Arnd <><

diff -ur --new-file libaio-0.3.92-orig/libaio.spec libaio-0.3.92/libaio.spec
--- libaio-0.3.92-orig/libaio.spec	Sat Sep 14 01:57:13 2002
+++ libaio-0.3.92/libaio.spec	Tue Sep 17 10:58:29 2002
@@ -7,7 +7,7 @@
 Source: %{name}-%{version}.tar.gz
 BuildRoot: %{_tmppath}/%{name}-root
 # Fix ExclusiveArch as we implement this functionality on more architectures
-ExclusiveArch: i386 x86_64 ia64
+ExclusiveArch: i386 x86_64 ia64 s390 s390x
 
 %description
 The Linux-native asynchronous I/O facility ("async I/O", or "aio") has a
diff -ur --new-file libaio-0.3.92-orig/src/libaio.h libaio-0.3.92/src/libaio.h
--- libaio-0.3.92-orig/src/libaio.h	Tue Sep 17 00:45:18 2002
+++ libaio-0.3.92/src/libaio.h	Tue Sep 17 11:40:49 2002
@@ -51,6 +51,14 @@
 #define PADDED(x, y)	x, y
 #define PADDEDptr(x, y)	x
 #define PADDEDul(x, y)	unsigned long x
+#elif defined(__s390x__) /* big endian, 64 bits */
+#define PADDED(x, y)	unsigned y; x
+#define PADDEDptr(x,y)	x
+#define PADDEDul(x, y)	unsigned long x
+#elif defined(__s390__) /* big endian, 32 bits */
+#define PADDED(x, y)	unsigned y; x
+#define PADDEDptr(x, y) unsigned y; x
+#define PADDEDul(x, y)	unsigned y; unsigned long x
 #else
 #error	endian?
 #endif
diff -ur --new-file libaio-0.3.92-orig/src/syscall-s390.h libaio-0.3.92/src/syscall-s390.h
--- libaio-0.3.92-orig/src/syscall-s390.h	Thu Jan  1 01:00:00 1970
+++ libaio-0.3.92/src/syscall-s390.h	Tue Sep 17 11:43:47 2002
@@ -0,0 +1,119 @@
+#define __NR_io_setup		243
+#define __NR_io_destroy		244
+#define __NR_io_getevents	245
+#define __NR_io_submit		246
+#define __NR_io_cancel		247
+
+#define _svc_clobber "2", "cc", "memory"
+
+#ifdef __s390x__
+#define __LR "lgr " /* 64 bit load register */
+#else
+#define __LR "lr	" /* 32 bit load register */
+#endif
+
+#define io_syscall0(type,name)					\
+type name(void) {						\
+	long __res;						\
+	__asm__ __volatile__ (					\
+		"    svc %b1\n"					\
+		"    "__LR" %0,2"				\
+		: "=d" (__res)					\
+		: "i" (__NR_##name)				\
+		: _svc_clobber );				\
+	return (type) __res;					\
+}
+
+#define io_syscall1(type,name,type1,arg1)			\
+type name(type1 arg1) {						\
+	register type1 __arg1 asm("2") = arg1;			\
+	long __res;						\
+	__asm__ __volatile__ (					\
+		"    svc %b1\n"					\
+		"    "__LR" %0,2"				\
+		: "=d" (__res)					\
+		: "i" (__NR_##name),				\
+		  "d" (__arg1)					\
+		: _svc_clobber );				\
+	return (type) __res;					\
+}
+
+#define io_syscall2(type,name,type1,arg1,type2,arg2)		\
+type name(type1 arg1, type2 arg2) {				\
+	register type1 __arg1 asm("2") = arg1;			\
+	register type2 __arg2 asm("3") = arg2;			\
+	long __res;						\
+	__asm__ __volatile__ (					\
+		"    svc %b1\n"					\
+		"    "__LR" %0,2"				\
+		: "=d" (__res)					\
+		: "i" (__NR_##name),				\
+		  "d" (__arg1),					\
+		  "d" (__arg2)					\
+		: _svc_clobber );				\
+	return (type) __res;					\
+}
+
+#define io_syscall3(type,name,type1,arg1,type2,arg2,		\
+		    type3,arg3)					\
+type name(type1 arg1, type2 arg2, type3 arg3) {			\
+	register type1 __arg1 asm("2") = arg1;			\
+	register type2 __arg2 asm("3") = arg2;			\
+	register type3 __arg3 asm("4") = arg3;			\
+	long __res;						\
+	__asm__ __volatile__ (					\
+		"    svc %b1\n"					\
+		"    "__LR" %0,2"				\
+		: "=d" (__res)					\
+		: "i" (__NR_##name),				\
+		  "d" (__arg1),					\
+		  "d" (__arg2),					\
+		  "d" (__arg3)					\
+		: _svc_clobber );				\
+	return (type) __res;					\
+}
+
+#define io_syscall4(type,name,type1,arg1,type2,arg2,		\
+		    type3,arg3,type4,arg4)			\
+type name(type1 arg1, type2 arg2, type3 arg3, type4 arg4) {	\
+	register type1 __arg1 asm("2") = arg1;			\
+	register type2 __arg2 asm("3") = arg2;			\
+	register type3 __arg3 asm("4") = arg3;			\
+	register type4 __arg4 asm("5") = arg4;			\
+	long __res;						\
+	__asm__ __volatile__ (					\
+		"    svc %b1\n"					\
+		"    "__LR" %0,2"				\
+		: "=d" (__res)					\
+		: "i" (__NR_##name),				\
+		  "d" (__arg1),					\
+		  "d" (__arg2),					\
+		  "d" (__arg3),					\
+		  "d" (__arg4)					\
+		: _svc_clobber );				\
+	return (type) __res;					\
+}
+
+#define io_syscall5(type,name,type1,arg1,type2,arg2,		\
+		    type3,arg3,type4,arg4,type5,arg5)		\
+type name(type1 arg1, type2 arg2, type3 arg3, type4 arg4,	\
+	  type5 arg5) {						\
+	register type1 __arg1 asm("2") = arg1;			\
+	register type2 __arg2 asm("3") = arg2;			\
+	register type3 __arg3 asm("4") = arg3;			\
+	register type4 __arg4 asm("5") = arg4;			\
+	register type5 __arg5 asm("6") = arg5;			\
+	long __res;						\
+	__asm__ __volatile__ (					\
+		"    svc %b1\n"					\
+		"    "__LR" %0,2"				\
+		: "=d" (__res)					\
+		: "i" (__NR_##name),				\
+		  "d" (__arg1),					\
+		  "d" (__arg2),					\
+		  "d" (__arg3),					\
+		  "d" (__arg4),					\
+		  "d" (__arg5)					\
+		: _svc_clobber );				\
+	return (type) __res;					\
+}
diff -ur --new-file libaio-0.3.92-orig/src/syscall.h libaio-0.3.92/src/syscall.h
--- libaio-0.3.92-orig/src/syscall.h	Sat Sep 14 01:07:20 2002
+++ libaio-0.3.92/src/syscall.h	Tue Sep 17 10:46:54 2002
@@ -10,6 +10,8 @@
 #include "syscall-x86_64.h"
 #elif defined(__ia64__)
 #include "syscall-ia64.h"
+#elif defined(__s390__)
+#include "syscall-s390.h"
 #else
 #error "add syscall-arch.h"
 #endif

RE: libaio 0.3.92 test release

[Chen, Kenneth W]

several questions regarding to aio-20020916 release:

In fs/aio.c, it doesn't appear that the API as well as the implementation
are sync'ed up with what's in 2.5.x.  And this leads to the following
discrepancy compare to what's in 2.5:

  1. The min_nr semantics in io_getevents() doesn't appear to be merged
correctly in this release.
  2. lookup_kiocb() still doesn't look right.
  3. sys_io_cancel() missing argument "struct io_event *result".
  4. kiocb is still pre-allocated on sys_io_setup while in 2.5, it is not.

Is there another release (hopefully soon) to sync up fs/aio.c with 2.5? or
is it going to be never?

- Ken Chen


-----Original Message-----
From: Benjamin LaHaise [mailto:bcrl@redhat.com]
Sent: Monday, September 16, 2002 7:12 PM
To: linux-aio@kvack.org
Cc: Linux Kernel
Subject: libaio 0.3.92 test release


Hello folks,

I've just uploaded the libaio 0.3.92 test release to kernel.org.  Most 
notably, this release passes a few basic tests on ia64, and should work 
on x86-64 too (but isn't tested).  An updated kernel patch can be found
in /pub/linux/kernel/people/bcrl/aio/patches/testing/aio-20020916.diff 
which uses the registered syscall ABI (no more dynamic syscalls), fixes 
a bug in io_submit that allowed iocbs to be read from kernel memory 
(that bug is not present in RH 2.1AS; the fix was lost in the 2.4.18 
merge), fixes an occasional hang caused by timers not being unregistered 
in io_getevents, and probably introduces a few other bugs.  This is a 
test release as I still have to split up the patches into -stable, 
-alpha and -developement to prevent people from shipping experimental 
code that was never meant to be used on production machines.  In any 
case, if people could give this a whirl and submit reports to 
linux-aio@kvack.org, it would be appreciated.  My hit list still 
includes getting ARM, PPC, S/390, SPARC and m68k support merged into 
libaio, so if anyone cares to provide patches, I'd appreciate it.  Cheers,

		-ben
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/

Re: libaio 0.3.92 test release

[Benjamin LaHaise]

On Tue, Sep 17, 2002 at 12:31:00PM -0700, Chen, Kenneth W wrote:
> several questions regarding to aio-20020916 release:
> 
> In fs/aio.c, it doesn't appear that the API as well as the implementation
> are sync'ed up with what's in 2.5.x.  And this leads to the following
> discrepancy compare to what's in 2.5:

Yeah, I missed a couple and have to add test cases for them to the 
test suite (those test programs were separate from libaio, and will 
soon no longer be).  That'll be fixed in today's test release.

> Is there another release (hopefully soon) to sync up fs/aio.c with 2.5? or
> is it going to be never?

Of course!  Why wouldn't there be?

		-ben

Re: libaio 0.3.92 test release

[Jesse Barnes]

On Mon, Sep 16, 2002 at 10:12:19PM -0400, Benjamin LaHaise wrote:
> Hello folks,
> 
> I've just uploaded the libaio 0.3.92 test release to kernel.org.  Most 
> notably, this release passes a few basic tests on ia64, and should work 
> on x86-64 too (but isn't tested).

Thanks Ben.  I just pulled down the latest patch and library and tried
them out on my ia64 box.  Many of the tests in the testsuite passed,
but I encountered a hang during 'make check' after 6.t ran.  Here's
the output up to that point:

[root@ainek1 harness]# make check
rm -f testdir/rofile
echo "test" >testdir/rofile
chmod 400 testdir/rofile
rm -f testdir/rwfile
echo "test" >testdir/rwfile
chmod 600 testdir/rwfile
rm -f testdir/wofile
echo "test" >testdir/wofile
chmod 200 testdir/wofile
./runtests.sh cases/2.p cases/3.p cases/4.p cases/5.p cases/6.p cases/7.p cases/8.p cases/10.p cases/11.p cases/12.p cases/13.p
Test run starting at Tue Sep 17 13:31:24 PDT 2002
Starting cases/2.p
expect -14: io_setup(-1000, 0xffffffffc0010000) = -14 [Bad address]
expect -14: io_setup( 1000, 0xffffffffc0010000) = -14 [Bad address]
expect -14: io_setup(    0, 0xffffffffc0010000) = -14 [Bad address]
expect -22: io_setup(-1000, 0x60000fffffffb990) = -22 [Invalid argument]
expect -22: io_setup(   -1, 0x60000fffffffb990) = -22 [Invalid argument]
expect -22: io_setup(    0, 0x60000fffffffb990) = -22 [Invalid argument]
expect   0: io_setup(    1, 0x60000fffffffb990) =   0 [Success]
expect -22: io_setup(    1, 0x60000fffffffb990) = -22 [Invalid argument]
test cases/2.t completed PASSED.
Completed cases/2.p with 0.
Starting cases/3.p
expect -22: io_submit(0xffffffffffffffff,   1, 0x60000fffffffb960) = -22 [Invalid argument]
expect   0: io_submit(0x2000000000044000,   0, 0x60000fffffffb960) =   0 [Success]
expect -14: io_submit(0x2000000000044000,   1,      (nil)) = -14 [Bad address]
expect -14: io_submit(0x2000000000044000,   1, 0xffffffffffffffff) = -14 [Bad address]
expect -14: io_submit(0x2000000000044000,   2, 0x60000fffffffb970) = -14 [Bad address]
expect -14: io_submit(0x2000000000044000,   2, 0x60000fffffffb980) = -14 [Bad address]
expect -22: io_submit(0x2000000000044000,  -1, 0x60000fffffffb960) = -22 [Invalid argument]
test cases/3.t completed PASSED.
Completed cases/3.p with 0.
Starting cases/4.p
expect  -9: (w), res = sync_submit: io_submit res=-9 [Bad file descriptor]
 -9 [Bad file descriptor]
expect  -9: (r), res = sync_submit: io_submit res=-9 [Bad file descriptor]
 -9 [Bad file descriptor]
expect 512: (w), res = 512 [Success]
expect 512: (r), res = 512 [Success]
expect -22: (r), res = -22 [Invalid argument]
expect -22: (w), res = -22 [Invalid argument]
expect   0: (r), res =   0 [Success]
expect   4: (w), res =   4 [Success]
expect   4: (w), res =   4 [Success]
expect   8: (r), res =   8 [Success]
read after append: [12345678]
expect -14: (r), res = -14 [Bad address]
expect -14: (w), res = -14 [Bad address]
expect -14: (w), res = 512 [Success] -- FAILED
test cases/4.t completed FAILED.
Completed cases/4.p with 1 -- FAILED.
Starting cases/5.p
expect   512: (w), res =   512 [Success]
expect   512: (r), res =   512 [Success]
expect   512: (r), res =   512 [Success]
expect   512: (w), res =   512 [Success]
expect   512: (w), res =   512 [Success]
expect   -14: (r), res =   -14 [Bad address]
expect   512: (r), res =   -14 [Bad address] -- FAILED
expect   -14: (w), res =   -14 [Bad address]
test cases/5.t completed FAILED.
Completed cases/5.p with 1 -- FAILED.
Starting cases/6.p
size = 953648
expect 805306368: (w), res = 805306368 [Success]
expect 805306368: (r), res = sync_submit: io_getevents res=0 [Success]
    0 [Success] -- FAILED
test cases/6.t completed FAILED.

Unfortunately, I don't have kdb compiled into this kernel so I can't
give you a backtrace right now, but maybe you've already run into this
problem?

Thanks,
Jesse