written by myself.
Signed-off-by: Jia-Ju Bai
---
sound/usb/quirks.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index acbeb52f6fd6..9eed650c54d4 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1181,7 +1181,7
hw_pll_init(), hw_dac_stop(), hw_dac_start() and hw_adc_init()
are never called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
reset() and init_display() are never called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/staging/fbtft
On 2018/7/27 18:34, Andy Shevchenko wrote:
On Fri, Jul 27, 2018 at 12:21 PM, Jia-Ju Bai wrote:
reset() and init_display() are never called in atomic context.
They call mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
gpio_set_value(par
usb_probe() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC 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
---
drivers/input/misc/yealink.c | 4
wdt87xx_resume() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/input/touchscreen/wdt87xx_i2c.c | 2
aiptek_probe() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC 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
---
drivers/input/tablet/aiptek.c
powermate_alloc_buffers() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC 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
---
drivers/input/misc
atp_open(), atp_recover() and atp_resume() are never
called in atomic context.
They call usb_submit_urb() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC 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
".force_die" in the kernel code.
So calling the function pointer in line 573 may cause a null pointer
dereference.
Best wishes,
Jia-Ju Bai
On 2018/7/26 22:12, Greg KH wrote:
On Thu, Jul 26, 2018 at 10:02:22PM +0800, Jia-Ju Bai wrote:
In Linux-4.16, drivers/staging/lustre/lustre/ptlrp/sec.c,
Please look at the 4.18-rc6 release for this file.
In short, nothing to worry about anymore :)
Looks good now :)
Best wishes,
Jia-Ju
,
Jia-Ju Bai
On 2018/8/11 10:44, Steven Rostedt wrote:
On Sat, Aug 11, 2018 at 10:35:24AM +0800, Jia-Ju Bai wrote:
The driver may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] schedule
kernel/locking/rtmutex.c, 1223:
schedule
/locking/rtmutex.c, 1249:
_raw_spin_lock_irqsave in rt_mutex_slowlock
To fix the bug, the spinlock is released before the loop of schedule()
This is found by my static analysis tool (DSAC).
Signed-off-by: Jia-Ju Bai
---
v2:
* Release the spinlock before the loop, instead of v1
kernel/locking/rtmutex.c, 1249:
_raw_spin_lock_irqsave in rt_mutex_slowlock
To fix the bug, the spinlock is released before schedule() and then acquired
again.
This is found by my static analysis tool (DSAC).
Signed-off-by: Jia-Ju Bai
---
kernel/locking/rtmutex.c | 6 --
1 file changed
way to fix, so I only report.
This is found by my static analysis tool (DSAC).
Best wishes,
Jia-Ju Bai
On 2018/8/13 20:42, Paul E. McKenney wrote:
On Mon, Aug 13, 2018 at 05:26:49PM +0800, Jia-Ju Bai wrote:
On 2018/8/13 12:18, Paul E. McKenney wrote:
On Mon, Aug 13, 2018 at 11:04:10AM +0800, Jia-Ju Bai wrote:
The kernel may sleep with holding a spinlock.
The function call paths (from
in
rcu_torture_timer
kernel/rcu/rcutorture.c, 1104: spin_lock in rcu_torture_timer
Note that [FUNC_PTR] means a function pointer call is used.
I do not find a good way to fix, so I only report.
This is found by my static analysis tool (DSAC).
Thanks,
Jia-Ju Bai
/callback_proc.c, 544: referring_call_exists in nfs4_callback_sequence
fs/nfs/callback_proc.c, 504: spin_lock in nfs4_callback_sequence
I do not find a good way to fix, so I only report.
This is found by my static analysis tool (DSAC).
Thanks,
Jia-Ju Bai
(), and
then be acquired again.
This is found by my static analysis tool (DSAC).
Thanks,
Jia-Ju Bai
,
Jia-Ju Bai
.
This is found by my static analysis tool (DSAC).
Signed-off-by: Jia-Ju Bai
---
fs/jffs2/malloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index ce1189793288..66496ef09716 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2
/pnfs_nfs.c, 154: spin_lock in pnfs_generic_recover_commit_reqs
I do not find a good way to fix, so I only report.
This is found by my static analysis tool (DSAC).
Thanks,
Jia-Ju Bai
On 2018/8/13 12:18, Paul E. McKenney wrote:
On Mon, Aug 13, 2018 at 11:04:10AM +0800, Jia-Ju Bai wrote:
The kernel may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] schedule_timeout_interruptible
kernel/rcu/rcutorture.c, 523
On 2018/8/13 16:56, Jan Kara wrote:
Hi,
On Mon 13-08-18 11:10:23, Jia-Ju Bai wrote:
The kernel may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] schedule
fs/dax.c, 259: schedule in get_unlocked_mapping_entry
fs/dax.c, 450
] means a function pointer call is used.
I do not find a good way to fix it, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and
checked by my code review.
Best wishes,
Jia-Ju Bai
k_mutex;
map->unlock = regmap_unlock_mutex;
lockdep_set_class_and_name(>mutex,
lock_key, lock_name);
}
But after reading the code, I cannot find the relationship between the
if condition and atomic context.
I am looking forward to your reply, than
On 2018/8/28 16:49, Johan Hovold wrote:
On Mon, Aug 27, 2018 at 10:55:17PM +0200, Alexandre Belloni wrote:
Hi,
On 30/07/2018 21:53:14+0800, Jia-Ju Bai wrote:
omap_rtc_power_off() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can
elf.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/bfusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/bfusb.c b/drivers/bluetooth/bfusb.c
index ab090a313a5f..0588639b899a 100644
--- a/drivers/blu
it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/btmrvl_sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 6f99b9f3d57f..af36ed6376ad 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers
alysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/bpa10x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/bpa10x.c b/drivers/bluetooth/bpa10x.c
found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
essary. GFP_ATOMIC can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/bluecard_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/hci_qca.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 05ec530b8a3a..021d966b8f08 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b
.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/bluetooth/hci_intel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
index 7c166e3b308b..46ace321bf60 100644
by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/firmware/memmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 5de3ed29282c..598eb0511097 100644
s is found by a static analysis tool named DCNS written by myself.
I also manually check the kernel code before reporting it.
Signed-off-by: Jia-Ju Bai
---
drivers/firewire/sbp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
index 6b
-by: Jia-Ju Bai
---
drivers/firewire/init_ohci1394_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firewire/init_ohci1394_dma.c
b/drivers/firewire/init_ohci1394_dma.c
index 2cc89ce745c9..6b5a3c12f715 100644
--- a/drivers/firewire/init_ohci1394_dma.c
+++ b/drivers
Thanks for the reply :)
On 2018/7/23 20:24, Stefan Richter wrote:
Adding Cc: LSML
On Jul 23 Jia-Ju Bai wrote:
sbp2_scsi_queuecommand() is only set to .queuecommand of
"struct scsi_host_template", and this function pointer is never called
in atomic context.
As far as
/usb_ops_linux.c, 604:
rtw_chk_hi_queue_cmd in usb_write_port_complete
To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC.
These bugs are found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 4 ++--
1 file changed, 2
:
spin_lock_irq in srp_send_tsk_mgmt
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/infiniband/core/mad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
:
_raw_spin_lock_irqsave in lg4ff_play
To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/hid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
To fix this bug, msleep() is replaced with mdelay().
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/infiniband/hw/hns/hns_roce_hem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_hem.c
b/drivers
, 5241:
_raw_spin_lock_irqsave in intel_iommu_enable_pasid
To fix this bug, usleep_range() is replaced with udelay().
This bug is found by my static analysis tool DSAC.
Signed-off-by: Jia-Ju Bai
---
drivers/pci/controller/dwc/pcie-designware.c | 2 +-
1 file changed, 1 insertion(+), 1
On 2018/9/5 16:29, Jiri Kosina wrote:
On Sat, 1 Sep 2018, Jia-Ju Bai wrote:
The driver may sleep with holding a spinlock.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] hid_alloc_report_buf(GFP_KERNEL)
drivers/hid/hid-core.c, 1435:
hid_alloc_report_buf
e give me explanation?
Thanks in advance :)
Best wishes,
Jia-Ju Bai
On 2018/9/11 15:49, Sebastian Andrzej Siewior wrote:
On 2018-09-01 16:12:10 [+0800], Jia-Ju Bai wrote:
wdm_in_callback() is a completion handler function for the USB driver.
So it should not sleep. But it calls service_outstanding_interrupt(),
which calls usb_submit_urb() with GFP_KERNEL
On 2018/9/11 16:40, Gustavo Pimentel wrote:
Hi Jia,
On 02/09/2018 04:38, Jia-Ju Bai wrote:
The driver may sleep with holding a spinlock and in an interupt handler.
The function call paths (from bottom to top) in Linux-4.16 are:
[FUNC] usleep_range
drivers/pci/dwc/pcie-designware.c, 181
uot;.
It's trickier to say for sure when you're not holding a lock...
Jia-Ju Bai is working on this. The tool is available on github. It's
still being improved, though, so perhaps it's not yet ready for eg 0-day
inclusion. He can give more details.
Thanks for Julia's recommendation :)
The function tboot_wait_for_aps is not called in atomic context.
Thus mdelay can be replaced with usleep_range, to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
arch/x86/kernel/tboot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ar
The function __add_pin_to_irq_node is not called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
arch/x86/kernel/apic/io_apic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The function apple_airport_reset is not called in atomic context.
Thus mdelay can be replaced with usleep_range, to avoid busy wait.
This is reported by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
arch/x86/kernel/early-qu
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!
On 2018/1/24 19:47, Thomas Gleixner wrote:
On Wed, 24 Jan 2018, Jia-Ju Bai wrote:
The function tboot_wait_for_aps is not called in atomic context.
Thus mdelay can be replaced with usleep_range, to reduce busy wait.
And how did you establish that it's not called in atomic context?
Thanks
Despite never getting called from atomic context, ks7010_upload_firmware()
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-o
-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/spi/spi-topcliff-pch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index 97d1375..dc93ca9 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/s
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
ossibility of sucessful allocation.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/xen/xen-pciback/conf_space_quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/conf_space_quirks.c
b/drivers/xen/xen-pciback/conf_space_quirks.c
ind
ontext.
Despite never getting called from atomic context,
pcistub_device_alloc() calls kzalloc() with GFP_ATOMIC,
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.
Signed-of
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>
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/xen/xen-pciback/pci_stub.c | 2 +-
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&
() 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
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
,
dm_TXPowerTrackingCallback_TSSI() 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>
---
d
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/staging/rtl8192u/r8192U_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softma
f 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/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
ossibility 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/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 2 +-
1 file changed, 1 insertion(
location.
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/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
.
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/platform/x86/intel_scu_ipc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platfo
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
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/scsi/st.c | 2 +-
1 file changed, 1 insertio
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>
-
ff-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/ntb/ntb_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index f58d8e3..2c0c8bc 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb
check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/ntb/ntb_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
index f58d8e3..08c9157 100644
--- a/drivers/ntb/ntb_transport.c
+++ b/drive
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
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
eck it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index f9308c2..2f064
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
lso manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/thermal/armada_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ae75328..0825a7a 100644
--- a/dr
elf.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/thermal/armada_thermal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ae75328..807fe74 100644
--- a/dr
elf.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/thermal/armada_thermal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ae75328..c289ae4 100644
--- a/dr
static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/tty/ipwireless/network.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/ipwireless/network.c b/drivers/tty/ipwi
usily 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/ide/hpt366.c | 2 +-
1 file changed, 1 insertio
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 16:33, Sergei Shtylyov wrote:
Hello!
On 4/11/2018 10:52 AM, Jia-Ju Bai wrote:
detect_pll_input_clock() is never called in atomic context.
detect_pll_input_clock() is only called by init_chipset_pdcnew(), which
is set as ".init_chipset" in struct ide_port_info.
Thi
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() <-
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/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
1 file chan
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/infiniband/hw/i40iw/i40iw_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c
b/drivers/infiniband/hw/i40iw/i40iw_main.c
index 27590ae..b86bda8 100644
--- a/drive
MIC,
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:
00()
calls mdelay() to busily 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/gpu/drm/
aiting.
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/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/dr
DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm
ic context, detect_pll_input_clock()
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>
-
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
) 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/ide/pdc202xx_new.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ide/
ic context, detect_pll_input_clock()
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>
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 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
301 - 400 of 1251 matches
Mail list logo
