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
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
quot;hotplug->enabled" is
also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/acpi/scan.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 970dd87d347c..e21d7b0f7179 100644
--- a/drivers/acpi/scan.c
+++ b/d
timeout"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/watchdog/mena21_wdt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/mena21_wdt.c b/drivers/watchdog/mena21_wdt.c
index 25d5d2b8cfbe..05ca69042829 100644
--- a/driv
On 2018/5/8 11:28, Guenter Roeck wrote:
On 05/07/2018 08:18 PM, Jia-Ju Bai wrote:
The write operation to "wdt->timeout" is protected by
the lock on line 118, but the read operation to
this data on line 105 is not protected by the lock.
Thus, there may exist a data race for
;
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/xen/xenbus/xenbus_xs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 49a3874ae6bb..274cdfee08b1 100644
--- a/drivers/x
t;flags"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/ata/ata_piix.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 7ecb1322a514..c99fdf473dee 100644
--- a/drivers/ata/ata_piix.c
On 2018/5/8 11:42, Guenter Roeck wrote:
On 05/07/2018 08:32 PM, Jia-Ju Bai wrote:
On 2018/5/8 11:28, Guenter Roeck wrote:
On 05/07/2018 08:18 PM, Jia-Ju Bai wrote:
The write operation to "wdt->timeout" is protected by
the lock on line 118, but the read operation to
this dat
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 15:02, Juergen Gross wrote:
On 08/05/18 05:34, Jia-Ju Bai wrote:
The read operation to "req->type" is protected by
the lock on line 128, but the write operation to
this data on line 118 is not protected by the lock.
Thus, there may exist a data race for "r
There is already a mutex in the watchdog core which serializes
calls to the various API functions.
So the mutex lock "drv->lock" is unnecessary and can be dropped.
Signed-off-by: Jia-Ju Bai
---
drivers/watchdog/mena21_wdt.c | 18 --
1 file changed, 18 deletions(-
uot;cmnd->scsi_done".
To fix this data race, the write operations on line 634-635
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/usb/storage/uas.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/s
;sc->next_chan"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
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/ath9k/channel.c
index 1b05b5d7a038
t;flags"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/ata/libata-pmp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/libata-pmp.c b/drivers/ata/libata-pmp.c
index 85aa76116a30..42f61106ac70 100644
--- a/drivers/ata/liba
On 2018/5/8 16:27, Oliver Neukum wrote:
Am Dienstag, den 08.05.2018, 15:47 +0800 schrieb Jia-Ju Bai:
The write operations to "cmnd->result" and "cmnd->scsi_done"
are protected by the lock on line 642-643, but the write operations
to these data on line 634-635 are
;alloc->buffer"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai
---
drivers/android/binder_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 5a426c877dfb..596acc3a84e4 100644
--- a/drive
On 2018/5/9 4:17, Rafael J. Wysocki wrote:
On Tue, May 8, 2018 at 5:08 AM, Jia-Ju Bai wrote:
The write operation to "hotplug->enabled" is protected by
the lock on line 1760, but the read operation to
this data on line 1755 is not protected by the lock.
Thus, there may exis
t; may sleep
This bug is found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
ode review.
Signed-off-by: Jia-Ju Bai
---
lib/parser.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/parser.c b/lib/parser.c
index 3278958..bc6e2ce 100644
--- a/lib/parser.c
+++ b/lib/parser.c
@@ -133,7 +133,7 @@ static int match_number(substring_t *s, int *result,
code review.
A possible fix is to remove cond_resched in __copy_gigantic_page.
Thanks,
Jia-Ju Bai
Thanks for your reply.
I agree that extra allocation in match_number() and match_u64int() may
be unnecessary.
Thanks,
Jia-Ju Bai
On 2017/10/7 9:37, Linus Torvalds wrote:
On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote:
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found
my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
ile
posix_lock_inode (fs/locks.c)
locks_get_lock_context
kmem_cache_alloc(GFP_KERNEL) --> may sleep
To fix them, GFP_KERNEL is replaced with GFP_ATOMIC.
These bugs are found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
fs/locks.c |2 +-
; again after them.
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
uot; and
"__cond_resched_lock".
I know that "__cond_resched_lock" is safe and okay to be called when
holding a spinlock.
However, I think "___might_sleep" can be removed, because it prints
error messages in this situation, but it is safe in fact.
Am I right? I am looking forward to your comments :)
Thanks,
Jia-Ju Bai
off-by: Jia-Ju Bai
---
drivers/staging/rtl8188eu/core/rtw_cmd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 9461bce..65083a7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cm
off-by: Jia-Ju Bai
---
drivers/staging/rtl8188eu/core/rtw_pwrctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
b/drivers/staging/rtl8188eu/core/rtw_pwrctrl.c
index f86c9ce..2913661 100644
--- a/drivers/staging/rtl8188eu/c
iew.
Signed-off-by: Jia-Ju Bai
---
drivers/staging/rtl8188eu/core/rtw_cmd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 9461bce..430b8eb 100644
--- a/drivers/staging/rtl8188eu/c
off-by: Jia-Ju Bai
---
drivers/staging/rtl8188eu/core/rtw_cmd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 9461bce..65083a7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cm
CC to mailing list.
On 2017/10/8 20:13, Jia-Ju Bai wrote:
The driver may sleep under a spinlock when calling the function
"ips_leave", which causes some possible sleep-in-atomic bugs.
Here are several examples:
rtw_set_802_11_disassociate (acquire the spinlock)
_rtw_pwr_wakeup
rs/pci/pci.c.
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
p_parking
arcmsr_stop_adapter_bgrb
arcmsr_hbaD_stop_bgrb
arcmsr_hbaD_wait_msgint_ready
msleep --> may sleep
To fix them, msleep is replaced with mdelay.
These bugs are found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/scsi/arcmsr/
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
---
drivers/net/wireless/ath/wcn36xx/main.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless
Jia-Ju Bai
y code review.
Thanks,
Jia-Ju Bai
lay in
__pci_start_power_transition in drivers/pci/pci.c.
This bug is found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
ock --> may sleep
A possible fix is to use spinlock instead of mutex lock in
pcmcia_access_config in drivers/pcmcia/pcmcia_resource.c.
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
)
_request_firmware_prepare
kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC in _request_firmware_prepare.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/base/firmware_class.c |
off-by: Jia-Ju Bai
---
sound/drivers/opl3/opl3_synth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/drivers/opl3/opl3_synth.c b/sound/drivers/opl3/opl3_synth.c
index ddcc1a3..2e1cb2b 100644
--- a/sound/drivers/opl3/opl3_synth.c
+++ b/sound/drivers/opl3/opl3_synt
According to seq_virmidi.c, the driver may sleep under a read spinlock.
The function call path is:
snd_virmidi_dev_receive_event (acquire the spinlock)
snd_seq_dump_var_event
copy_from_user --> may sleep
This bug is found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
ode review.
Signed-off-by: Jia-Ju Bai
---
fs/cachefiles/namei.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c
index 3978b32..39e1504 100644
--- a/fs/cachefiles/namei.c
+++ b/fs/cachefiles/namei.c
@@ -83,7 +83,7 @@ static noinl
ter this function.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/scsi/fnic/fnic_fcs.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/fnic/fnic_fcs.c b/drivers/scsi/fnic/fnic_fcs.c
index 999fc75..4c99c96 100644
--- a/driv
According to fs/dcache.c, might_sleep is called under a spinlock,
and the function call path is:
d_prune_aliases (acquire the spinlock)
dput
might_sleep
This bug is found by my static analysis tool and my code review.
A possible fix is to remove might_sleep in dput.
Thanks,
Jia-Ju Bai
logoff
mutex_lock --> may sleep
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
rports
fc_rport_logoff
mutex_lock --> may sleep
These bugs are found by my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
Thanks for your detailed explanation :)
I will improve my static analysis tool.
Thanks,
Jia-Ju Bai
On 2017/10/3 11:19, Al Viro wrote:
On Tue, Oct 03, 2017 at 10:38:25AM +0800, Jia-Ju Bai wrote:
According to fs/dcache.c, might_sleep is called under a spinlock,
and the function call path
my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/block/drbd/drbd_nl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index a12f77e..713c965 100644
--- a/drivers/block/drbd/drbd_nl.c
++
tic analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/block/drbd/drbd_nl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index a12f77e..ad093da 100644
--- a/drivers/block/drbd/drbd_nl.c
++
my static analysis tool and my code review.
Thanks,
Jia-Ju Bai
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
---
v2:
* Replace mdelay with usleep_range, instead of msleep in v1.
Thank Larry for good advice
On 2018/1/9 0:31, Larry Finger wrote:
On 01/08/2018 10:21 AM, Kalle Valo wrote:
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 msleep, to reduce
busy wait.
Signed-off-by: Jia-Ju Bai
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 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 2017/12/19 1:05, Stephen Hemminger wrote:
On Mon, 18 Dec 2017 17:02:52 +0800
Jia-Ju Bai wrote:
The kzalloc function is called with GFP_ATOMIC.
But according to driver call graph, it is not in atomic context,
namely no spinlock is held nor in an interrupt handler.
This GFP_ATOMIC
iew.
Signed-off-by: Jia-Ju Bai
---
drivers/media/platform/sti/bdisp/bdisp-hw.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c
b/drivers/media/platform/sti/bdisp/bdisp-hw.c
index b7892f3..b63d9c9 100
On 2017/12/19 18:43, Fabien DESSENNE wrote:
Hi,
On 16/12/17 12:54, Jia-Ju Bai wrote:
The driver may sleep under a spinlock.
The function call path is:
bdisp_device_run (acquire the spinlock)
bdisp_hw_reset
msleep --> may sleep
To fix it, readl_poll_timeout_atomic is u
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
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
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
---
drivers/net/ethernet/marvell/sky2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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
---
drivers/net/wireless/broadcom/b43/phy_n.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
rtl8192_usb_probe is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with msleep,
to avoid busy wait.
Signed-off-by: Jia-Ju Bai
---
drivers/staging/rtl8192u/r8192U_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
imm_init 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
---
drivers/scsi/imm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/imm.c b
i40iw_wait_pe_ready 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
---
drivers/infiniband/hw/i40iw/i40iw_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
iew.
Signed-off-by: Jia-Ju Bai
---
drivers/media/platform/sti/bdisp/bdisp-hw.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c
b/drivers/media/platform/sti/bdisp/bdisp-hw.c
index b7892f3..e94a371 100644
--- a/driv
Hi,
On 2017/12/15 22:51, Fabien DESSENNE wrote:
Hi
On 12/12/17 14:47, Jia-Ju Bai wrote:
The driver may sleep under a spinlock.
The function call path is:
bdisp_device_run (acquire the spinlock)
bdisp_hw_reset
msleep --> may sleep
To fix it, msleep is replaced with mdelay.
Ma
The kzalloc function is called with GFP_ATOMIC.
But according to driver call graph, it is not in atomic context,
namely no spinlock is held nor in an interrupt handler.
This GFP_ATOMIC is unnecessary, and replace with GFP_KERNEL.
Signed-off-by: Jia-Ju Bai
---
drivers/hv/hv.c |2 +-
1 file
On 2017/12/18 16:54, Vitaly Kuznetsov wrote:
Jia-Ju Bai writes:
The kzalloc function is called with GFP_ATOMIC.
But according to driver call graph, it is not in atomic context,
namely no spinlock is held nor in an interrupt handler.
This GFP_ATOMIC is unnecessary, and replace
The kzalloc function is called with GFP_ATOMIC.
But according to driver call graph, it is not in atomic context,
namely no spinlock is held nor in an interrupt handler.
This GFP_ATOMIC is unnecessary, and replace with GFP_KERNEL.
Signed-off-by: Jia-Ju Bai
---
drivers/hv/hv.c |2 +-
1 file
Four kzalloc functions are called with GFP_ATOMIC.
But according to driver call graph, they are not in atomic context,
namely no spinlock is held nor in an interrupt handler.
All these "GFP_ATOMIC"s are unnecessary,
and replace with with "GFP_KERNEL"s.
Signed-off-by: Jia-
o disable
the interrupt;
perf_pmu_register() calls mutex_lock() and idr_alloc(GFP_KERNEL), and
they can sleep;
pmu_dev_alloc() calls kzalloc(GFP_KERNEL), and it can sleep.
In my opinion, this code may sleep with interrupts are disabled.
I wonder why this code is okay?
Best wishes,
Jia-Ju Bai
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
On 2018/4/11 23:04, Ulf Hansson wrote:
On 11 April 2018 at 04:46, Jia-Ju Bai wrote:
wbsd_init() is never called in atomic context.
The call chains ending up at wbsd_init() are:
[1] wbsd_init() <- wbsd_probe()
[2] wbsd_init() <- wbsd_pnp_probe()
wbsd_probe() is set as ".probe
sis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
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
1 file changed,
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
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/13 18:41, Mark Brown wrote:
On Mon, Apr 09, 2018 at 06:46:21PM +0800, Jia-Ju Bai wrote:
broxton_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".
Please submit patches using subject lines
.
Despite never getting called from atomic context, snd_ad1889_init()
calls mdelay for busy 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.
Signed-off-by: Jia-Ju Bai
---
sound/pci/ad
S written by myself.
Signed-off-by: Jia-Ju Bai
---
sound/pci/ad1889.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/ad1889.c b/sound/pci/ad1889.c
index 0bf2c04..a2a8e1d 100644
--- a/sound/pci/ad1889.c
+++ b/sound/pci/ad1889.c
@@ -258,7 +258,7 @
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
---
net/dccp/proto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
off-by: Jia-Ju Bai
---
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 @@ void __init dn_route_init(v
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
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
+++ b/net/ncsi/ncsi-manage.c
@@ -1508
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
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
--- a/net/tipc/monitor.c
+++ b/ne
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
---
fs/quota/dquot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
ity 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
---
fs/dlm/lowcomms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 4813d0e..2d4e
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
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
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
---
drivers/xen/xen-pciback/pci_stub.c | 2 +-
1 file changed, 1 inser
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
---
drivers/xen/xen-pcibac
ossibility of sucessful allocation.
Signed-off-by: Jia-Ju Bai
---
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
index 7476791..e3df3f9 10
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
c analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/video/fbdev/savage/savagefb_driver.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/savage/savagefb_driver.c
b/drivers/video/fbde
Jia-Ju Bai
---
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
--- a/net/decnet/dn_route.c
+++ b/
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
---
v2:
* Modify the description of GFP_ATOMIC in v1.
Thank Eric for good advice
also manually check it.
Signed-off-by: Jia-Ju Bai
---
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/ncsi-manage.c
index 3fd3c39..6b5b
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
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 --git a/net/tipc/monitor.c b/ne
s tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
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 --git a/net/tipc/monitor.c b/ne
Jia-Ju Bai
---
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
--- a/net/decnet/dn_route.c
+++ b/
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
---
drivers/usb/storage/freecom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/freecom.
context, aty128_set_suspend()
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
---
drivers/video/fbdev/aty/a
usily wait.
This is not necessary and can be replaced with msleep()
and 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
---
drivers/video/fbdev/aty/radeon_pm.c | 8
1 file changed, 4
501 - 600 of 1251 matches
Mail list logo
