From: Alex Williamson <alex.williamson@redhat.com>
To: "Wang, Wei W" <wei.w.wang@intel.com>
Cc: Kunwu Chan <chentao@kylinos.cn>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] vfio: Use WARN_ON for low-probability allocation failure issue in vfio_pci_bus_notifier
Date: Mon, 15 Jan 2024 09:28:41 -0700 [thread overview]
Message-ID: <20240115092841.19dc32f6.alex.williamson@redhat.com> (raw)
In-Reply-To: <DS0PR11MB6373BAF9CFEC4D67DEAAB1F7DC6C2@DS0PR11MB6373.namprd11.prod.outlook.com>
On Mon, 15 Jan 2024 15:41:02 +0000
"Wang, Wei W" <wei.w.wang@intel.com> wrote:
> On Monday, January 15, 2024 2:35 PM, Kunwu Chan wrote:
> > kasprintf() returns a pointer to dynamically allocated memory which can be
> > NULL upon failure.
> >
> > This is a blocking notifier callback, so errno isn't a proper return value. Use
> > WARN_ON to small allocation failures.
> >
> > Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
> > ---
> > v2: Use WARN_ON instead of return errno
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> > index 1cbc990d42e0..61aa19666050 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -2047,6 +2047,7 @@ static int vfio_pci_bus_notifier(struct notifier_block
> > *nb,
> > pci_name(pdev));
> > pdev->driver_override = kasprintf(GFP_KERNEL, "%s",
> > vdev->vdev.ops->name);
> > + WARN_ON(!pdev->driver_override);
>
> Saw Alex's comments on v1. Curious why not return "NOTIFY_BAD" on errors though
> less likely? Similar examples could be found in kvm_pm_notifier_call, kasan_mem_notifier etc.
If the statement is that there are notifier call chains that return
NOTIFY_BAD, I would absolutely agree, but the return value needs to be
examined from the context of the caller. BUS_NOTIFY_ADD_DEVICE is
notified via bus_notify() in device_add(). What does it accomplish to
return NOTIFY_BAD in a chain that ignores the return value? At best
we're preventing callbacks further down the chain from being called.
That doesn't seem obviously beneficial either.
The scenario here is similar to that in fail_iommu_bus_notify() where
they've chosen to trigger a pr_warn() if they're unable to crease sysfs
entries. In fact, a pci_warn(), maybe even pci_err() might be a better
alternative here than a WARN_ON(). Thanks,
Alex
next prev parent reply other threads:[~2024-01-15 16:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 6:34 [PATCH v2] vfio: Use WARN_ON for low-probability allocation failure issue in vfio_pci_bus_notifier Kunwu Chan
2024-01-15 15:41 ` Wang, Wei W
2024-01-15 16:28 ` Alex Williamson [this message]
2024-01-16 12:08 ` Wang, Wei W
2024-02-22 21:37 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240115092841.19dc32f6.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=chentao@kylinos.cn \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wei.w.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).