We have root caused the issue and it is same as you mentioned.
"_scsih_get_enclosure_logicalid_chassis_slot()" is called with interrupts
disabled and this function
"_scsih_get_enclosure_logicalid_chassis_slot" again calls
_config_request(), with mutex_lock().
We have patch ready along with few other change and we ll be posting
it by tomorrow after covering BST.
Suganath Prabu S
On Mon, Mar 12, 2018 at 11:53 PM, Bart Van Assche
> For the first I/O request after boot that is sent to a disk attached to an
> mpt3sas adapter I see the below complaint appearing in the kernel log. This
> occurs at least with kernels v4.16-rc4 and v4.16-rc5.
> What I see in the mpt3sas source code is that
> _scsih_get_enclosure_logicalid_chassis_slot() is called with interrupts
> disabled and also that a function called by that function, namely
> _config_request(), calls mutex_lock().
> Can someone who is more familiar than I with the mpt3sas adapter have a look
> at this and propose a fix?
> BUG: sleeping function called from invalid context at
> in_atomic(): 1, irqs_disabled(): 1, pid: 2389, name: kworker/u64:1
> INFO: lockdep is turned off.
> irq event stamp: 278
> hardirqs last enabled at (277): [<0000000032c577ec>]
> hardirqs last disabled at (278): [<000000006082e2fa>] __schedule+0x120/0x1010
> softirqs last enabled at (0): [<000000008c2eb285>]
> softirqs last disabled at (0): [< (null)>] (null)
> Preemption disabled at:
> [<0000000000000000>] (null)
> CPU: 3 PID: 2389 Comm: kworker/u64:1 Tainted: G W
> 4.16.0-rc5-dbg+ #1
> Workqueue: poll_mpt3sas0_statu _base_fault_reset_work [mpt3sas]
> Call Trace:
> _config_request.constprop.5+0xa3/0xe70 [mpt3sas]
> mpt3sas_config_get_enclosure_pg0+0xb3/0x110 [mpt3sas]
> _scsih_get_enclosure_logicalid_chassis_slot+0xf8/0x160 [mpt3sas]
> mpt3sas_scsih_reset_handler+0x3f6/0xb30 [mpt3sas]
> mpt3sas_base_hard_reset_handler+0x49a/0x7c0 [mpt3sas]
> _base_fault_reset_work+0x1bb/0x260 [mpt3sas]