[PATCH] arch: x86: xen: check the return value of kasprintf()

2022-02-25 Thread Jia-Ju Bai
841355a ("x86: split spinlock implementations out into their own files") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai --- arch/x86/xen/smp.c | 2 ++ arch/x86/xen/smp_pv.c | 2 ++ arch/x86/xen/spinlock.c | 2 ++ 3 files changed, 6 insertions(+) diff --git a/arch/x86/xen/sm

[Xen-devel] [BUG] xen: Two possible sleep-in-atomic-context bugs in bind_evtchn_to_irqhandler()

2018-06-19 Thread Jia-Ju Bai
gs are found by my static analysis tool (DSAC-2) and checked by my code review. I do not know how to correctly fix these bugs, so I just report them. Maybe create_active() should not be called with holding a spinlock. Best wishes, Jia-Ju Bai ___ Xen-devel m

[Xen-devel] [PATCH] xen: Fix two possible sleep-in-atomic-context bugs in create_active()

2018-06-19 Thread Jia-Ju Bai
pvcalls_front_accept To fix these bugs, GFP_KERNEL is replaced with GFP_ATOMIC. These bugs are found by my static analysis tool (DSAC-2) and checked by my code review. Signed-off-by: Jia-Ju Bai --- drivers/xen/pvcalls-front.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen

Re: [Xen-devel] [PATCH] xen: xenbus: Fix a possible data race in xs_request_enter

2018-05-08 Thread Jia-Ju Bai
On 2018/5/8 15:02, Juergen Gross wrote: On 08/05/18 05:34, Jia-Ju Bai wrote: The read operation to "req->type" is protected by the lock on line 128, but the write operation to this data on line 118 is not protected by the lock. Thus, there may exist a data race for "req-&g

[Xen-devel] [PATCH] xen: xenbus: Fix a possible data race in xs_request_enter

2018-05-07 Thread Jia-Ju Bai
; should be also protected by the lock. Signed-off-by: Jia-Ju Bai --- drivers/xen/xenbus/xenbus_xs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c index 49a3874ae6bb..274cdfee08b1 100644 --- a/drivers/x

[Xen-devel] [PATCH] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_reg_add

2018-04-10 Thread Jia-Ju Bai
not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/xen/xen-pciback/pci_stub.c | 2 +- 1

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

2018-04-10 Thread Jia-Ju Bai
On 2018/4/10 23:01, Boris Ostrovsky wrote: On 04/10/2018 10:31 AM, Jia-Ju Bai wrote: On 2018/4/10 22:27, Boris Ostrovsky wrote: On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: pcistub_probe() is never called in atomic context. This function is only set as ".probe" in struct pci_driver

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

2018-04-10 Thread Jia-Ju Bai
On 2018/4/10 22:27, Boris Ostrovsky wrote: On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: pcistub_probe() is never called in atomic context. This function is only set as ".probe" in struct pci_driver. Despite never getting called from atomic context, pcistub_probe() calls kmal

[Xen-devel] [PATCH 2/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_init_device

2018-04-09 Thread Jia-Ju Bai
ocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/xen/xen-pcibac

[Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

2018-04-09 Thread Jia-Ju Bai
e replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/xen/xen-pciback/pci_stub.c | 2 +- 1 file changed, 1 inser

[Xen-devel] [PATCH 3/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_device_alloc

2018-04-09 Thread Jia-Ju Bai
ontext. Despite never getting called from atomic context, pcistub_device_alloc() calls kzalloc() with GFP_ATOMIC, which does not sleep for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. Signed-of

[Xen-devel] [PATCH 4/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in xen_pcibk_config_quirks_init

2018-04-09 Thread Jia-Ju Bai
ossibility of sucessful allocation. Signed-off-by: Jia-Ju Bai --- drivers/xen/xen-pciback/conf_space_quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/conf_space_quirks.c b/drivers/xen/xen-pciback/conf_space_quirks.c index 7476791..e3df3f9 10