RE: 2.2.1-ac5 oops with many fd
Jeffrey Jones (jeffreyj@ami.com)
Mon, 15 Feb 1999 12:16:05 -0500
> -----Original Message-----
> From: alan@lxorguk.ukuu.org.uk [SMTP:alan@lxorguk.ukuu.org.uk]
> Sent: Monday, February 15, 1999 11:41 AM
> To: Jeffrey Jones
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: 2.2.1-ac5 oops with many fd
>
> > The only bug in the driver is that instead of failing gracefully, it
> > continued to dereference the
> > NULL pointer. I've fixed that, however...
>
> Have you fixed that properly. You can't do a kmalloc in a driver when
> issuing read or write requests or you may deadlock needing to swap out
> data
> by issuing a write...
>
Aha! I believe this is the reason it was failing. If I allocate the
maximum
possible amount of memory I'll need in the beginning when nothing else
is going on, it works. But if I allocate it as I need it, it runs for a
while until
there is a lot of I/O and then kmalloc returns NULL. I'll try adding a
spinlock
around the kmalloc so it can't call it while other stuff is going on.
> > Surely there must be somewhere where I can get more than 8k of DMAable
> > memory...
>
> Linear DMAable memory ?
>
> Alan
>
I actually only need it in 136 byte chunks, the only place I got 8k from was
that's
about how much had been allocated total when kmalloc started failing. But I
think it's probably due to reading/writing from it during allocation.
Regarding Andrea Arcangelli's suggestion of using __get_free_pages(),
should I still use kmalloc if I can get it to work, or is there another
reason
to use __get_free_pages? Given the choice, I'd rather stick with kmalloc
since it allows smaller chunks to be allocated at a time. Thanks both for
your help,
Jeff L Jones <jeffreyj@ami.com>
RAID SW Dev., American Megatrends Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/