;sc->next_chan"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wireless/ath/ath9k/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath
On 2018/5/8 13:04, Eric Dumazet wrote:
On 05/07/2018 07:16 PM, Jia-Ju Bai wrote:
Yes, ">stats" will not change, because it is a fixed address.
But the field data in "dev->stats" is changed (rx_frame_errors, rx_crc_errors
and rx_missed_errors).
So if the driver ret
On 2018/5/8 9:56, Eric Dumazet wrote:
On 05/07/2018 05:51 PM, Jia-Ju Bai wrote:
On 2018/5/7 22:15, Eric Dumazet wrote:
On 05/07/2018 07:08 AM, Jia-Ju Bai wrote:
The write operations to "dev->stats" are protected by
the spinlock on line 862-864, but the read operations to
this
On 2018/5/7 22:15, Eric Dumazet wrote:
On 05/07/2018 07:08 AM, Jia-Ju Bai wrote:
The write operations to "dev->stats" are protected by
the spinlock on line 862-864, but the read operations to
this data on line 858 and 867 are not protected by the spinlock.
Thus, there may exi
operations to "dev->stats" are
protected by the spinlock, and a local variable is used for return.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/8390/lib8390.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/et
On 2018/4/12 10:21, arvindY wrote:
On Thursday 12 April 2018 07:00 AM, Jia-Ju Bai wrote:
On 2018/4/12 0:16, James Bottomley wrote:
On Wed, 2018-04-11 at 23:39 +0800, Jia-Ju Bai wrote:
de4x5_hw_init() is never called in atomic context.
de4x5_hw_init() is only called by de4x5_pci_probe
On 2018/4/12 0:19, Florian Fainelli wrote:
On 04/11/2018 12:14 AM, Jia-Ju Bai wrote:
On 2018/4/11 13:30, Phil Reid wrote:
On 11/04/2018 09:51, Jia-Ju Bai wrote:
b53_switch_reset_gpio() is never called in atomic context.
The call chain ending up at b53_switch_reset_gpio() is:
[1
sis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Use gpio_set_value_cansleep() to replace gpio_set_value() additionally.
Thanks for Florian and Phil for good advice.
---
drivers/net/dsa/b53/b53_common.c | 8 ++
On 2018/4/12 0:16, James Bottomley wrote:
On Wed, 2018-04-11 at 23:39 +0800, Jia-Ju Bai wrote:
de4x5_hw_init() is never called in atomic context.
de4x5_hw_init() is only called by de4x5_pci_probe(), which is only
set as ".probe" in struct pci_driver.
Despite never getting called f
er getting called from atomic context, sxgbe_sw_reset()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
e replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Use usleep_range() to correct usleep() in v1.
---
drivers/net/et
On 2018/4/11 22:26, David Miller wrote:
From: Jia-Ju Bai <baijiaju1...@gmail.com>
Date: Wed, 11 Apr 2018 16:20:22 +0800
Okay, I now know why many of my patches were not replied.
Many of your patches are not responded to because you handle patch
feedback poorly sometimes.
Okay,
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice.
v3:
* Modify wrong text in description in v2.
Thank Ying for good advice.
---
net/tipc/m
On 2018/4/11 18:11, Ying Xue wrote:
On 04/10/2018 09:17 AM, Jia-Ju Bai wrote:
tipc_mon_create() is never called in atomic context.
The call chain ending up at dn_route_init() is:
Sorry, I don't think there is any relationship between the following
call chain with dn_route_init().
[1
On 2018/4/11 16:17, Greg KH wrote:
On Wed, Apr 11, 2018 at 04:11:00PM +0800, Jia-Ju Bai wrote:
On 2018/4/11 16:03, Greg KH wrote:
On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote:
On 2018/4/11 14:41, Greg KH wrote:
On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote
On 2018/4/11 16:03, Greg KH wrote:
On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote:
On 2018/4/11 14:41, Greg KH wrote:
On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote:
stir421x_fw_upload() is never called in atomic context.
The call chain ending up
On 2018/4/11 14:41, Greg KH wrote:
On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote:
stir421x_fw_upload() is never called in atomic context.
The call chain ending up at stir421x_fw_upload() is:
[1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe()
irda_usb
On 2018/4/11 13:30, Phil Reid wrote:
On 11/04/2018 09:51, Jia-Ju Bai wrote:
b53_switch_reset_gpio() is never called in atomic context.
The call chain ending up at b53_switch_reset_gpio() is:
[1] b53_switch_reset_gpio() <- b53_switch_reset() <-
b53_reset_switch() <-
lled from atomic context, fcpci_init()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmai
tomic context, fcpcipnp_setup()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
er getting called from atomic context, sxgbe_sw_reset()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
e replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ieee802154/atusb.c | 2 +-
1
ten by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
b/drivers/net/ethernet/intel/
e replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
1 file changed, 1 insertio
myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 274f367..e070ff6 100
ry and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/can/sja1000/peak_pcmcia.c | 2 +-
1 file changed, 1 insertio
sy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/can/sja1000/peak_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/sja10
sy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/staging/irda/drivers/irda-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/stag
gned-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/staging/irda/drivers/irda-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/irda/drivers/irda-usb.c
b/drivers/staging/irda/drivers/irda-usb.c
index 723e49b..c6c8c2c 100644
--- a/drivers/sta
MIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/u
usily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wan/sbni.c | 2 +-
1 file chang
and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wimax/i2400m/tx
also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wireless/broadcom/b43legacy/dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43legacy/dma.c
b/drivers/net/wireless/broadcom/b43legacy/dma.c
() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wireless/cisco/airo.c | 2
sy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wireless/zydas/zd1201.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1
allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com&
Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice.
---
net/decnet/dn_route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 0bd3afd..59ed12a 100644
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice.
---
net/tipc/monitor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --gi
also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice.
---
net/ncsi/ncsi-manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/n
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice.
---
net/tipc/monitor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --gi
with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice.
---
net/decnet/dn_route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 0bd3afd..59ed12a 100644
On 2018/4/9 22:44, Eric Dumazet wrote:
On 04/09/2018 07:10 AM, Jia-Ju Bai wrote:
dn_route_init() is never called in atomic context.
The call chain ending up at dn_route_init() is:
[1] dn_route_init() <- decnet_init()
decnet_init() is only set as a parameter of module_init().
Despite ne
On 2018/4/9 22:42, Eric Dumazet wrote:
On 04/09/2018 07:10 AM, Jia-Ju Bai wrote:
dccp_init() is never called in atomic context.
This function is only set as a parameter of module_init().
Despite never getting called from atomic context,
dccp_init() calls __get_free_pages() with GFP_ATOMIC
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
net/tipc/monitor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/tipc/monitor.c b/net/tipc/monitor.c
index 9e109bb..9714d80 100644
--
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
net/ncsi/ncsi-manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index 3fd3c39..6b5b5a0 100644
--- a/net/ncsi/ncsi-manage.c
++
off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
net/decnet/dn_route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 0bd3afd..59ed12a 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1898,7 +1898,7 @@ vo
with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
net/dccp/proto.c | 4 ++--
1 file chan
umented to require a mutex held by caller, etc.) -
then a switch to GFP_KERNEL might be appropriate. With analysis
of callchains posted as you are posting that.
* either way, having the tool print the callchains out
would be a good idea - for examining them, for writing reports,
etc.
Thanks for your very helpful advice :)
I will follow it in my patches.
Thanks,
Jia-Ju Bai
On 2018/1/27 0:07, David Miller wrote:
From: Al Viro <v...@zeniv.linux.org.uk>
Date: Fri, 26 Jan 2018 12:05:22 +
On Fri, Jan 26, 2018 at 04:00:27PM +0800, Jia-Ju Bai wrote:
After checking all possible call chains to fs_send() here,
my tool finds that fs_send() is never called in
On 2018/1/26 21:56, Jia-Ju Bai wrote:
On 2018/1/26 20:05, Al Viro wrote:
On Fri, Jan 26, 2018 at 04:00:27PM +0800, Jia-Ju Bai wrote:
After checking all possible call chains to fs_send() here,
my tool finds that fs_send() is never called in atomic context.
And this function is assigned
On 2018/1/26 20:05, Al Viro wrote:
On Fri, Jan 26, 2018 at 04:00:27PM +0800, Jia-Ju Bai wrote:
After checking all possible call chains to fs_send() here,
my tool finds that fs_send() is never called in atomic context.
And this function is assigned to a function pointer "dev->ops->s
d(), and __vcc_connect() is only called by
vcc_connect(), which calls mutex_lock(),
so it indicates that he_open() can call functions which may sleep.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Sig
t;send(), and vcc_sendmsg() calls schedule(),
it indicates that fs_send() can call functions which may sleep.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...
->dev->ops->send(), and vcc_sendmsg() calls schedule(),
it indicates that atmtcp_v_send() can call functions which may sleep.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Ba
(), and vcc_sendmsg calls schedule,
it indicates that psend() can call functions which may sleep.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com&g
that idt77252_preset() can call functions which can sleep.
Thus mdelay can be replaced with usleep_range to avoid busy wait.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/atm/idt77252.c |2 +-
1 file chan
->dev->ops->send, and vcc_sendmsg calls schedule,
it indicates that fore200e_send can call functions which may sleep.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju
, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/atm/fore200e.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/atm/fore200e.c b/drive
On 2018/1/19 9:11, Francois Romieu wrote:
Jia-Ju Bai <baijiaju1...@gmail.com> :
[...]
The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG!
ere?
If not, how this data race is avoided?
Thanks,
Jia-Ju Bai
On 2018/1/9 17:07, Arend van Spriel wrote:
On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
On 2018/1/9 16:35, Greg KH wrote:
On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay
On 2018/1/9 16:35, Greg KH wrote:
On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with usleep_range,
to reduce busy wait.
Signed-off-by: Jia-Ju Bai
On 2018/1/9 0:31, Larry Finger wrote:
On 01/08/2018 10:21 AM, Kalle Valo wrote:
Jia-Ju Bai <baijiaju1...@gmail.com> wrote:
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce
bus
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with usleep_range,
to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Replace mdelay with usleep_range, instead of msleep in v1.
sky2_vpd_wait is not called in an interrupt handler nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/marvell/sky2.c |2 +-
1 file changed, 1 insertion(+), 1 de
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wireless/broadcom/b43/phy_n.c |2 +-
1 file chan
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/wireless/broadcom/b43/phy_n.c |2 +-
1 file chan
sky2_vpd_wait is not called in an interrupt handler nor holding a spinlock.
The function mdelay in it can be replaced with msleep, to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/marvell/sky2.c |2 +-
1 file changed, 1 insertion(+), 1 de
Sorry,
I think I know your meaning now.
Maybe we can unlock the spinlock before "schedule_timeout_interruptible"
and then lock again?
Like:
spin_unlock(...);
schedule_timeout_interruptible(1);
spin_lock(...);
Best wishes,
Jia-Ju Bai
On 2017/12/14 11:34, David Mi
Sorry, I made a mistake in last e-mail.
Maybe "mdelay(1000/HZ)" or "udelay(100/HZ)" .
Which one do you think is right?
Thanks,
Jia-Ju Bai
On 2017/12/14 11:13, Jia-Ju Bai wrote:
Thanks for reply :)
I think I should use "udelay(10/HZ)" instead, do you thin
Thanks for reply :)
I think I should use "udelay(10/HZ)" instead, do you think it is right?
Thanks,
Jia-Ju Bai
On 2017/12/14 5:20, David Miller wrote:
I want you to review all of your patches and resend them after you
have checked them carefully.
The first patch I e
On 2017/12/14 0:50, Stephen Hemminger wrote:
On Wed, 13 Dec 2017 15:42:56 +0800
Jia-Ju Bai <baijiaju1...@gmail.com> wrote:
On 2017/12/13 13:18, Stephen Hemminger wrote:
On Tue, 12 Dec 2017 20:57:01 -0500 (EST)
David Miller <da...@davemloft.net> wrote:
From: Stephen Hem
ned-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/cadence/macb_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c
b/drivers/net/ethernet/cadence/macb_main.c
index 72a67f7..b02c806 100644
--- a/drivers/net
tic analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
ode review.
Thanks,
Jia-Ju Bai
off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/qlogic/qla3xxx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c
b/drivers/net/ethernet/qlogic/qla3xxx.c
index 8ad3e24..7994d04 100644
--- a/drivers/net/ethernet/qlogic/
is bug is found by my static analysis tool(DSAC) and checked by my code
review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/qlogic/qla3xxx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c
b/drivers/
sis tool(DSAC) and checked by my code
review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/hp/hp100.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c
index c8c7ad2
und by my static analysis tool(DSAC) and checked by my code
review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/net/ethernet/hp/hp100.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/et
eep
usb_kill_urb --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
d Miller <da...@davemloft.net> wrote:
From: Jia-Ju Bai <baijiaju1...@gmail.com>
Date: Tue, 12 Dec 2017 16:38:12 +0800
According to drivers/net/ethernet/marvell/skge.c, the driver may sleep
under a spinlock.
The function call path is:
skge_remove (acquire the spinlock)
free_irq --> may
set (acquire the spinlock)
phy_start_aneg
phy_start_aneg_priv
mutex_lock --> may sleep
I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and
checked by my code review.
Thanks,
Jia-Ju Bai
set (acquire the spinlock)
phy_start_aneg
phy_start_aneg_priv
mutex_lock --> may sleep
I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and
checked by my code review.
Thanks,
Jia-Ju Bai
ead
mutex_lock --> may sleep
I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and
checked by my code review.
Thanks,
Jia-Ju Bai
off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
drivers/net/wireless/mac80211_hwsim.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 10b075a..f2ebf4a 100644
--- a/drivers/net/wireless/mac8021
SAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
my code review.
Thanks,
Jia-Ju Bai
off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
drivers/net/hippi/rrunner.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
index 8483f03..1ab97d9 100644
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/
SAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
errupt (interrupt handler)
vortex_error
vortex_up
pci_set_power_state --> may sleep
pci_enable_device --> may sleep
I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and
checked by my code review.
Th
y code review.
Thanks,
Jia-Ju Bai
No rcu_read_lock is called, but rcu_read_unlock is still called.
Thus rcu_read_unlock should be removed.
Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
drivers/net/wireless/ath/wcn36xx/main.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/mai
it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
crypto/shash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/shash.c b/crypto/shash.c
index 5
.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com>
---
crypto/shash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/shash.c b/crypto/shash.c
index 5e31c8d..8fcecc6 100644
--- a/crypto/shash.c
+++ b/
to report bugs as soon as they are introduced. I report it to
the author and CC the relevant list. If people don't respond to my
email after a month then I complain again.
regards,
dan carpenter
Thanks for your helpful advice.
Thanks,
Jia-Ju Bai
On 2017/6/21 21:40, Kalle Valo wrote:
Jia-Ju Bai <baijiaju1...@163.com> writes:
On 06/21/2017 02:11 PM, Kalle Valo wrote:
David Miller<da...@davemloft.net> writes:
From: Jia-Ju Bai<baijiaju1...@163.com>
Date: Mon, 19 Jun 2017 10:48:53 +0800
The driver may sleep
On 06/21/2017 02:11 PM, Kalle Valo wrote:
David Miller<da...@davemloft.net> writes:
From: Jia-Ju Bai<baijiaju1...@163.com>
Date: Mon, 19 Jun 2017 10:48:53 +0800
The driver may sleep under a spin lock, and the function call path is:
netxen_nic_pci_mem_access_direct (acqu
The driver may sleep under a spin lock, and the function call path is:
netxen_nic_pci_mem_access_direct (acquire the lock by spin_lock)
ioremap --> may sleep
To fix it, the lock is released before "ioremap", and the lock is
acquired again after this function.
Signed-off-b
1 - 100 of 131 matches
Mail list logo
