2004-01-20 02:31:57

by Mike Fedyk

[permalink] [raw]
Subject: [2.6.1-bk2] Might sleep while loading st.ko

I saw this in my kernel log while working with a scsi tape drive.

Is this a known sleeping function, or should I take more action to notify
the scsi or adaptec driver teams?

st: Version 20031228, fixed bufsize 32768, s/g segs 256
Debug: sleeping function called from invalid context at mm/slab.c:1856
in_atomic():1, irqs_disabled():0
Call Trace:
[__might_sleep+157/224] __might_sleep+0x9d/0xe0
[kmem_cache_alloc+92/96] kmem_cache_alloc+0x5c/0x60
[cdev_alloc+23/80] cdev_alloc+0x17/0x50
[_end+542090623/1069194756] st_probe+0x3fb/0x790 [st]
[bus_match+47/96] bus_match+0x2f/0x60
[driver_attach+87/144] driver_attach+0x57/0x90
[bus_add_driver+138/160] bus_add_driver+0x8a/0xa0
[_end+541199949/1069194756] init_st+0x49/0x94 [st]
[sys_init_module+288/624] sys_init_module+0x120/0x270
[sysenter_past_esp+82/121] sysenter_past_esp+0x52/0x79

Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0
st0: try direct i/o: yes, max page reachable by HBA 1048575
st0: Block limits 2 - 16777215 bytes.
st0: Incorrect block size.

00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev 05)
00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 05)
00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 05)
00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 05)
00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 05)
00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 05)
00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 05)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF
02:09.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
02:0a.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 01)

/proc/modules:
st 35608 0 - Live 0xe0949000
soundcore 7488 0 - Live 0xe08d6000
r128 91948 28 - Live 0xe0972000
hid 61888 0 - Live 0xe08fa000
usbmouse 4352 0 - Live 0xe0854000
nfs 94124 3 - Live 0xe095a000
lockd 58992 2 nfs, Live 0xe090d000
sunrpc 122312 10 nfs,lockd, Live 0xe091e000
uhci_hcd 31120 0 - Live 0xe08cd000
ohci_hcd 17408 0 - Live 0xe086f000
ehci_hcd 22148 0 - Live 0xe0877000
usbcore 98524 7 hid,usbmouse,uhci_hcd,ohci_hcd,ehci_hcd, Live 0xe08e0000
evdev 8192 0 - Live 0xe080c000
parport_pc 31788 1 - Live 0xe08b9000
lp 9376 0 - Live 0xe086b000
parport 36712 2 parport_pc,lp, Live 0xe08af000
floppy 56052 0 - Live 0xe087f000
i2c_isa 2048 0 - Live 0xe084f000
i2c_core 21256 1 i2c_isa, Live 0xe0857000
tulip 45216 0 - Live 0xe085e000
crc32 4224 1 tulip, Live 0xe080f000
rtc 11976 0 - Live 0xe084b000
unix 26032 247 - Live 0xe0815000


2004-01-20 19:43:09

by Mike Fedyk

[permalink] [raw]
Subject: Re: [2.6.1-bk2] Might sleep while loading st.ko

On Tue, Jan 20, 2004 at 09:30:57PM +0200, Kai Makisara wrote:
> Added linux-scsi which may be better list for this problem.
>
[snip]
> I thought I used enough debugging options to catch this but I did not...
>
> The patch below fixes this problem (introduced in 2.6.1) by moving cdev
> code outside the lock protecting st internal data. The patched driver
> compiles and seems to work in my tests.
>
> The sysfs link to /sys/cdev/major/st?m0 is not made any more because I have
> understood that it is a bad idea.
>
> Thanks for reporting the bug.
>

I'll put this patch in my next kernel compile.

Thanks.

2004-01-20 19:31:18

by Kai Mäkisara (Kolumbus)

[permalink] [raw]
Subject: Re: [2.6.1-bk2] Might sleep while loading st.ko

Added linux-scsi which may be better list for this problem.

On Mon, 19 Jan 2004, Mike Fedyk wrote:

> I saw this in my kernel log while working with a scsi tape drive.
>
> Is this a known sleeping function, or should I take more action to notify
> the scsi or adaptec driver teams?
>
> st: Version 20031228, fixed bufsize 32768, s/g segs 256
> Debug: sleeping function called from invalid context at mm/slab.c:1856
> in_atomic():1, irqs_disabled():0
> Call Trace:
> [__might_sleep+157/224] __might_sleep+0x9d/0xe0
> [kmem_cache_alloc+92/96] kmem_cache_alloc+0x5c/0x60
> [cdev_alloc+23/80] cdev_alloc+0x17/0x50
> [_end+542090623/1069194756] st_probe+0x3fb/0x790 [st]

I thought I used enough debugging options to catch this but I did not...

The patch below fixes this problem (introduced in 2.6.1) by moving cdev
code outside the lock protecting st internal data. The patched driver
compiles and seems to work in my tests.

The sysfs link to /sys/cdev/major/st?m0 is not made any more because I have
understood that it is a bad idea.

Thanks for reporting the bug.

--
Kai

