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
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
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
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
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
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
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
;
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
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
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
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
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
12 matches
Mail list logo