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
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
timeout"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 25d5d2b8cfb
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
quot;hotplug->enabled" is
also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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
;
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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.
On 2018/5/9 4:17, Rafael J. Wysocki wrote:
On Tue, May 8, 2018 at 5:08 AM, Jia-Ju Bai <baijiaju1...@gmail.com> 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 lo
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 <baijiaju1...@gmail.com>
---
drivers/usb/storage/uas.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/st
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
t;flags"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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
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
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 <baijiaju1...@gmail.com>
---
drivers/watchdog/mena21_wdt.c | 18 --
;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
;alloc->buffer"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 5a426c877d
in pci_specified_resource_alignment
In fact, I suspect that my report is false, because I always have an
impression that printk() cannot sleep.
But according to the call path, I cannot find where I make the mistake...
So could someone please help me to point the mistake?
Best wishes,
Jia-Ju Bai
On 2018/5/31 22:08, Matthew Wilcox wrote:
On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
Here is the call path for kfree().
Please look at it *from the bottom up*.
[FUNC] alloc_pages(GFP_KERNEL)
arch
On 2018/5/31 22:09, Christopher Lameter wrote:
On Thu, 31 May 2018, Jia-Ju Bai wrote:
I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
That should not happen.
Here is the call path for kfree().
Please look at it *from the bottom up*.
[FUNC] alloc_pages
tool does not follow the data flow well, and I need to
improve it.
In this case of kfree(), I want know how the data flow leads to my mistake.
Best wishes,
Jia-Ju Bai
d still return 0 in case the flag is set.
If it's only used in three locations, I think it would be better to
simply remove it from vsprintf() and have the three callers call
clk_get_rate() directly.
Agreed.
Best wishes,
Jia-Ju Bai
.
Signed-off-by: Jia-Ju Bai
---
drivers/staging/rtlwifi/halmac/rtl_halmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
index 66f0a6dfc52c..e921a62e72a3 100644
--- a/drivers/staging
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
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
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
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
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,
/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
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
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 <baijiaju1...@gmail.com>
---
drivers/staging/rtl8192u/r8192U_core.c |2 +-
1 file changed, 1 insertion
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 <baijiaju1...@gmail.com>
---
drivers/scsi/imm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
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
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
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 <baijiaju1...@gmail.com>
---
drivers/infiniband/hw/i40iw/i40iw_main.c |2 +-
1 file changed, 1 ins
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 <baijiaju1...@gmail.com>
---
drivers/scsi/imm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
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 <baijiaju1...@gmail.com>
---
drivers/staging/rtl8192u/r8192U_core.c |2 +-
1 file changed, 1 insertion
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
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
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.
ere?
If not, how this data race is avoided?
Thanks,
Jia-Ju Bai
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 <baijiaju1...@gmail.com>
---
sound/pci/emu10k1/memory.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 0
tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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/blo
analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 f
that 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 <baijiaju1...@gmail.com>
---
drivers/block/DAC960.c |2 +-
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
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 <baijiaju1...@gmail.
() 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 <baijia
->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
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...
, 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
->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
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
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
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
that 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 <baijiaju1...@gmail.com>
---
drivers/block/drbd/drbd_worker.c |2 +-
.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 6
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 <baijiaju1...@gmail.com>
---
drivers/block/mt
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 <baijiaju1...@gmail.com>
---
drivers/block/paride/on26.c |2
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
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 <baijiaju1...@gmail.com>
---
drivers/block/mtip32xx/mtip32xx.c |2 +-
1 file changed, 1 insertion
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 <baijiaju1...@gmail.com>
---
drivers/block/mtip32xx/mtip32xx.c |2 +-
1 file changed, 1 insertion
that btmrvl_send_sync_cmd()
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 <baijiaju1...@gmail.com>
---
drivers/bluetooth/btmrvl_main.c |2
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/27 0:26, Larry Finger wrote:
On 01/26/2018 03:13 AM, Jia-Ju Bai wrote:
After checking all possible call chains to bcma_pmu_resources_init()
here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock.
Thus
analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
v2:
* Use usleep_range(2000, 2500), instead of (1500, 2000) in v1.
---
drivers/bcma/driver_chipcommon_pmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
written by myself.
And I also manually audit the result.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 5de3ed2..598eb05
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
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
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 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
.
This is found by a static analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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 8
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 <baijiaju1...@gmail.com>
---
block/blk-mq-sched.c
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
that 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 <baijiaju1...@gmail.com>
---
drivers/ata/pata_it821x.c |2 +-
1 file c
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>
---
crypto/crypto_user.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/crypto_user.c b/
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>
---
drivers/acpi/osl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
analysis tool named DCNS written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
---
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
-Ju Bai <baijiaju1...@gmail.com>
---
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_pdc2
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>
---
v2:
* Revise the description.
Thanks Al for helpful advice.
---
drivers/block/paride/on26.c |2 +-
1 file changed, 1 insertion(+),
On 2018/1/27 1:31, Al Viro wrote:
On Fri, Jan 26, 2018 at 11:42:25PM +0800, Jia-Ju Bai wrote:
After checking all possible call chains to on26_test_port() here,
my tool finds that this function is never called in atomic context,
namely never in an interrupt handler or holding a spinlock
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
never getting called from atomic context, download_firmware()
calls mdelay() for busy wait.
That is not necessary and 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 <baijiaju1...@gmail.com>
mdelay() for busy wait.
That is not necessary and 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 <baijiaju1...@gmail.com>
---
drivers/bluetooth/hci_ath.c |4 ++--
1 file changed, 2 insertions
On 2018/1/28 1:48, Ed Cashin wrote:
If the tool cannot tell whether the protected state is manipulated by *another*
piece of code called in atomic context, then it's insufficient.
On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai <baijiaju1...@gmail.com> wrote:
After checking all possibl
On 2018/2/8 18:20, Rafael J. Wysocki wrote:
On Thursday, February 8, 2018 11:13:10 AM CET Chris Wilson wrote:
Quoting Rafael J. Wysocki (2018-02-08 09:51:41)
On Thursday, January 25, 2018 11:13:41 AM CET Jia-Ju Bai wrote:
After checking all possible call chains to acpi_os_execute here,
my
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
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
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
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
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
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
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
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
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
201 - 300 of 1251 matches
Mail list logo
