The variable ioc->taskmgmt_quiesce_io is often protected by the lock ioc->taskmgmt_lock when is accessed. Here is an example in mpt_SoftResetHandler(): spin_lock_irqsave(&ioc->taskmgmt_lock, flags); ... ioc->taskmgmt_quiesce_io = 0; ... spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags); However, ioc->taskmgmt_quiesce_io is set to 1 without holding the lock ioc->taskmgmt_lock in mpt_ioc_reset(): case MPT_IOC_SETUP_RESET: ioc->taskmgmt_quiesce_io = 1; In my opinion, this may be a harmful race, because the value of ioc->taskmgmt_quiesce_io can be rewritten by mpt_ioc_reset() when another thread is accessing it. To fix this possible data race, a lock and unlock pair is added when accessing the variable ioc->taskmgmt_quiesce_io. Reported-by: BassCheck <bass@xxxxxxxxxxx> Signed-off-by: Tuo Li <islituo@xxxxxxxxx> --- drivers/message/fusion/mptbase.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c index 4bf669c55649..86d7b4defeb0 100644 --- a/drivers/message/fusion/mptbase.c +++ b/drivers/message/fusion/mptbase.c @@ -6561,9 +6561,12 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS *pCfg) static int mpt_ioc_reset(MPT_ADAPTER *ioc, int reset_phase) { + unsigned long flags; switch (reset_phase) { case MPT_IOC_SETUP_RESET: + spin_lock_irqsave(&ioc->taskmgmt_lock, flags); ioc->taskmgmt_quiesce_io = 1; + spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags); dtmprintk(ioc, printk(MYIOC_s_DEBUG_FMT "%s: MPT_IOC_SETUP_RESET\n", ioc->name, __func__)); break; -- 2.34.1