[PATCH] crypto: rsa-pkcs1pad: Replace GFP_ATOMIC with GFP_KERNEL in pkcs1pad_encrypt_sign_complete

2018-01-25 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in __blk_queue_init_tags

2018-01-25 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in __blk_queue_init_tags

2018-01-25 Thread Jia-Ju Bai
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

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread 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

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread 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

[PATCH 1/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in __blk_queue_init_tags

2018-01-24 Thread Jia-Ju Bai
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

[PATCH 1/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in __blk_queue_init_tags

2018-01-24 Thread Jia-Ju Bai
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

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread Jia-Ju Bai
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

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread Jia-Ju Bai
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

[PATCH 2/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in init_tag_map

2018-01-24 Thread Jia-Ju Bai
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

[PATCH 2/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in init_tag_map

2018-01-24 Thread Jia-Ju Bai
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

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread Jia-Ju Bai
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

Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread Jia-Ju Bai
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

[PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread Jia-Ju Bai
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

[PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc

2018-01-24 Thread Jia-Ju Bai
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

[PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

2018-01-24 Thread 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

[PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

2018-01-24 Thread Jia-Ju Bai
. This is 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

Re: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

2018-01-24 Thread Jia-Ju Bai
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

Re: [PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

2018-01-24 Thread Jia-Ju Bai
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

[PATCH] kernel: x86: early-quirks: Replace mdelay with usleep_range in apple_airport_reset

2018-01-23 Thread Jia-Ju Bai
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

[PATCH] kernel: x86: early-quirks: Replace mdelay with usleep_range in apple_airport_reset

2018-01-23 Thread Jia-Ju Bai
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

[PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

2018-01-23 Thread Jia-Ju Bai
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

[PATCH] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

2018-01-23 Thread Jia-Ju Bai
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

[PATCH] kernel: x86: apic: Replace GFP_ATOMIC with GFP_KERNEL in __add_pin_to_irq_node

2018-01-23 Thread Jia-Ju Bai
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

[PATCH] kernel: x86: apic: Replace GFP_ATOMIC with GFP_KERNEL in __add_pin_to_irq_node

2018-01-23 Thread Jia-Ju Bai
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

[PATCH] sound: emu10k1: Replace GFP_ATOMIC with GFP_KERNEL in synth_alloc_pages

2018-01-23 Thread 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

[PATCH] sound: emu10k1: Replace GFP_ATOMIC with GFP_KERNEL in synth_alloc_pages

2018-01-23 Thread 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 --- sound/pci/emu10k1/memory.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/emu10k1/memory.c b

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Jia-Ju Bai
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!

Re: net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread 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

net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Jia-Ju Bai
ere? If not, how this data race is avoided? Thanks, Jia-Ju Bai

net: r8169: a question of memory barrier in the r8169 driver

2018-01-18 Thread Jia-Ju Bai
ere? If not, how this data race is avoided? Thanks, Jia-Ju Bai

Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-09 Thread 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

Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-09 Thread 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

Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-09 Thread 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

Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-09 Thread 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

Re: b43: Replace mdelay with msleep in b43_radio_2057_init_post

2018-01-08 Thread Jia-Ju Bai
On 2018/1/9 0:31, Larry Finger wrote: On 01/08/2018 10:21 AM, Kalle Valo wrote: Jia-Ju Bai <baijiaju1...@gmail.com> wrote: b43_radio_2057_init_post is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with msleep, to reduce bus

Re: b43: Replace mdelay with msleep in b43_radio_2057_init_post

2018-01-08 Thread Jia-Ju Bai
On 2018/1/9 0:31, Larry Finger wrote: On 01/08/2018 10:21 AM, Kalle Valo wrote: Jia-Ju Bai 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

[PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-08 Thread 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.

[PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-08 Thread 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

[PATCH] scsi: imm: Replace mdelay with msleep in imm_init

2017-12-30 Thread Jia-Ju Bai
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

[PATCH] scsi: imm: Replace mdelay with msleep in imm_init

2017-12-30 Thread Jia-Ju Bai
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

[PATCH] sky2: Replace mdelay with msleep in sky2_vpd_wait

2017-12-30 Thread Jia-Ju Bai
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

[PATCH] sky2: Replace mdelay with msleep in sky2_vpd_wait

2017-12-30 Thread Jia-Ju Bai
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

[PATCH] b43: Replace mdelay with msleep in b43_radio_2057_init_post

2017-12-30 Thread 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 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

[PATCH] b43: Replace mdelay with msleep in b43_radio_2057_init_post

2017-12-30 Thread 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 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

[PATCH] staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe

2017-12-30 Thread Jia-Ju Bai
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

[PATCH] staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe

2017-12-30 Thread Jia-Ju Bai
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

[PATCH] i40iw: Replace mdelay with msleep in i40iw_wait_pe_ready

2017-12-24 Thread Jia-Ju Bai
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

[PATCH] i40iw: Replace mdelay with msleep in i40iw_wait_pe_ready

2017-12-24 Thread Jia-Ju Bai
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

[PATCH] scsi: imm: Replace mdelay with msleep in imm_init

2017-12-24 Thread Jia-Ju Bai
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

[PATCH] scsi: imm: Replace mdelay with msleep in imm_init

2017-12-24 Thread Jia-Ju Bai
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

[PATCH] staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe

2017-12-24 Thread Jia-Ju Bai
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

[PATCH] staging: rtl8192u: Replace mdelay with msleep in rtl8192_usb_probe

2017-12-24 Thread Jia-Ju Bai
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

[PATCH] b43: Replace mdelay with msleep in b43_radio_2057_init_post

2017-12-23 Thread 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 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

[PATCH] b43: Replace mdelay with msleep in b43_radio_2057_init_post

2017-12-23 Thread 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 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

[PATCH] sky2: Replace mdelay with msleep in sky2_vpd_wait

2017-12-23 Thread Jia-Ju Bai
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

[PATCH] sky2: Replace mdelay with msleep in sky2_vpd_wait

2017-12-23 Thread Jia-Ju Bai
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

Re: [PATCH V2 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Jia-Ju Bai
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

Re: [PATCH V2 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Jia-Ju Bai
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

[PATCH V3 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Jia-Ju Bai
iew. Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- 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 inde

[PATCH V3 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Jia-Ju Bai
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

Re: [PATCH V2] hyper-v: use GFP_KERNEL for hv_context.hv_numa_map

2017-12-19 Thread Jia-Ju Bai
On 2017/12/19 1:05, Stephen Hemminger wrote: On Mon, 18 Dec 2017 17:02:52 +0800 Jia-Ju Bai <baijiaju1...@gmail.com> 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 h

Re: [PATCH V2] hyper-v: use GFP_KERNEL for hv_context.hv_numa_map

2017-12-19 Thread Jia-Ju Bai
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

[PATCH] staging: vt6655: Use GFP_KERNEL in kzalloc

2017-12-18 Thread Jia-Ju Bai
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: J

[PATCH] staging: vt6655: Use GFP_KERNEL in kzalloc

2017-12-18 Thread Jia-Ju Bai
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-

[PATCH V2] hyper-v: use GFP_KERNEL for hv_context.hv_numa_map

2017-12-18 Thread Jia-Ju Bai
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 <baijiaju1...@gmail.com> --- driv

[PATCH V2] hyper-v: use GFP_KERNEL for hv_context.hv_numa_map

2017-12-18 Thread Jia-Ju Bai
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

Re: [PATCH] hv: Fix unnecessary sleeping in hv_synic_alloc

2017-12-18 Thread Jia-Ju Bai
On 2017/12/18 16:54, Vitaly Kuznetsov wrote: Jia-Ju Bai <baijiaju1...@gmail.com> 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 unnec

Re: [PATCH] hv: Fix unnecessary sleeping in hv_synic_alloc

2017-12-18 Thread Jia-Ju Bai
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

[PATCH] hv: Fix unnecessary sleeping in hv_synic_alloc

2017-12-18 Thread Jia-Ju Bai
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 <baijiaju1...@gmail.com> --- driv

[PATCH] hv: Fix unnecessary sleeping in hv_synic_alloc

2017-12-18 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-16 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-16 Thread Jia-Ju Bai
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

[PATCH V2 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-16 Thread Jia-Ju Bai
iew. Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- 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

[PATCH V2 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-16 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub

2017-12-13 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub

2017-12-13 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub

2017-12-13 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub

2017-12-13 Thread Jia-Ju Bai
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

Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub

2017-12-13 Thread Jia-Ju Bai
Thanks for reply :) I think I should use "udelay(10/HZ)" instead, do you think it is right? Thanks, Jia-Ju Bai On 2017/12/14 5:20, David Miller wrote: I want you to review all of your patches and resend them after you have checked them carefully. The first patch I e

Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub

2017-12-13 Thread Jia-Ju Bai
Thanks for reply :) I think I should use "udelay(10/HZ)" instead, do you think it is right? Thanks, Jia-Ju Bai On 2017/12/14 5:20, David Miller wrote: I want you to review all of your patches and resend them after you have checked them carefully. The first patch I e

Re: [BUG] skge: a possible sleep-in-atomic bug in skge_remove

2017-12-13 Thread Jia-Ju Bai
On 2017/12/14 0:50, Stephen Hemminger wrote: On Wed, 13 Dec 2017 15:42:56 +0800 Jia-Ju Bai <baijiaju1...@gmail.com> wrote: On 2017/12/13 13:18, Stephen Hemminger wrote: On Tue, 12 Dec 2017 20:57:01 -0500 (EST) David Miller <da...@davemloft.net> wrote: From: Stephen Hem

Re: [BUG] skge: a possible sleep-in-atomic bug in skge_remove

2017-12-13 Thread Jia-Ju Bai
On 2017/12/14 0:50, Stephen Hemminger wrote: On Wed, 13 Dec 2017 15:42:56 +0800 Jia-Ju Bai wrote: On 2017/12/13 13:18, Stephen Hemminger wrote: On Tue, 12 Dec 2017 20:57:01 -0500 (EST) David Miller wrote: From: Stephen Hemminger Date: Tue, 12 Dec 2017 10:22:40 -0800 On Tue, 12

[PATCH] drm: Fix a possible sleep-in-atomic bug in show_leaks

2017-12-13 Thread Jia-Ju Bai
SAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- drivers/gpu/drm/drm_mm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 61a1c8e..5b9965d 100644 --- a/drivers/gpu/drm

[PATCH] drm: Fix a possible sleep-in-atomic bug in show_leaks

2017-12-13 Thread Jia-Ju Bai
SAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/gpu/drm/drm_mm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 61a1c8e..5b9965d 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/

[BUG] cx88: a possible sleep-in-atomic bug in snd_cx88_switch_put

2017-12-13 Thread Jia-Ju Bai
ode review. Thanks, Jia-Ju Bai

[BUG] cx88: a possible sleep-in-atomic bug in snd_cx88_switch_put

2017-12-13 Thread Jia-Ju Bai
ode review. Thanks, Jia-Ju Bai

[PATCH 2/2] rtc-r7301: Fix a possible sleep-in-atomic bug in rtc7301_set_time

2017-12-13 Thread Jia-Ju Bai
The driver may sleep under a spinlock. The function call path is: rtc7301_set_time (acquire the spinlock) usleep_range --> may sleep To fix it, usleep_range is replaced with udelay. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju

[PATCH 1/2] rtc-r7301: Fix a possible sleep-in-atomic bug in rtc7301_read_time

2017-12-13 Thread Jia-Ju Bai
iew. Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- drivers/rtc/rtc-r7301.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-r7301.c b/drivers/rtc/rtc-r7301.c index 28d5408..d846e97 100644 --- a/drivers/rtc/rtc-r7301.c +++ b/drivers/rtc/rt

[PATCH 1/2] rtc-r7301: Fix a possible sleep-in-atomic bug in rtc7301_read_time

2017-12-13 Thread Jia-Ju Bai
iew. Signed-off-by: Jia-Ju Bai --- drivers/rtc/rtc-r7301.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-r7301.c b/drivers/rtc/rtc-r7301.c index 28d5408..d846e97 100644 --- a/drivers/rtc/rtc-r7301.c +++ b/drivers/rtc/rtc-r7301.c @@ -95,7 +95,7 @@ static

[PATCH 2/2] rtc-r7301: Fix a possible sleep-in-atomic bug in rtc7301_set_time

2017-12-13 Thread Jia-Ju Bai
The driver may sleep under a spinlock. The function call path is: rtc7301_set_time (acquire the spinlock) usleep_range --> may sleep To fix it, usleep_range is replaced with udelay. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju

[PATCH] macb: Fix a possible sleep-in-atomic bug in macb_tx_error_task

2017-12-13 Thread Jia-Ju Bai
ned-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- drivers/net/ethernet/cadence/macb_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 72a67f7..b02c806 100644 --- a/drivers/net

[PATCH] macb: Fix a possible sleep-in-atomic bug in macb_tx_error_task

2017-12-13 Thread Jia-Ju Bai
ned-off-by: Jia-Ju Bai --- drivers/net/ethernet/cadence/macb_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 72a67f7..b02c806 100644 --- a/drivers/net/ethernet/cadence/macb_mai

[BUG] tulip/de4x5: a possible sleep-in-atomic bug in de4x5_interrupt

2017-12-13 Thread Jia-Ju Bai
tic analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] tulip/de4x5: a possible sleep-in-atomic bug in de4x5_interrupt

2017-12-13 Thread Jia-Ju Bai
tic analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] atlx: a possible sleep-in-atomic bug in atl1_intr

2017-12-13 Thread Jia-Ju Bai
ode review. Thanks, Jia-Ju Bai

[BUG] atlx: a possible sleep-in-atomic bug in atl1_intr

2017-12-13 Thread Jia-Ju Bai
ode review. Thanks, Jia-Ju Bai

[PATCH 1/2] qla3xxx: Fix a possible sleep-in-atomic bug in ql_sem_spinlock

2017-12-13 Thread Jia-Ju Bai
is bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- drivers/net/ethernet/qlogic/qla3xxx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/

[PATCH 1/2] qla3xxx: Fix a possible sleep-in-atomic bug in ql_sem_spinlock

2017-12-13 Thread Jia-Ju Bai
is bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/net/ethernet/qlogic/qla3xxx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c

[PATCH 2/2] qla3xxx: Fix a possible sleep-in-atomic bug in ql_wait_for_drvr_lock

2017-12-13 Thread Jia-Ju Bai
off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- drivers/net/ethernet/qlogic/qla3xxx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c index 8ad3e24..7994d04 100644 --- a/drivers/net/ethernet/qlogic/

<    4   5   6   7   8   9   10   11   12   13   >