From: Madhuparna Bhowmik
Currently in c67x00_drv_probe() IRQ is requested before calling
c67x00_probe_sie() and hence if interrupt happens the reading of certain
variables in the handler can race with initialization of the variables,
for e.g. sie->sie_num is written in c67x00_probe_sie() and
From: Madhuparna Bhowmik
via_save_pcictrlreg() should be called with host->lock held
as it writes to pm_pcictrl_reg, otherwise there can be a race
condition between via_sd_suspend() and via_sdc_card_detect().
The same pattern is used in the function via_reset_pcictrl()
as well, where
From: Madhuparna Bhowmik
In probe, IRQ is requested before zchan->id is initialized which can be
read in the irq handler. Hence, shift request irq after other initializations
complete.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Madhuparna Bhowmik
---
From: Madhuparna Bhowmik
In probe IRQ is requested before zchan->id is initialized which can be
read in the irq handler. Hence, shift request irq and enable clock after
other initializations complete. Here, enable clock part is not part of
the race, it is just shifted down after request_irq to
From: Madhuparna Bhowmik
After misc_register the open() callback can be called.
However the base address (swc_base_addr) is set after misc_register()
in init.
As a result, if open callback is called before pc87413_get_swc_base_addr()
then in the following call chain: pc87413_open() ->
From: Madhuparna Bhowmik
engine->stat_irq_thresh was initialized after device_create_file() in
the probe function, the initialization may race with call to
spacc_stat_irq_thresh_store() which updates engine->stat_irq_thresh,
therefore initialize it before creating the file in probe function.
From: Madhuparna Bhowmik
In rdc321x_wdt_probe(), rdc321x_wdt_device.queue is initialized
after misc_register(), hence if ioctl is called before its
initialization which can call rdc321x_wdt_start() function,
it will see an uninitialized value of rdc321x_wdt_device.queue,
hence initialize it
From: Madhuparna Bhowmik
The variable DeviceErrorCount is used to keep track of the number of
errors in read, write and interrupt routines, however it was not
protected by proper locking.
Therefore, this patch adds a spinlock: error_lock to protect the
variable.
Found by Linux Driver
From: Madhuparna Bhowmik
via_save_pcictrlreg() should be called with host->lock held
as it writes to pm_pcictrl_reg, otherwise there can be a race
condition between via_sd_suspend() and via_sdc_card_detect().
The same pattern is used in the function via_reset_pcictrl()
as well, where
From: Madhuparna Bhowmik
In capi_init(), after register_chrdev() the file operation callbacks
can be called. However capinc_tty_init() is called later.
Since capiminors and capinc_tty_driver are initialized in
capinc_tty_init(), their initialization can race with their usage
in various callbacks
From: Madhuparna Bhowmik
This patch fixes the macro _list_check_srcu() for CONFIG_PROVE_RCU_LIST =
False.
Reported-by: kernel test robot
Signed-off-by: Madhuparna Bhowmik
---
include/linux/rculist.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rculist.h
From: Madhuparna Bhowmik
list/hlist_for_each_entry_rcu() provides an optional cond argument
to specify the lock held in the updater side.
However for SRCU read side, not providing the cond argument results
into false positive as whether srcu_read_lock is held or not is not
checked implicitly.
From: Madhuparna Bhowmik
Use hlist_for_each_entry_srcu() instead of hlist_for_each_entry_rcu()
as it also checkes if the right lock is held.
Using hlist_for_each_entry_rcu() with a condition argument will not
report the cases where a SRCU protected list is traversed using
rcu_read_lock(). Hence,
From: Madhuparna Bhowmik
list/hlist_for_each_entry_rcu() provides an optional cond argument
to specify the lock held in the updater side.
However for SRCU read side, not providing the cond argument results
into false positive as whether srcu_read_lock is held or not is not
checked implicitly.
From: Madhuparna Bhowmik
Fix the following false positive warnings:
[ 9403.765413][T61744] =
[ 9403.786541][T61744] WARNING: suspicious RCU usage
[ 9403.807865][T61744] 5.7.0-rc1-next-20200417 #4 Tainted: G L
[ 9403.838945][T61744]
From: Madhuparna Bhowmik
This patch fixes the following warning:
=
WARNING: suspicious RCU usage
5.7.0-rc4-next-20200507-syzkaller #0 Not tainted
-
net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
ipmr_new_table() returns
From: Madhuparna Bhowmik
This patch fixes the following warning:
=
WARNING: suspicious RCU usage
5.7.0-rc5-next-20200514-syzkaller #0 Not tainted
-
drivers/net/hamradio/bpqether.c:149 RCU-list traversed in non-reader section!!
Since rtnl
From: Madhuparna Bhowmik
This patch fixes the following warning:
=
WARNING: suspicious RCU usage
5.7.0-rc4-next-20200507-syzkaller #0 Not tainted
-
net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
ipmr_new_table() returns
From: Madhuparna Bhowmik
This patch fixes the following warning:
=
WARNING: suspicious RCU usage
5.7.0-rc4-next-20200507-syzkaller #0 Not tainted
-
net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
ipmr_new_table() returns
From: Madhuparna Bhowmik
Use list_for_each_entry() instead of list_for_each_entry_rcu() whenever
spinlock or mutex is always held.
Otherwise, pass cond to list_for_each_entry_rcu().
Signed-off-by: Madhuparna Bhowmik
---
arch/x86/kernel/nmi.c | 2 +-
arch/x86/kvm/irq_comm.c| 3
From: Madhuparna Bhowmik
This patch fixes the following warning and other usage of
RCU list in eventfd.c
[29179.937976][T75781] WARNING: suspicious RCU usage
[29179.942789][T75781] 5.7.0-rc3-next-20200429 #1 Tainted: G O L
[29179.949752][T75781] -
From: Madhuparna Bhowmik
This patch fixes the following warning and few other
instances of traversal of evm_config_xattrnames list:
[ 32.848432] =
[ 32.848707] WARNING: suspicious RCU usage
[ 32.848966] 5.7.0-rc1-6-ga8d5875ce5f0b #1 Not tainted
[
From: Madhuparna Bhowmik
Fix the following false positive warnings:
[ 9403.765413][T61744] =
[ 9403.786541][T61744] WARNING: suspicious RCU usage
[ 9403.807865][T61744] 5.7.0-rc1-next-20200417 #4 Tainted: G L
[ 9403.838945][T61744]
23 matches
Mail list logo