-------------------------------8<-----------------------------------------
--- linux-2.6.1-bk6/drivers/scsi/st.c 2004-01-20 20:16:20.000000000 +0200
+++ linux-2.6.1-bk6-k1/drivers/scsi/st.c 2004-01-20 21:18:10.000000000 +0200
@@ -17,7 +17,7 @@
Last modified: 18-JAN-1998 Richard Gooch <[email protected]> Devfs support
*/

-static char *verstr = "20031228";
+static char *verstr = "20040120";

#include <linux/module.h>

@@ -3846,7 +3846,30 @@
STm->default_compression = ST_DONT_TOUCH;
STm->default_blksize = (-1); /* No forced size */
STm->default_density = (-1); /* No forced density */
+ }
+
+ for (i = 0; i < ST_NBR_PARTITIONS; i++) {
+ STps = &(tpnt->ps[i]);
+ STps->rw = ST_IDLE;
+ STps->eof = ST_NOEOF;
+ STps->at_sm = 0;
+ STps->last_block_valid = FALSE;
+ STps->drv_block = (-1);
+ STps->drv_file = (-1);
+ }

+ tpnt->current_mode = 0;
+ tpnt->modes[0].defined = TRUE;
+
+ tpnt->density_changed = tpnt->compression_changed =
+ tpnt->blksize_changed = FALSE;
+ init_MUTEX(&tpnt->lock);
+
+ st_nr_dev++;
+ write_unlock(&st_dev_arr_lock);
+
+ for (mode = 0; mode < ST_NBR_MODES; ++mode) {
+ STm = &(tpnt->modes[mode]);
for (j=0; j < 2; j++) {
cdev = cdev_alloc();
if (!cdev) {
@@ -3855,17 +3878,17 @@
goto out_put_disk;
}
snprintf(cdev->kobj.name, KOBJ_NAME_LEN, "%sm%d%s", disk->disk_name,
- i, j ? "n" : "");
+ mode, j ? "n" : "");
cdev->owner = THIS_MODULE;
cdev->ops = &st_fops;
STm->cdevs[j] = cdev;

error = cdev_add(STm->cdevs[j],
- MKDEV(SCSI_TAPE_MAJOR, TAPE_MINOR(dev_num, i, j)),
+ MKDEV(SCSI_TAPE_MAJOR, TAPE_MINOR(dev_num, mode, j)),
1);
if (error) {
printk(KERN_ERR "st%d: Can't add %s-rewind mode %d\n",
- dev_num, j ? "non" : "auto", i);
+ dev_num, j ? "non" : "auto", mode);
}

error = sysfs_create_link(&STm->cdevs[j]->kobj, &SDp->sdev_gendev.kobj,
@@ -3876,43 +3899,15 @@
dev_num);
}
}
- }
- error = sysfs_create_link(&SDp->sdev_gendev.kobj, &tpnt->modes[0].cdevs[0]->kobj,
- "tape");
- if (error) {
- printk(KERN_ERR "st%d: Can't create sysfs link from SCSI device.\n",
- dev_num);
- }
-
- for (i = 0; i < ST_NBR_PARTITIONS; i++) {
- STps = &(tpnt->ps[i]);
- STps->rw = ST_IDLE;
- STps->eof = ST_NOEOF;
- STps->at_sm = 0;
- STps->last_block_valid = FALSE;
- STps->drv_block = (-1);
- STps->drv_file = (-1);
- }

- tpnt->current_mode = 0;
- tpnt->modes[0].defined = TRUE;
-
- tpnt->density_changed = tpnt->compression_changed =
- tpnt->blksize_changed = FALSE;
- init_MUTEX(&tpnt->lock);
-
- st_nr_dev++;
- write_unlock(&st_dev_arr_lock);
-
- for (mode = 0; mode < ST_NBR_MODES; ++mode) {
- /* Rewind entry */
- devfs_mk_cdev(MKDEV(SCSI_TAPE_MAJOR, dev_num + (mode << 5)),
- S_IFCHR | S_IRUGO | S_IWUGO,
- "%s/mt%s", SDp->devfs_name, st_formats[mode]);
- /* No-rewind entry */
- devfs_mk_cdev(MKDEV(SCSI_TAPE_MAJOR, dev_num + (mode << 5) + 128),
- S_IFCHR | S_IRUGO | S_IWUGO,
- "%s/mt%sn", SDp->devfs_name, st_formats[mode]);
+ /* Rewind entry */
+ devfs_mk_cdev(MKDEV(SCSI_TAPE_MAJOR, dev_num + (mode << 5)),
+ S_IFCHR | S_IRUGO | S_IWUGO,
+ "%s/mt%s", SDp->devfs_name, st_formats[mode]);
+ /* No-rewind entry */
+ devfs_mk_cdev(MKDEV(SCSI_TAPE_MAJOR, dev_num + (mode << 5) + 128),
+ S_IFCHR | S_IRUGO | S_IWUGO,
+ "%s/mt%sn", SDp->devfs_name, st_formats[mode]);
}
disk->number = devfs_register_tape(SDp->devfs_name);