Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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 kmalloc() 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. > > 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 > Applied the series and the extra patch to for-linus-4.17 -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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 kmalloc() 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. 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 For all 5 patches: Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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. Despite never getting called from atomic context, pcistub_probe() calls kmalloc() 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. 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 What about use of GFP_ATOMIC in pcistub_reg_add()? Thanks for your reply :) I find pcistub_reg_add() is called by pcistub_quirk_add(). And pcistub_quirk_add() is called in the macro DRIVER_ATTR(). I am not sure whether DRIVER_ATTR() can make the function called in atomic context, so I do not analyze it in my tool. I don't see why it needs to be ATOMIC, it's sysfs access. Can you send a patch to fix it as well? Okay, I will send a patch for it soon. You can have a look :) Best wishes, Jia-Ju Bai ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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. >>> >>> Despite never getting called from atomic context, >>> pcistub_probe() calls kmalloc() 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. >>> >>> 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 >> What about use of GFP_ATOMIC in pcistub_reg_add()? > > Thanks for your reply :) > I find pcistub_reg_add() is called by pcistub_quirk_add(). > And pcistub_quirk_add() is called in the macro DRIVER_ATTR(). > I am not sure whether DRIVER_ATTR() can make the function called in > atomic context, > so I do not analyze it in my tool. I don't see why it needs to be ATOMIC, it's sysfs access. Can you send a patch to fix it as well? Thanks. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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 kmalloc() 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. 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 What about use of GFP_ATOMIC in pcistub_reg_add()? Thanks for your reply :) I find pcistub_reg_add() is called by pcistub_quirk_add(). And pcistub_quirk_add() is called in the macro DRIVER_ATTR(). I am not sure whether DRIVER_ATTR() can make the function called in atomic context, so I do not analyze it in my tool. Best wishes, Jia-Ju Bai ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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 kmalloc() 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. > > 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 What about use of GFP_ATOMIC in pcistub_reg_add()? -boris > --- > drivers/xen/xen-pciback/pci_stub.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/xen/xen-pciback/pci_stub.c > b/drivers/xen/xen-pciback/pci_stub.c > index 9e480fd..95e6ddd 100644 > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -577,7 +577,7 @@ static int pcistub_probe(struct pci_dev *dev, const > struct pci_device_id *id) > } > > if (!match) { > - pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_ATOMIC); > + pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL); > if (!pci_dev_id) { > err = -ENOMEM; > goto out; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe
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 kmalloc() 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. 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 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 9e480fd..95e6ddd 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -577,7 +577,7 @@ static int pcistub_probe(struct pci_dev *dev, const struct pci_device_id *id) } if (!match) { - pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_ATOMIC); + pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL); if (!pci_dev_id) { err = -ENOMEM; goto out; -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel