Date: Thu, 27 Jan 2000 10:54:07 -0800 From: "Scott Hess" <scott@avantgo.com> To: "Matthew Dillon" <dillon@apollo.backplane.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: aio_read crashing certain kernels. Message-ID: <073d01bf68f7$e3ca25b0$1e80000a@avantgo.com> References: <01b301bf6824$46e928a0$1e80000a@avantgo.com> <200001262330.PAA16635@apollo.backplane.com> <066e01bf6877$02deb550$1e80000a@avantgo.com> <200001270457.UAA18887@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Matthew Dillon" <dillon@apollo.backplane.com> wrote:
> This is an incredibly scary program!
OK, so I was facetious in including that program - my basic point was that
it doesn't happen when I'm doing anything weird, it happens with the most
straightforward aio_read program imaginable. Furthermore, it works on the
uniprocessor/EIDE/standard-kernel machine, it doesn't on the
SMP/Adaptec/custom-kernel machine. I've included another version of the
program which I've used to actually kill a machine, repeatedly.
> It's sending an iocb to aio_read
> and then pops the stack and exits. The act of exiting could very
well
> scribble all over the iocb structure while the I/O is in progress
and,
> of course, then the program invalidates the stack and exits.
??? The problem is that I'm locking up the entire box, hard enough this
morning that I had to pull the plug to get it back. If all I got were a
coredump, I'd be over on freebsd-questions trying to figure out how it was
that I misunderstood the problem.
[Actually, I think this did cause my original posting to work right,
because the process exitting probably caused the aio stuff to either error
out or work correctly :-).]
> You could be right about the SMP build --- the aio code is indeed
> doing a fork with RFMEM and that *WILL* break under SMP.
The weird thing is, rfork() on SMP returns ENOTSUPP - it doesn't work, but
it doesn't break, either.
Here's the program. I've found that it actually sometimes works, but I
haven't been able to figure out why. It seems to have something to do with
whether the file might be in the buffer cache or not (so it helps to pass a
file which hasn't been accessed in awhile). Also, if I change the #if 1 to
#if 0, it seems to work just fine. My suspicion is that it could be an SMP
issue, and if I'm lucky, everything executes on a single CPU and works. If
I'm unlucky, BAM! The code that I'm really hacking on does a lot of reads
from widely placed sections of a file, and thus is more likely to hit the
problem (if someone really really really wants that program, I can try to
hack it into postable shape, but the enclosed program does the job for me).
Again, the symptoms of a problem are that the entire box locks up so hard
that you have to power cycle it at best, or pull the plug at worst.
#include <fcntl.h>
#include <aio.h>
#include <errno.h>
void main( int argc, char **argv)
{
int fd=open( argc>1 ? argv[1] : "/usr/tmp/aiotest.c", O_RDONLY);
char buf[ 1024];
struct aiocb iocb;
sigset_t sigset;
if( fd==-1) {
perror( "opening");
}
bzero( &iocb, sizeof( iocb));
iocb.aio_fildes=fd;
iocb.aio_offset=0;
iocb.aio_buf=buf;
iocb.aio_nbytes=sizeof( buf);
iocb.aio_sigevent.sigev_notify=SIGEV_SIGNAL;
iocb.aio_sigevent.sigev_signo=SIGIO;
#if 1
if( aio_read( &iocb)==-1) {
perror( "aio_read");
}
while( aio_error( &iocb)==EINPROGRESS);
#else
printf( "aio_read\n");
if( aio_read( &iocb)==-1) {
perror( "aio_read");
}
do {
printf( "aio_error\n");
} while( aio_error( &iocb)==EINPROGRESS);
#endif
printf( "en==%d\n", aio_error( &iocb));
printf( "rc==%d\n", aio_return( &iocb));
}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?073d01bf68f7$e3ca25b0$1e80000a>