On 06/21/2017 02:11 PM, Kalle Valo wrote:
David Miller writes:
From: Jia-Ju Bai
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 (acquire the lock by spin_lock)
ioremap --> may sleep
To fix
On 2017/6/21 21:40, Kalle Valo wrote:
Jia-Ju Bai writes:
On 06/21/2017 02:11 PM, Kalle Valo wrote:
David Miller writes:
From: Jia-Ju Bai
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
I try 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
static analysis tool (DSAC-2) and checked by my
code review.
I do not know how to correctly fix this bug, so I just report them.
Maybe cgwb_kill() should not be called with holding a spinlock.
Best wishes,
Jia-Ju Bai
with GFP_ATOMIC.
This bug is found by my static analysis tool (DSAC-2) and checked by
my code review.
Signed-off-by: Jia-Ju Bai
---
mm/mempool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/mempool.c b/mm/mempool.c
index 5c9dce34719b..d33bd5d622e7 100644
--- a/mm
/rtmutex.c, 1249: _raw_spin_lock_irqsave in rt_mutex_slowlock
This bug is found by my static analysis tool (DSAC-2) and checked by my
code review.
I do not know how to correctly fix this bug, so I just report them.
Best wishes,
Jia-Ju Bai
409: spin_lock in kcov_ioctl
This bug is found by my static analysis tool (DSAC-2) and checked by my
code review.
I do not know how to correctly fix this bug, so I just report them.
Best wishes,
Jia-Ju Bai
On 2018/6/21 11:38, Matthew Wilcox wrote:
On Thu, Jun 21, 2018 at 11:07:14AM +0800, Jia-Ju Bai wrote:
The kernel may sleep with holding a spinlock.
The function call path (from bottom to top) in Linux-4.16.7 is:
[FUNC] remove_element(GFP_KERNEL)
mm/mempool.c, 250: remove_element in
On 2018/6/21 11:43, Al Viro wrote:
On Thu, Jun 21, 2018 at 11:20:59AM +0800, Jia-Ju Bai wrote:
The kernel may sleep with holding a spinlock.
The function call path (from bottom to top) in Linux-4.16.7 is:
[FUNC] vfree --> can sleep
kernel/kcov.c, 237: vfree in kcov_put
kernel/kcov.c,
The argument "gfp_t flags" is not used in kasan_unpoison_element()
and remove_element(), so remove it.
Signed-off-by: Jia-Ju Bai
---
mm/mempool.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/mempool.c b/mm/mempool.c
index 5c9dce34719b..3076ab3f7
I am looking forward to your reply, thanks in advance :)
Best wishes,
Jia-Ju Bai
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 be
sults are right.
Could someone please give me explanation?
Thanks in advance :)
Best wishes,
Jia-Ju Bai
] 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
way to fix, so I only report.
This is found by my static analysis tool (DSAC).
Best wishes,
Jia-Ju Bai
,
Jia-Ju Bai
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
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 in
/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 that
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
,
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
acquired again.
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
/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
ot;.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
keyspan_probe() is never called in atomic context.
It calls usb_alloc_coherent() with GFP_ATOMIC, which is not necessary.
GFP_ATOMIC can be replace 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
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
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
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
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
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
sr9700_bind() 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/net/usb/sr9700.c | 2 +-
1 file changed
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_reset_dac() and hw_card_init() are never
called in atomic context.
They 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
---
sound
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
pcmcia_fixup_iowidth() and pcmcia_enable_device() 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
gpio_poweroff_do_poweroff() 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/power/reset/gpio
piix4_poweroff() is never called in atomic context.
It calls mdelay() to busily wait, which is not necessary.
mdelay() can be replaced with msleep() and usleep_range().
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/power/reset/piix4
syscon_poweroff() 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/power/reset/syscon-poweroff.c | 2
omap_rtc_power_off() 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/rtc/rtc-omap.c | 2 +-
1 file
mrst_read_time() 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/rtc/rtc-mrst.c | 2 +-
1 file
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
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(-)
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
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
d 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
.
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
--- a
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
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 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
--- a
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
: 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
The function synth_alloc_pages 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
---
sound/pci/emu10k1/memory.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/emu10k1/memory.c b
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
---
arch/x86/kernel/apic/io_apic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic
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
---
arch/x86/kernel/tboot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tboot.c b/arch/x86
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
---
arch/x86/kernel/early-quirks.c |2 +-
1 file changed
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?
T
found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
arch/x86/platform/efi/quirks.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 8a99a2e..b6dcb52 100644
--- a/arch
The function ioc_create_icq here is not called in atomic context.
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
---
block/blk-mq-sched.c |2 +-
1 file changed, 1
On 2018/1/25 10:58, Al Viro wrote:
On Thu, Jan 25, 2018 at 10:46:26AM +0800, Jia-Ju Bai wrote:
The function ioc_create_icq here is not called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a static analysis tool named DCNS
After checking all possible call chains to init_tag_map here,
my tool finds that init_tag_map is never called in atomic context.
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
On 2018/1/25 11:34, Jens Axboe wrote:
On 1/24/18 7:46 PM, Jia-Ju Bai wrote:
The function ioc_create_icq here is not called in atomic context.
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.
But
After checking all possible call chains to kmalloc here,
my tool finds that kmalloc is never called in atomic context.
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
On 2018/1/25 12:16, Al Viro wrote:
On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote:
I have checked the given call chain, and find that nvme_dev_disable in
nvme_timeout calls mutex_lock that can sleep.
Thus, I suppose this call chain is not in atomic context.
... or it is broken
On 2018/1/25 11:44, Jens Axboe wrote:
On 1/24/18 8:38 PM, Jia-Ju Bai wrote:
After checking all possible call chains to kmalloc here,
my tool finds that kmalloc is never called in atomic context.
Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
This is found by a
After checking all possible call chains to kzalloc here,
my tool finds that this kzalloc is never called in atomic context.
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
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
---
crypto/crypto_user.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index
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
---
drivers/acpi/osl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi
analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/ata/sata_mv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index cc208b7..42d4589 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
it821x_firmware_command
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
---
drivers/ata/pata_it821x.c |2 +-
1 file changed, 1 insertion(+), 1
-Ju Bai
---
drivers/ata/pata_pdc2027x.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_pdc2027x.c b/drivers/ata/pata_pdc2027x.c
index ffd8d33..4e8584d 100644
--- a/drivers/ata/pata_pdc2027x.c
+++ b/drivers/ata/pata_pdc2027x.c
@@ -580,7 +580,7 @@ static
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
---
drivers/atm/fore200e.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 6ebc4e4
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
---
driv
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
---
drivers/atm/idt77252.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
(), 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
---
drivers/atm/solos-pci.c
v->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 Bai
On 2018/1/19 9:11, Francois Romieu wrote:
Jia-Ju Bai :
[...]
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! Tx Ring full when que
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
---
drivers/atm/
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
found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/base/power/domain.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0c80bea..f84ac72 100644
--- a/drivers
mutex_lock that can sleep.
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 Bai
---
drivers/opp/cpu.c |2
analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/bcma/driver_chipcommon_pmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bcma/driver_chipcommon_pmu.c
b/drivers/bcma/driver_chipcommon_pmu.c
index f1eb4d3..478948c 100644
--- a
tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/block/aoe/aoenet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c
index 63773a9..d5fff7a 100644
--- a/drivers/block/aoe/aoenet.c
+++ b/drivers
DAC960_DetectController() 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
---
drivers/block/DAC960.c |2 +-
1 file changed, 1 insertion
() that can sleep,
so it indicates that DAC960_CreateAuxiliaryStructures() 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
---
drivers/block
On 2018/1/26 18:26, Pavel Machek wrote:
On Fri 2018-01-26 16:38:19, Jia-Ju Bai wrote:
After checking all possible call chains to genpd_dev_pm_detach() and
genpd_dev_pm_attach() here,
my tool finds that these functions are never called in atomic context,
namely never in an interrupt handler or
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
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 to a
drbd_resync_finished()
can call function which can 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
---
drivers/block/drbd/drbd_worker.c |2 +-
1 file changed, 1 insertion(+), 1
found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/auxdisplay/charlcd.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/auxdisplay/charlcd.c b/drivers/auxdisplay/charlcd.c
index 642afd8..9e84795 100644
--- a/drivers
call functions that can sleep.
Thus mdelay can be replaced with msleep to avoid busy wait.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/block/mtip32xx/mtip32xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
call functions that can sleep.
Thus mdelay can be replaced with msleep to avoid busy wait.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/block/mtip32xx/mtip32xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
patch,
so it indicates that mtip_handle_tfe() can call functions that can sleep.
Thus mdelay can be replaced with msleep to avoid busy wait.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/block/mtip32xx/mtip32xx.c |2 +-
1 file
it indicates that on26_test_port() can call functions that can sleep.
Thus mdelay can be replaced with msleep to avoid busy wait.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai
---
drivers/block/paride/on26.c |2 +-
1 file changed, 1 insertion
1 - 100 of 755 matches
Mail list logo
