[PATCH] fs: kernfs: Fix possible null-pointer dereferences in kernfs_path_from_node_locked()

trlcpy(buf + len, kn->name, ...) Thus, possible null-pointer dereferences may occur. To fix these possible bugs, buf is checked before being used. If it is NULL, -EINVAL is returned. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/ker

[PATCH] fs: jffs2: Fix possible null-pointer dereferences in jffs2_add_frag_to_fragtree()

ofs) Thus possible null-pointer dereferences may occur. To fix these bugs, -EINVAL is returned when "this" is NULL. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/jffs2/nodelist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) d

[PATCH] ata: libata-core: Fix possible null-pointer dereferences in ata_host_alloc_pinfo()

i[j] is NULL, the loop continues, and "j++" is moved to the loop's regulator. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- drivers/ata/libata-core.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drive

[PATCH] fs: nfsd: Fix three possible null-pointer dereferences

fix these possible bugs, -EINVAL is returned when cb is NULL. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/nfsd/nfs4callback.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/fs/nfsd/nfs4callback.c b/fs/n

[PATCH] char: ppdev: Fix a possible null-pointer dereference in pp_release()

port_release(pp->pdev); Thus, a possible null-pointer dereference may occur. To fix this bug, pp->pdev is checked on line 740. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- drivers/char/ppdev.c | 2 +- 1 file changed, 1 insertion(+), 1 d

[PATCH] net: key: af_key: Fix possible null-pointer dereferences in pfkey_send_policy_notify()

us, possible null-pointer dereferences may occur. To fix these bugs, xp is checked before calling key_notify_policy(). These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/key/af_key.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/key/a

[PATCH] net: ceph: Fix a possible null-pointer dereference in ceph_crypto_key_destroy()

may occur. To fix this bug, key->tfm is checked before calling crypto_free_sync_skcipher(). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/ceph/crypto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ceph/crypto.

[PATCH] fs: crypto: keyinfo: Fix a possible null-pointer dereference in derive_key_aes()

ing crypto_free_skcipher(). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/crypto/keyinfo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c index 207ebed918c1..b419720cac54 100644 --- a/fs/cry

[PATCH] net: 9p: Fix possible null-pointer dereferences in p9_cm_event_handler()

sis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/9p/trans_rdma.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c index bac8dad5dd69..eba3c5fc2731 100644 --- a/net/9p/trans_rdma.c +++ b/net

[PATCH] ALSA: core: Fix possible null-pointer dereferences in snd_timer_proc_read()

references may occur. To fix these bugs, timer->card is checked before being used. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- sound/core/timer.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/core/ti

[PATCH 1/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_setup_sdata()

_ops; Thus, possible null-pointer dereferences may occur. To fix these bugs, sdata->dev is checked before being used. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/mac80211/iface.c | 6 -- 1 file changed, 4 insertions(+), 2 deleti

[PATCH 2/2] net: mac80211: Fix possible null-pointer dereferences in ieee80211_xmit_fast_finish()

| (key->conf.keyidx << 6); Thus, possible null-pointer dereferences may occur. To fix these bugs, key is checked on line 3384. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/mac80211/tx.c | 2 +- 1 file changed, 1 insertion(+), 1 de

Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

MODULE_READY; - av7110->ci_slot[data[0]].flags = flags; + av7110->ci_slot[data_0].flags = flags; This does not even do what it says. Compiler is still free to access data[0] multiple times. It needs READ_ONCE() to be effective. Thanks for this advice, I will submit a v2 patch soon. Best wishes, Jia-Ju Bai

Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

he compiler optimization may drop the copying operation, and thus READ_ONCE() should be used here. I will submit a v2 patch soon. Best wishes, Jia-Ju Bai

[PATCH] media: pci: ttpci: av7110: avoid compiler optimization of reading data[0] in debiirq()

Signed-off-by: Jia-Ju Bai --- drivers/media/pci/ttpci/av7110.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c index bf36b1e22b63..f7d098d5b198 100644 --- a/drivers/media/pci/ttpci/av7110.c +++ b/drivers/media

Re: [PATCH AUTOSEL 4.19 08/38] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

On 2020/8/31 6:25, Laurent Pinchart wrote: Hi Jia-Ju, On Sun, Aug 30, 2020 at 03:33:11PM +0800, Jia-Ju Bai wrote: On 2020/8/30 1:16, Laurent Pinchart wrote: On Sat, Aug 29, 2020 at 02:10:20PM +0200, Pavel Machek wrote: Hi! The value av7110->debi_virt is stored in DMA mem

[PATCH] media: venus: fix possible buffer overlow casued bad DMA value in venus_sfr_print()

->buf_size is assigned to a local variable, and then this variable is checked before being used. Signed-off-by: Jia-Ju Bai --- drivers/media/platform/qcom/venus/hfi_venus.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/venus/hfi

[PATCH] net: vmxnet3: fix possible buffer overflow caused by bad DMA value in vmxnet3_get_rss()

; is executed. To fix this possible bug, n is checked after being used. Signed-off-by: Jia-Ju Bai --- drivers/net/vmxnet3/vmxnet3_ethtool.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c index 6528940ce5f3..b53bb8bcd47

[PATCH] usb: cdns3: fix possible buffer overflow caused by bad DMA value

To fix these possible bugs, index is checked before being used. Signed-off-by: Jia-Ju Bai --- drivers/usb/cdns3/ep0.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c index e71240b386b4..0a80c7ade613 100644 --- a/drivers/usb/cdns3/ep0.c +++ b

[PATCH] input: tablet: aiptek: fix possible buffer overflow caused by bad DMA value in aiptek_irq()

uot;macroKeyEvents[macro]" is executed. To fix these possible bugs, macro is checked before being used. Signed-off-by: Jia-Ju Bai --- drivers/input/tablet/aiptek.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/input/tablet/aiptek.c b/drivers/input/tablet/aipt

[PATCH] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

ow when the code "av7110->ci_slot[data[0]]" is used. To fix this possible bug, data[0] is assigned to a local variable, which replaces the use of data[0]. Signed-off-by: Jia-Ju Bai --- drivers/media/pci/ttpci/av7110.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --

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

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

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

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] kernel: x86: tboot: Replace mdelay with usleep_range in tboot_wait_for_aps

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: early-quirks: Replace mdelay with usleep_range in apple_airport_reset

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

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

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] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

. 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

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

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

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

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 2/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in init_tag_map

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

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 1/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in __blk_queue_init_tags

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

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 1/2] block: blk-tag: Replace GFP_ATOMIC with GFP_KERNEL in __blk_queue_init_tags

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

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

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

[PATCH] crypto: crypto_user: Replace GFP_ATOMIC with GFP_KERNEL in crypto_report

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 --- 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

[PATCH] acpi: osl: Replace GFP_ATOMIC with GFP_KERNEL in acpi_os_execute

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

[PATCH] ata: sata_mv: Replace mdelay with usleep_range in mv_reset_channel

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

[PATCH] ata: pata_it821x: Replace mdelay with usleep_range in it821x_firmware_command

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 --- drivers/ata/pata_it821x.c |2 +- 1 file changed, 1 insertion(+), 1

[PATCH] ata: pata_pdc2027x: Replace mdelay with msleep

-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

Re: [PATCH] acpi: osl: Replace GFP_ATOMIC with GFP_KERNEL in acpi_os_execute

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

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

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

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

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

[PATCH 1/2] atm: fore200e: Replace GFP_ATOMIC with GFP_KERNEL in fore200e_open

, 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/fore200e.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 6ebc4e4

[PATCH 2/2] atm: fore200e: Replace GFP_ATOMIC with GFP_KERNEL in fore200e_send

->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

[PATCH] atm: idt77252: Replace mdelay with usleep_range in idt77252_preset

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 --- drivers/atm/idt77252.c |2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH] atm: solos-pci: Replace GFP_ATOMIC with GFP_KERNEL in psend

(), 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

[PATCH] atm: atmtcp: Replace GFP_ATOMIC with GFP_KERNEL in atmtcp_v_send

->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 Bai

[PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

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/

[PATCH] atm: he: Replace GFP_ATOMIC with GFP_KERNEL in he_open

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

[PATCH] base: power: domain: Replace mdelay with msleep

. This is 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

[PATCH] opp: cpu: Replace GFP_ATOMIC with GFP_KERNEL in dev_pm_opp_init_cpufreq_table

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

[PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

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

[PATCH] block: aoenet: Replace GFP_ATOMIC with GFP_KERNEL in aoenet_rcv

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

[PATCH] block: DAC960: Replace GFP_ATOMIC with GFP_KERNEL in DAC960_DetectController

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 --- drivers/block/DAC960.c |2 +- 1 file changed, 1 insertion

[PATCH 2/2] block: DAC960: Replace GFP_ATOMIC with GFP_KERNEL in DAC960_CreateAuxiliaryStructures

() 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

Re: [PATCH] base: power: domain: Replace mdelay with msleep

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

Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

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

Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

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

[PATCH] block: drbd: Replace GFP_ATOMIC with GFP_KERNEL in drbd_resync_finished

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 --- drivers/block/drbd/drbd_worker.c |2 +- 1 file changed, 1 insertion(+), 1

[PATCH] auxdisplay: charlcd: delete mdelay in long_sleep

. This is 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

[PATCH 1/3] block: mtip32xx: Replace mdelay with msleep in mtip_hw_init

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

[PATCH 2/3] block: mtip32xx: Replace mdelay with msleep in mtip_service_thread

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

[PATCH 3/3] block: mtip32xx: Replace mdelay with msleep in mtip_handle_tfe

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

[PATCH] block: paride: on26: Replace mdelay with msleep in on26_test_port

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

[PATCH] bluetooth: btmrvl_main: Replace GFP_ATOMIC with GFP_KERNEL in btmrvl_send_sync_cmd

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 --- drivers/bluetooth/btmrvl_main.c |2 +- 1 file changed, 1 insertion

Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

On 2018/1/27 0:07, David Miller wrote: From: Al Viro 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 atomic context

Re: [PATCH] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

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

[PATCH v2] bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- 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/drivers/bcma/driver_chipcommon_pmu.c b

[PATCH] firmware: memmap: Replace GFP_ATOMIC with GFP_KERNEL in firmware_map_add_hotplug

written by myself. And I also manually audit the result. 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 5de3ed2..598eb05 100644 --- a/drivers/firmware/memmap.c

Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

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

Re: [PATCH] block: paride: on26: Replace mdelay with msleep in on26_test_port

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

[PATCH v2] block: paride: on26: Replace mdelay with msleep in on26_test_port

to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai --- v2: * Revise the description. Thanks Al for helpful advice. --- drivers/block/paride/on26.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bl

[PATCH] bluetooth: hci_ll: Replace mdelay with msleep in download_firmware

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 --- drivers/bluetooth/hci_ll.c

[PATCH] bluetooth: hci_ath: Replace mdelay with msleep in ath_wakeup_ar3k

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 --- drivers/bluetooth/hci_ath.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] block: aoenet: Replace GFP_ATOMIC with GFP_KERNEL in aoenet_rcv

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 wrote: After checking all possible call chains to aoenet_rcv(), my

[PATCH] ALSA: i2c: ak4xxx-adda: Fix a possible null pointer dereference in build_adc_controls()

tor_name; Thus, a possible null-pointer dereference may occur. To fix this bug, referring to lines 773 and 774, ak->adc_info and ak->adc_info[mixer_ch].selector_name are checked before being used. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai

[PATCH] fs: overlayfs: Fix a possible null-pointer dereference in ovl_free_fs()

on line 224: ovl_inuse_unlock(ofs->upper_mnt->mnt_root); Thus, a possible null-pointer dereference may occur. To fix this bug, ofs->upper_mnt is checked before being used in ovl_free_fs(). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/

[PATCH] net: tipc: Fix a possible null-pointer dereference in tipc_publ_purge()

analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/tipc/name_distr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c index 44abc8e9c990..241ed2274473 100644 --- a/net/tipc/name_distr.c +++ b/net/tipc/name_distr.c

[PATCH] net: bluetooth: hci_sock: Fix a possible null-pointer dereference in hci_mgmt_cmd()

nce(), add_device() and remove_device() in mgmt.c. Thus, a possible null-pointer dereference may occur. To fix this bug, hdev is checked before calling handler->func(). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/bluetooth/hci_sock.c

[PATCH] infiniband: hw: cxgb3: Fix a possible null-pointer dereference in connect_reply_upcall()

o fix this bug, ep->com.cm_id is checked before being used. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- drivers/infiniband/hw/cxgb3/iwch_cm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/cxgb3

Re: [PATCH] ALSA: i2c: ak4xxx-adda: Fix a possible null pointer dereference in build_adc_controls()

On 2019/7/25 23:52, Takashi Iwai wrote: On Thu, 25 Jul 2019 10:27:33 +0200, Jia-Ju Bai wrote: In build_adc_controls(), there is an if statement on line 773 to check whether ak->adc_info is NULL: if (! ak->adc_info || ! ak->adc_info[mixer_ch].switch_name)

[PATCH v2] ALSA: i2c: ak4xxx-adda: Fix a possible null pointer dereference in build_adc_controls()

hus, a possible null-pointer dereference may occur. To fix this bug, referring to lines 773 and 774, ak->adc_info and ak->adc_info[mixer_ch].selector_name are checked before being used. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- v2: * Fi

[PATCH 1/2] net: ipv4: Fix a possible null-pointer dereference in inet_csk_rebuild_route()

off-by: Jia-Ju Bai --- net/ipv4/inet_connection_sock.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c index f5c163d4771b..27d9d80f3401 100644 --- a/net/ipv4/inet_connection_sock.c +++ b/net/i

[PATCH 2/2] net: ipv4: Fix a possible null-pointer dereference in fib4_rule_suppress()

clntref)) Thus, a possible null-pointer dereference may occur. To fix this bug, result->fi is checked before calling fib_info_put(). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/ipv4/fib_rules.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/3] fs: ocfs2: Fix a possible null-pointer dereference in ocfs2_info_scan_inode_alloc()

ocfs2_super *osb = OCFS2_SB(inode->i_sb); Thus, a possible null-pointer dereference may occur. To fix this bug, inode_alloc is checked on line 286. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/ocfs2/ioctl.c | 2 +- 1 file changed

[PATCH 1/3] fs: ocfs2: Fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()

ll-pointer dereferences may occur. To fix these bugs, if loc-xl_entry is NULL, ocfs2_xa_prepare_entry() abnormally returns with -EINVAL. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/ocfs2/xattr.c | 6 -- 1 file changed, 4 insertions

[PATCH 2/3] fs: ocfs2: Fix a possible null-pointer dereference in ocfs2_write_end_nolock()

>t_tid; Thus, a possible null-pointer dereference may occur. To fix this bug, handle is checked before calling ocfs2_update_inode_fsync_trans(). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/ocfs2/aops.c | 3 ++- 1 file changed, 2 inserti

[PATCH] fs: nfs: Fix possible null-pointer dereferences in encode_attrs()

*p++ = cpu_to_be32(label->len); p = xdr_encode_opaque_fixed(p, label->label, label->len); To fix these bugs, label is checked before being used. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/nfs/nfs4xdr.c | 2 +- 1 file

[PATCH 2/2] net: ipv6: Fix a possible null-pointer dereference in vti6_link_config()

rt is not NULL. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/ipv6/ip6_vti.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c index 024db17386d2..572647205c52 100644 --- a/net/i

[PATCH 1/2] net: ipv6: Fix a possible null-pointer dereference in ip6_xmit()

ore calling ip6_autoflowlabel(net,np). This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- net/ipv6/ip6_output.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 8e49fd62e

[PATCH] isdn: mISDN: hfcsusb: Fix possible null-pointer dereferences in start_isoc_chain()

ur. To fix these bugs, "continue" is added to avoid using fifo->iso[i].urb when it is NULL. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- drivers/isdn/hardware/mISDN/hfcsusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers

[PATCH] fs: reiserfs: Fix possible null-pointer dereferences in remove_from_transaction()

(bh); put_bh(bh); Thus, possible null-pointer dereferences may occur. To fix these bugs, bh is checked before being used. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/reiserfs/journal.c | 7 --- 1 file changed, 4 insertions

[PATCH] input: touchscreen: wm97xx-core: Fix possible null-pointer dereferences in wm97xx_ts_input_open()

analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- drivers/input/touchscreen/wm97xx-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c index 0a174bd82915..f7bd0726a577 1006

Re: [PATCH] input: touchscreen: wm97xx-core: Fix possible null-pointer dereferences in wm97xx_ts_input_open()

On 2019/7/26 17:06, Charles Keepax wrote: On Fri, Jul 26, 2019 at 04:48:16PM +0800, Jia-Ju Bai wrote: In wm97xx_ts_input_open(), there is an if statement on line 507 to check whether wm->mach_ops is NULL: if (wm->mach_ops && wm->mach_ops->acc_enabled) When

[PATCH v2] input: touchscreen: wm97xx-core: Fix possible null-pointer dereferences in wm97xx_ts_input_open()

tic analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- v2: * Add a new check of wm->mach_ops in wm97xx_init_pen_irq(). Thank Charles for helpful advice. --- drivers/input/touchscreen/wm97xx-core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/input/touchscree

Re: [PATCH 1/3] fs: ocfs2: Fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()

On 2019/7/26 17:37, Joseph Qi wrote: On 19/7/26 11:36, Jia-Ju Bai wrote: In ocfs2_xa_prepare_entry(), there is an if statement on line 2136 to check whether loc->xl_entry is NULL: if (loc->xl_entry) When loc->xl_entry is NULL, it is used on line 2158: ocfs2_xa_add_

[PATCH 1/3 v2] fs: ocfs2: Fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()

ll-pointer dereferences may occur. To fix these bugs, if loc-xl_entry is NULL, ocfs2_xa_prepare_entry() abnormally returns with -EINVAL. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- v2: * Directly return -EINVAL if loc-xl_entry is NULL. Thank

[PATCH v3] input: touchscreen: wm97xx-core: Fix possible null-pointer dereferences in wm97xx_ts_input_open()

tic analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- v2: * Add a new check of wm->mach_ops in wm97xx_init_pen_irq(). Thank Charles for helpful advice. v3: * Print a message if wm->mach_ops is NULL in wm97xx_init_pen_irq(). Thank Charles for helpful advice. --- dri

[PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()

dropping connection " "%pI6c->%pI6c\n", >c_laddr, >c_faddr); rds_conn_drop(conn); Thus, possible null-pointer dereferences may occur. To fix these bugs, conn is checked before being used. These bugs are found by a static analysis tool STCheck writt

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