Bug 157642

Description of problem:
dmesg shows some debug output that looks bad, but system runs OK.
Seems to be related to SCSI drivers.  Messages begin with:
  Debug: sleeping function called from invalid context at mm/slab.c:2110
  in_atomic():0, irqs_disabled():1
Full dmesg output attached.

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.1303_FC4

How reproducible:
100%

Steps to Reproduce:
1. reboot
2.
3.
  
Actual results:


Expected results:


Additional info:

Observed same error message when a network card in an FC4 server went offline:

Jul 17 04:03:22 amanda2 kernel: NETDEV WATCHDOG: eth2: transmit timed out
Jul 17 04:03:22 amanda2 kernel: Debug: sleeping function called from invalid
context at mm/slab.c:2126
Jul 17 04:03:22 amanda2 kernel: in_atomic():1, irqs_disabled():0
Jul 17 04:03:22 amanda2 kernel:  [<c014cc1c>] __kmalloc+0x89/0x8b
Jul 17 04:03:22 amanda2 kernel:  [<c019445d>] proc_create+0x84/0xe6
Jul 17 04:03:22 amanda2 kernel:  [<c019456f>] proc_mkdir_mode+0x22/0x57
Jul 17 04:03:22 amanda2 kernel:  [<c014456e>] register_handler_proc+0x7b/0x89
Jul 17 04:03:22 amanda2 kernel:  [<c0143dbf>] setup_irq+0x8e/0xe2
Jul 17 04:03:22 amanda2 kernel:  [<f89944cf>] e100_intr+0x0/0x14b [e100]
Jul 17 04:03:22 amanda2 kernel:  [<c0143ffa>] request_irq+0x85/0x9b
Jul 17 04:03:22 amanda2 kernel:  [<f89951ac>] e100_up+0xe7/0x1bd [e100]
Jul 17 04:03:22 amanda2 kernel:  [<c02b8bc2>] dev_watchdog+0x0/0xa9
Jul 17 04:03:22 amanda2 kernel:  [<c02b8c63>] dev_watchdog+0xa1/0xa9
Jul 17 04:03:22 amanda2 kernel:  [<c012a28d>] run_timer_softirq+0xe5/0x1b9
Jul 17 04:03:22 amanda2 kernel:  [<c0126602>] __do_softirq+0x72/0xdc
Jul 17 04:03:22 amanda2 kernel:  [<c0106753>] do_softirq+0x4b/0x4f
Jul 17 04:03:23 amanda2 kernel:  =======================
Jul 17 04:03:23 amanda2 kernel:  [<c0104ae8>] apic_timer_interrupt+0x1c/0x24
Jul 17 04:03:23 amanda2 kernel:  [<c010201a>] default_idle+0x0/0x29
Jul 17 04:03:23 amanda2 kernel:  [<c0102040>] default_idle+0x26/0x29
Jul 17 04:03:23 amanda2 kernel:  [<c01020c4>] cpu_idle+0x4e/0x63
Jul 17 04:03:23 amanda2 kernel: e100: eth2: e100_watchdog: link up, 100Mbps,
full-duplex

Server was up and running and the other NIC (another e100) was online.  Didn't
try an ifdown/ifup.  Didn't think about it before I rebooted the box.  Sorry.  :(

  John:  Can you upgrade to a newer kernel?
Gordon:  What kernel are you running?

I found the bug.  I don't know what the fix is.

In drivers/scsi/scsi_transport_spi.c in the funciton spi_dv_device()
spi_dv_device_internal(sdev, buffer) is called with BKL held.

The problematic call tree is:
spi_dv_device_internal()
spi_dv_device_compare_inquiry()
spi_execute()
scsi_execute()
blk_rq_map_kern(sdev->request_queue, req, buffer, bufflen, __GFP_WAIT))

The __GFP_WAIT is passed to a kmalloc later.

Crap.  I'm an idiot.  I thought down() was BKL but really it's just a semafor...  

Gordon, you're bug is probably something different from John's.  Can you open a
new bug for the issue you see?

bug 160673 is probably a duplicate of this (John's) bug.

*** Bug 160673 has been marked as a duplicate of this bug. ***

Still seen in 2.6.12-1.1398_FC4smp, i686

There is a fix upstream.
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=53222b906903fd861dc24ebccfa07ee125941313


The allocation in sym_alloc_lcb_tags() becomes GFP_ATOMIC.

Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.

2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

I've not seen this recur after the last few updates, marking as fixed.