[PATCH] staging: rtlwifi: Fix a possible sleep-in-atomic-context bug in _is_fw_read_cmd_down()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The driver may sleep with holding a spinlock.
The function call path (from bottom to top) in Linux-4.16.7 is:

[FUNC] schedule
drivers/staging/rtlwifi/halmac/rtl_halmac.c, 884: 
		schedule in _is_fw_read_cmd_down
drivers/staging/rtlwifi/halmac/rtl_halmac.c, 912: 
		_is_fw_read_cmd_down in rtl_halmac_send_h2c
drivers/staging/rtlwifi/halmac/rtl_halmac.c, 907: 
		_raw_spin_lock_irqsave in rtl_halmac_send_h2c

To fix this bug, schedule() is replaced with mdelay(1).

This bug is found by my static analysis tool (DSAC-2) and checked by
my code review.

Signed-off-by: Jia-Ju Bai <baijiaju1990@xxxxxxxxx>
---
 drivers/staging/rtlwifi/halmac/rtl_halmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 66f0a6dfc52c..e921a62e72a3 100644
--- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
+++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
@@ -881,7 +881,7 @@ static bool _is_fw_read_cmd_down(struct rtl_priv *rtlpriv, u8 msgbox_num)
 		if (valid == 0)
 			read_down = true;
 		else
-			schedule();
+			mdelay(1);
 	} while ((!read_down) && (retry_cnts--));
 
 	return read_down;
-- 
2.17.0

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux