Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

2017-06-01 Thread Jia-Ju Bai
On 06/02/2017 12:11 AM, Jonathan Corbet wrote: On Thu, 01 Jun 2017 09:05:07 +0800 Jia-Ju Bai wrote: I admit my patches are not well tested, and they may not well fix the bugs. I am looking forward to opinions and suggestions :) May I politely suggest that sending out untested locking changes

[BUG] fs/f2fs: a possible sleep-in-atomic bug in f2fs_trace_pid

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

[BUG] sound/soc/samsung: a possible sleep-in-atomic bugs in s3c_pcm_hw_params

2017-12-11 Thread Jia-Ju Bai
nly report. This possible bug is found by my static analysis tool (DSAC) and my code review. Thanks, Jia-Ju Bai

[BUG] drivers/tty/hvc: a possible sleep-in-atomic bug in xen_pv_console_init

2017-12-11 Thread Jia-Ju Bai
bug is found by my static analysis tool (DSAC) and my code review. Thanks, Jia-Ju Bai

[BUG] drivers/scsi/advansys: three possible sleep-in-atomic bugs in advansys_interrupt

2017-12-11 Thread Jia-Ju Bai
Thanks, Jia-Ju Bai

[BUG] drivers/scsi/dpt_i2o: a possible sleep-in-atomic bug in adpt_isr

2017-12-11 Thread Jia-Ju Bai
with "mdelay". If this fixing is correct, I can send a patch. This possible is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] drivers/scsi/dpt_i2o: a possible sleep-in-atomic bug in adpt_i2o_post_this

2017-12-11 Thread Jia-Ju Bai
quot; with "mdelay". If this fixing is correct, I can send a patch. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] drivers/scsi/dpt_i2o: a possible sleep-in-atomic bug in adpt_i2o_status_get

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

[PATCH] NCR5380: Fix a possible sleep-in-atomic bug in NCR5380_poll_politely2

2017-12-11 Thread Jia-Ju Bai
From: Jia-Ju Bai The kernel module may sleep under a spinlock. The function call paths are: NCR5380_select (acquire the spinlock) NCR5380_reselect NCR5380_poll_politely NCR5380_poll_politely2 schedule_timeout_uninterruptible --> may sleep NCR5380_abort (acquire the spinl

[BUG] drivers/scsi/ipr: two possible sleep-in-atomic bugs

2017-12-11 Thread Jia-Ju Bai
cmd wait_for_completion --> may sleep (>_lock is still held) I do not find a good way to fix them, so I only report. These possible bugs are found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] drivers/scsi/wd719x: a possible sleep-in-atomic bug in wd719x_host_reset

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

[BUG] drivers/usb/host/isp116x-hcd: a possible sleep-in-atomic bug in isp116x_start

2017-12-11 Thread Jia-Ju Bai
may sleep I do not find a good way to fix it, so I only report. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] 3com/3c59x: two possible sleep-in-atomic bugs

2017-12-11 Thread Jia-Ju Bai
errupt (interrupt handler) vortex_error vortex_up pci_set_power_state --> may sleep pci_enable_device --> may sleep I do not find a good way to fix them, so I only report. These possible bugs are found by my static analysis tool (DSAC) and checked by my code review. Th

Re: [PATCH] NCR5380: Fix a possible sleep-in-atomic bug in NCR5380_poll_politely2

2017-12-11 Thread Jia-Ju Bai
Thanks for your reply :) On 2017/12/12 11:38, Finn Thain wrote: On Tue, 12 Dec 2017, Jia-Ju Bai wrote: From: Jia-Ju Bai The kernel module may sleep under a spinlock. The spinlock is always taken in irq mode, and the schedule_timeout_uninterruptible() is conditional on !irqs_disabled(). I

[BUG] drivers/gpio: some possible sleep-in-atomic bugs

2017-12-11 Thread Jia-Ju Bai
-> may sleep grgpio_irq_map (acquire the spinlock) request_irq --> may sleep grgpio_irq_unmap (acquire the spinlock) free_irq --> may sleep I do not find a good way to fix them, so I only report. These possible bugs is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] drivers/spi: a possible sleep-in-atomic bug in atmel_spi_remove

2017-12-11 Thread Jia-Ju Bai
ort. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[PATCH] esas2r: Fix possible sleep-in-atomic bugs in esas2r_check_adapter

2017-12-12 Thread Jia-Ju Bai
is replaced with mdelay. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/scsi/esas2r/esas2r_init.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/esas2r/esas2r_init.c b/drivers

[BUG] drivers/scsi/esas2r: a possible sleep-in-atomic bug in esas2r_nvram_read_direct

2017-12-12 Thread Jia-Ju Bai
do not find a good way to fix it, so I only report. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[PATCH] esas2r: Fix a possible sleep-in-atomic bug in esas2r_flash_access

2017-12-12 Thread Jia-Ju Bai
esas2r_flash_access schedule_timeout_interruptible --> may sleep To fix it, schedule_timeout_uninterruptible is replaced with mdelay. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/scsi/esas2r/esas2r_flas

[PATCH] esas2r: Fix a possible sleep-in-atomic bug in esas2r_wait_request

2017-12-12 Thread Jia-Ju Bai
schedule_timeout_interruptible --> may sleep To fix it, schedule_timeout_uninterruptible is replaced with mdelay. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/scsi/esas2r/esas2r_main.c |2 +- 1 file changed, 1 insertion(+)

[BUG] drivers/input/misc/pcap: a possible sleep-in-atomic bug in pcap_keys_handler

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

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

2017-12-12 Thread Jia-Ju Bai
SAC) and checked by my code review. Thanks, Jia-Ju Bai

[PATCH] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close

2017-12-12 Thread Jia-Ju Bai
off-by: Jia-Ju Bai --- drivers/net/hippi/rrunner.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c index 8483f03..1ab97d9 100644 --- a/drivers/net/hippi/rrunner.c +++ b/drivers/net/hippi/rrunner.c @@ -1379,8 +1379,8 @@ sta

[BUG] sbni: a possible sleep-in-atomic bug in sbni_close

2017-12-12 Thread Jia-Ju Bai
my code review. Thanks, Jia-Ju Bai

[BUG] wl3501: a possible sleep-in-atomic bug in wl3501_reset

2017-12-12 Thread Jia-Ju Bai
SAC) and checked by my code review. Thanks, Jia-Ju Bai

[PATCH] mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl

2017-12-12 Thread Jia-Ju Bai
off-by: Jia-Ju Bai --- drivers/net/wireless/mac80211_hwsim.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c index 10b075a..f2ebf4a 100644 --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/

[BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown

2017-12-12 Thread Jia-Ju Bai
SAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] mm/vmalloc: ___might_sleep is called under a spinlock in __purge_vmap_area_lazy

2017-10-08 Thread Jia-Ju Bai
___might_sleep in cond_resched_lock. This bug is found by my static analysis tool and my code review. Thanks, Jia-Ju Bai

Re: [BUG] mm/vmalloc: ___might_sleep is called under a spinlock in __purge_vmap_area_lazy

2017-10-08 Thread Jia-Ju Bai
Thanks for your reply and explanation :) I will improve my analysis. Thanks, Jia-Ju Bai On 2017/10/9 12:10, Kirill A. Shutemov wrote: On Mon, Oct 09, 2017 at 12:00:33PM +0800, Jia-Ju Bai wrote: The ___might_sleep is called under a spinlock, and the function call graph

Re: [alsa-devel] [PATCH] opl3: Fix a possible sleep-in-atomic bug in snd_opl3_find_patch

2017-10-09 Thread Jia-Ju Bai
Thanks for your reply :) Yes, you are right. Sorry for this false positive. Thanks, Jia-Ju Bai On 2017/10/9 14:32, Clemens Ladisch wrote: Jia-Ju Bai wrote: The driver may sleep under a spinlock, and the function call path is: snd_opl3_note_on (acquire the spinlock) snd_opl3_find_patch

Re: [BUG] vt6655: A possible sleep-in-atomic bug in vt6655_suspend

2017-10-09 Thread Jia-Ju Bai
Okay, I will send a patch :) Thanks, Jia-Ju Bai On 2017/10/9 13:43, Greg KH wrote: On Mon, Oct 09, 2017 at 09:10:28AM +0800, Jia-Ju Bai wrote: According to device_main.c, the driver may sleep under a spinlock, and the function call path is: vt6655_suspend (acquire the spinlock

[PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

2017-10-09 Thread Jia-Ju Bai
hese bugs are found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai --- drivers/pci/pci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 6078dfc..7b763a3 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

2017-10-09 Thread Jia-Ju Bai
Oh, sorry, I will send the patches for each driver. Thanks, Jia-Ju Bai On 2017/10/9 16:17, Greg KH wrote: On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, which may sleep. The function call paths

[PATCH] vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend

2017-10-09 Thread Jia-Ju Bai
und by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai --- drivers/staging/vt6655/device_main.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c index 9fcf2e2..1123b4f 100

[PATCH] gma500: Fix possible sleep-in-atomic bugs in gma_power_begin

2017-10-09 Thread Jia-Ju Bai
x them, the spinlock is released before gma_resume_pci, and it is acquired again after gma_resume_pci. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai --- drivers/gpu/drm/gma500/power.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/

[BUG] vme_ca91cx42: a possible sleep-in-atomic bug in ca91cx42_master_set

2017-12-12 Thread Jia-Ju Bai
bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[PATCH] vme: Fix a possible sleep-in-atomic bug in vme_tsi148

2017-12-12 Thread Jia-Ju Bai
ool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/vme/vme.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vme/vme.c b/drivers/vme/vme.c index 8124622..92500f6 100644 --- a/drivers/vme/vme.c +++ b/drivers/vme/vme.c @@ -1290,7 +129

[PATCH] rtl8188eu: Fix a possible sleep-in-atomic bug in set_tx_beacon_cmd

2017-12-12 Thread Jia-Ju Bai
by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/staging/rtl8188eu/core/rtw_mlme_ext.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c b/drivers/staging/rtl8188e

[PATCH] tty/isicom: Fix a possible sleep-in-atomic bug in WaitTillCardIsFree

2017-12-12 Thread Jia-Ju Bai
my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/tty/isicom.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/tty/isicom.c b/drivers/tty/isicom.c index 015686f..bdd3027 100644 --- a/drivers/tty/isicom.c +++ b/d

[PATCH] arcmsr: Fix possible sleep-in-atomic bugs in arcmsr_queue_command

2017-12-12 Thread Jia-Ju Bai
From: Jia-Ju Bai The driver may sleep under a spinlock, and the function call paths are: arcmsr_queue_command(acquire the spinlock) arcmsr_queue_command_lck arcmsr_handle_virtual_command arcmsr_iop_message_xfer arcmsr_iop_parking arcmsr_stop_adapter_bgrb

[PATCH 2/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_save_request

2017-12-12 Thread Jia-Ju Bai
SAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/media/platform/sti/bdisp/bdisp-hw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c b/drivers/media/platform/sti/bdisp/bdisp-hw.c index 4b62ceb..7b45

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

2017-12-12 Thread Jia-Ju Bai
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. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia

[BUG] haswell: a possible sleep-in-atomic bug in hsw_irq_thread

2017-12-12 Thread Jia-Ju Bai
ort. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] soc/sti: a possible sleep-in-atomic bug in uni_player_ctl_iec958_put

2017-12-12 Thread Jia-Ju Bai
bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] scsi/qla2xxx: a possible sleep-in-atomic bug in qlt_get_tag

2017-12-12 Thread Jia-Ju Bai
de review. Thanks, Jia-Ju Bai

[BUG] b44: two possible sleep-in-atomic bugs in b44_set_link_ksettings and b44_ioctl

2017-12-12 Thread Jia-Ju Bai
ead mutex_lock --> may sleep I do not find a good way to fix them, so I only report. These possible bugs are found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] renesas/sh_eth: two possible sleep-in-atomic bugs in sh_eth_set_link_ksettings and sh_eth_nway_reset

2017-12-12 Thread Jia-Ju Bai
set (acquire the spinlock) phy_start_aneg phy_start_aneg_priv mutex_lock --> may sleep I do not find a good way to fix them, so I only report. These possible bugs are found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[BUG] renesas/ravb: two possible sleep-in-atomic bugs in ravb_set_link_ksettings and ravb_nway_reset

2017-12-12 Thread Jia-Ju Bai
set (acquire the spinlock) phy_start_aneg phy_start_aneg_priv mutex_lock --> may sleep I do not find a good way to fix them, so I only report. These possible bugs are found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

Re: [BUG] scsi/qla2xxx: a possible sleep-in-atomic bug in qlt_get_tag

2017-12-12 Thread Jia-Ju Bai
On 2017/12/13 12:42, James Bottomley wrote: On Wed, 2017-12-13 at 11:18 +0800, Jia-Ju Bai wrote: The driver may sleep under a spinlock. The function call paths are: qlt_handle_abts_recv_work (acquire the spinlock) qlt_response_pkt_all_vps qlt_response_pkt

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

2017-12-12 Thread Jia-Ju Bai
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 Dec 2017 08:34:45 -0500 (EST) David Miller wrote: From: Jia-Ju Bai Date: Tue, 12 Dec 2017 16:38:12

[BUG] kaweth: a possible sleep-in-atomic bug in kaweth_start_xmit

2017-12-13 Thread Jia-Ju Bai
eep usb_kill_urb --> may sleep I do not find a good way to fix it, so I only report. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

[PATCH] qedi: Fix a possible sleep-in-atomic bug in qedi_process_tmf_resp

2017-12-13 Thread Jia-Ju Bai
und by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/scsi/qedi/qedi_fw.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedi/qedi_fw.c b/drivers/scsi/qedi/qedi_fw.c index bd302d3..20a9259 100644 --- a/driv

[PATCH] bluecard: Fix a possible sleep-in-atomic bug in bluecard_write_wakeup

2017-12-13 Thread Jia-Ju Bai
my code review. Signed-off-by: Jia-Ju Bai --- drivers/bluetooth/bluecard_cs.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/bluetooth/bluecard_cs.c b/drivers/bluetooth/bluecard_cs.c index d513ef4..82437a6 100644 --- a/drivers/bluetooth/bluecard_cs.c ++

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

2017-12-13 Thread Jia-Ju Bai
sis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/net/ethernet/hp/hp100.c |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c index c8c7ad2..6addcbd 100644 --- a/drivers/

[PATCH 2/2] hp100: Fix a possible sleep-in-atomic bug in hp100_down_vg_link

2017-12-13 Thread Jia-Ju Bai
und by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/net/ethernet/hp/hp100.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c index c8c7

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

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

[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

[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

[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] 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/

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

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 4.19 016/125] media: pci: ttpci: av7110: fix possible buffer overflow caused by bad DMA value in debiirq()

2020-09-01 Thread Jia-Ju Bai
On 2020/9/2 5:16, Pavel Machek wrote: On Tue 2020-09-01 18:35:23, Greg Kroah-Hartman wrote: On Tue, Sep 01, 2020 at 05:25:12PM +0100, Sean Young wrote: Greg, On Tue, Sep 01, 2020 at 05:09:31PM +0200, Greg Kroah-Hartman wrote: From: Jia-Ju Bai [ Upstream commit

[PATCH] atm: eni: avoid accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
lem, skb->data[3] is assigned to a local variable before DMA mapping, and then the driver accesses this local variable instead of skb->data[3]. Signed-off-by: Jia-Ju Bai --- drivers/atm/eni.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/atm/eni.c b/drivers/atm/en

[PATCH] atm: idt77252: avoid accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
s problem, the calculation result of skb->data is stored in a local variable before DMA mapping, and then the driver accesses this local variable instead of skb->data. Signed-off-by: Jia-Ju Bai --- drivers/atm/idt77252.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --

[PATCH] net: vmxnet3: avoid accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
e. To fix this problem, dma_map_single() is called after these accesses. Signed-off-by: Jia-Ju Bai --- drivers/net/vmxnet3/vmxnet3_drv.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c index ca3

[BUG] scsi: wd719x: accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
->data_p = 0; These accesses may cause data inconsistency between CPU cache and hardware. I am not sure how to properly fix this problem, and thus I only report it. Best wishes, Jia-Ju Bai

[PATCH] p54: avoid accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
hardware. To fix this problem, ((struct p54_hdr *)skb->data)->req_id is stored in a local variable before DMA mapping, and then the driver accesses this local variable instead of skb->data. Signed-off-by: Jia-Ju Bai --- drivers/net/wireless/intersil/p54/p54pci.c | 4 +++- 1 file

[BUG] net: rocker: accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
how to properly fix this problem, and thus I only report it. Best wishes, Jia-Ju Bai

[BUG] crypto: qat: accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
h as:   bufl->bufers[y].len = sg->length;   bufl->num_bufs = sg_nctr;   bufers = buflout->bufers;   buflout->num_bufs = sg_nctr; These accesses may cause data inconsistency between CPU cache and hardware. I am not sure how to properly fix this problem, and thus I only report it. Best wishes, Jia-Ju Bai

[BUG] crypto: hisilicon: accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
he and hardware. I am not sure how to properly fix this problem, and thus I only report it. Best wishes, Jia-Ju Bai

[PATCH] scsi: esas2r: fix possible buffer overflow caused by bad DMA value in esas2r_process_fs_ioctl()

2020-08-02 Thread Jia-Ju Bai
o cause buffer overflow. To fix this problem, "fsc->command" is assigned to a local variable, and then this local variable is used to replace "fsc->command". Signed-off-by: Jia-Ju Bai --- drivers/scsi/esas2r/esas2r_flash.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

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

2020-08-02 Thread Jia-Ju Bai
q->op" can be modified to cause buffer overflow when the driver accesses "vfdi_ops[req->op]". To fix this problem, "req->op" is assigned to a local variable, and then the driver accesses this variable instead of "req->op". Signed-off-by: Jia-Ju Bai --- dri

Re: [BUG] crypto: hisilicon: accessing the data mapped to streaming DMA

2020-08-02 Thread Jia-Ju Bai
On 2020/8/3 9:12, Zhou Wang wrote: On 2020/8/2 22:52, Jia-Ju Bai wrote: In qm_qp_ctx_cfg(), "sqc" and "aeqc" are mapped to streaming DMA: eqc_dma = dma_map_single(..., eqc, ...); .. aeqc_dma = dma_map_single(..., aeqc, ...); Only sqc, cqc will be configu

Re: [PATCH] scsi: esas2r: fix possible buffer overflow caused by bad DMA value in esas2r_process_fs_ioctl()

2020-08-02 Thread Jia-Ju Bai
On 2020/8/2 23:47, James Bottomley wrote: On Sun, 2020-08-02 at 23:21 +0800, Jia-Ju Bai wrote: Because "fs" is mapped to DMA, its data can be modified at anytime by malicious or malfunctioning hardware. In this case, the check "if (fsc->command >= cmdcnt)" ca

Re: [PATCH] net: vmxnet3: avoid accessing the data mapped to streaming DMA

2020-08-03 Thread Jia-Ju Bai
On 2020/8/4 6:59, David Miller wrote: From: Jia-Ju Bai Date: Sun, 2 Aug 2020 21:11:07 +0800 In vmxnet3_probe_device(), "adapter" is mapped to streaming DMA: adapter->adapter_pa = dma_map_single(..., adapter, ...); Then "adapter" is accessed at many places in

[PATCH v2 1/4 resend] rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA

2020-11-18 Thread Jia-Ju Bai
rol is accessed on line 681: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- v2: * Use "rtlwifi" as subject pref

[PATCH v2 3/4 resend] rtlwifi: rtl8192de: avoid accessing the data mapped to streaming DMA

2020-11-18 Thread Jia-Ju Bai
rol is accessed on line 670: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- v2: * Use "rtlwifi" as subject pref

Re: [PATCH v2 1/4] rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA

2020-11-18 Thread Jia-Ju Bai
Thanks for the advice. I have added the description of the changes and resent the patches. Best wishes, Jia-Ju Bai On 2020/11/19 1:20, Larry Finger wrote: On 11/17/20 7:53 PM, Jia-Ju Bai wrote: In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on line 677:    dma_add

[PATCH v2 4/4 resend] rtlwifi: rtl8723ae: avoid accessing the data mapped to streaming DMA

2020-11-18 Thread Jia-Ju Bai
t;frame_control is accessed on line 535: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- v2: * Use "rtlwifi" as subject pref

[PATCH v2 2/4 resend] rtlwifi: rtl8192ce: avoid accessing the data mapped to streaming DMA

2020-11-18 Thread Jia-Ju Bai
rol is accessed on line 534: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- v2: * Use "rtlwifi" as subject pref

[PATCH v2 2/4] rtlwifi: rtl8192ce: avoid accessing the data mapped to streaming DMA

2020-11-17 Thread Jia-Ju Bai
rol is accessed on line 534: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx

[PATCH v2 3/4] rtlwifi: rtl8192de: avoid accessing the data mapped to streaming DMA

2020-11-17 Thread Jia-Ju Bai
rol is accessed on line 670: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx

[PATCH v2 1/4] rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA

2020-11-17 Thread Jia-Ju Bai
rol is accessed on line 681: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx

Re: [PATCH] rtl8192ce: avoid accessing the data mapped to streaming DMA

2020-11-17 Thread Jia-Ju Bai
On 2020/11/7 19:44, Kalle Valo wrote: Jia-Ju Bai wrote: In rtl92ce_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on line 530: dma_addr_t mapping = dma_map_single(..., skb->data, ...); On line 533, skb->data is assigned to hdr after cast: struct ieee80211_hdr *hdr

[PATCH v2 4/4] rtlwifi: rtl8723ae: avoid accessing the data mapped to streaming DMA

2020-11-17 Thread Jia-Ju Bai
t;frame_control is accessed on line 535: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai --- drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx

Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()

2019-07-29 Thread Jia-Ju Bai
On 2019/7/29 21:45, Andrew Lunn wrote: On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote: In phy_led_trigger_change_speed(), there is an if statement on line 48 to check whether phy->last_triggered is NULL: if (!phy->last_triggered) When phy->last_triggered is NULL, i

[PATCH v2] fs: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling()

2019-07-29 Thread Jia-Ju Bai
nd by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- v2: * Adjust the code and add an assignment. Thank Darrick J. Wong for helpful advice. --- fs/xfs/scrub/dabtree.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/xfs/scrub/dabt

Re: [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()

2019-07-30 Thread Jia-Ju Bai
On 2019/7/30 11:41, David Miller wrote: From: Andrew Lunn Date: Tue, 30 Jul 2019 05:32:29 +0200 On Tue, Jul 30, 2019 at 10:25:36AM +0800, Jia-Ju Bai wrote: On 2019/7/29 21:45, Andrew Lunn wrote: On Mon, Jul 29, 2019 at 05:24:24PM +0800, Jia-Ju Bai wrote: In phy_led_trigger_change_speed

[PATCH v2] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()

2019-07-30 Thread Jia-Ju Bai
le null-pointer dereference may occur. To fix this bug, led_trigger_event(>last_triggered->trigger, LED_OFF) is called when phy->last_triggered is not NULL. This bug is found by a static analysis tool STCheck written by the OSLAB group in Tsinghua University. Signed-off-by: J

Re: linux-next: build warning after merge of the akpm-current tree

2019-07-31 Thread Jia-Ju Bai
this patch. Thus, I think the definition of ocfs2_xa_add_entry() could be removed. If it is okay, I can send a new patch (v3). Best wishes, Jia-Ju Bai

[PATCH] security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb()

2019-07-23 Thread Jia-Ju Bai
_to_auditdata(skb, , NULL); Thus, possible null-pointer dereferences may occur when skb is NULL. To fix these possible bugs, an if statement is added to check skb. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- security/smack/smack_lsm

[PATCH] fs: afs: Fix a possible null-pointer dereference in afs_put_read()

2019-07-23 Thread Jia-Ju Bai
null-pointer dereference may occur in this case. To fix this possible bug, an if statement is added in afs_put_read() to check req->pages. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- fs/afs/file.c | 12 +++- 1 file changed, 7 i

[PATCH] x86: Fix possible null-pointer dereferences in untrack_pfn()

2019-07-23 Thread Jia-Ju Bai
rt; Thus, possible null-pointer dereferences may occur. To fix these possible bugs, vma is checked on line 1063. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- arch/x86/mm/pat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

[PATCH] ALSA: isa: gus: Fix a possible null-pointer dereference in snd_gf1_mem_xfree()

2019-07-23 Thread Jia-Ju Bai
ay occur in this case. To fix this possible bug, block->next is checked before using it. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai --- sound/isa/gus/gus_mem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/isa/gus/g

Re: [PATCH] ALSA: isa: gus: Fix a possible null-pointer dereference in snd_gf1_mem_xfree()

2019-07-23 Thread Jia-Ju Bai
Thanks for the quick reply :) I think you are right, and I did not consider "if (alloc->last == block)" Sorry for the false report... Best wishes, Jia-Ju Bai On 2019/7/23 21:47, Takashi Iwai wrote: On Tue, 23 Jul 2019 15:40:20 +0200, Jia-Ju Bai wrote: In snd_

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