Re: [QLA2300] Call Trace: sleeping function called from invalid context

[Andrew Morton <akpm@osdl.org>]

Tomasz K__oczko <kloczek@rudy.mif.pg.gda.pl> wrote:
>
> Configuration:
>  Sun v20z directly connected to Sun 3511 FC array. HBA:
>  03:01.0 Fibre Channel: QLogic Corp. QLA2300 64-bit Fibre Channel Adapter (rev 01)
> 
>  On begining on FC port aren't avalaible any luns for this host.
>  Change on array controler configuration for map SCSI channel to port 
>  connected to this host causes on this computer:
> 
>  qla2300 0000:03:01.0: LIP reset occured (f8f7).
>  Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
>  in_atomic():1, irqs_disabled():1
> 
>  Call Trace: <IRQ> <ffffffff80277156>{device_for_each_child+54}
>          <ffffffff880317c5>{:scsi_transport_fc:fc_remote_port_block+53}
>          <ffffffff8803c284>{:qla2xxx:qla2x00_mark_all_devices_lost+68}
>          <ffffffff8804570f>{:qla2xxx:qla2x00_async_event+2127}
>          <ffffffff88045f30>{:qla2xxx:qla2300_intr_handler+384}
>          <ffffffff8016135c>{handle_IRQ_event+44} <ffffffff8016148d>{__do_IRQ+253}
>          <ffffffff80111678>{do_IRQ+72} <ffffffff8010f027>{ret_from_intr+0}
>           <EOI> <ffffffff8010d390>{default_idle+0} <ffffffff8010d3b2>{default_idle+34}
>          <ffffffff8010d407>{cpu_idle+71} <ffffffff8050685a>{start_kernel+474}
>          <ffffffff80506266>{_sinittext+614}
>  qla2300 0000:03:01.0: LIP occured (f7f7).
> 
>  System it is Fedora devel version (2.6.11-1.1275_FC4smp).

fc_remote_port_block() calls scsi_target_block() calls device_for_each_child().

In Linus's tree, device_for_each_child() does down_read().  In -mm that
down_read() has been taken out, but device_for_each_child() is still doing
spin_lock() and hence still cannot be called from interrupts.

Now, possibly we could make that locking in the new device_for_each_child()
(klist_iter->i_klist->k_lock) be IRQ-safe.  That'd be for Pat and Greg to
decide.

I suspect they'll say no, and the qlogic driver (or scsi) need to stop
calling device_for_each_child() from IRQ context.

(Locking in the new device_for_each_child() looks funny to me.  Are we sure
it's safe?)