[611] in linux-scsi channel archive
st bug
daemon@ATHENA.MIT.EDU (Philip Blundell)
Sat Sep 9 22:14:01 1995
Date: Sat, 9 Sep 1995 20:35:04 +0100 (BST)
From: Philip Blundell <pjb27@cam.ac.uk>
To: Kai.Makisara@metla.fi
cc: linux-scsi@vger.rutgers.edu
There is a potential problem with the current version of the st driver
(in 1.3.24). If there isn't enough free memory when you initialise it,
it can fail to allocate buffers and not notice. This gives you a null
dereference and a kernel oops.
The attached patch adds a check to make sure that the buffers have been
successfully allocated. This isn't quite enough; it avoids problems
at the time, but the st driver will still be running with null buffer
pointers, so presumably you will get an oops at some later point when you
actually try to use it. I'm not quite sure what to do about it - by the
time we get to allocating buffers there doesn't seem to be any clean
way to back out of initialising the driver.
Fortunately, you don't tend to get a memory-squeeze condition very often
when loading the driver. I've seen it happen just a couple of times.
--- linux/drivers/scsi/st.c Thu Sep 7 17:54:21 1995
+++ linux/drivers/scsi/st.c Sat Sep 9 15:46:20 1995
@@ -2104,6 +2104,14 @@
for (i=0; i < st_nbr_buffers; i++) {
st_buffers[i] = (ST_buffer *) scsi_init_malloc(sizeof(ST_buffer) -
1 + st_buffer_size, GFP_ATOMIC | GFP_DMA);
+ /* Make sure that the malloc didn't fail, to avoid causing a kernel oops.
+ FIXME. We ought to do something slightly more useful, like disabling
+ the tape driver (to avoid disaster later).
+ */
+ if (st_buffers[i] == NULL) {
+ printk(KERN_ERR "st: Not enough memory for buffers\n");
+ return;
+ }
#if DEBUG
/* printk("st: Buffer address: %p\n", st_buffers[i]); */
#endif
--
pjb
