Re: [PATCH 1/2] vdpa: support per virtqueue max queue size
在 2021/7/7 下午12:04, Yongji Xie 写道:
static long vhost_vdpa_get_vring_num(struct vhost_vdpa *v, u16 __user *argp)
{
- struct vdpa_device *vdpa = v->vdpa;
- const struct vdpa_config_ops *ops = vdpa->config;
u16 num;
- num = ops->get_vq_num_max(vdpa);
+ /*
+* VHOST_VDPA_GET_VRING_NUM asssumes a global max virtqueue
s/asssumes/assumes. Other looks good to me.
Thanks,
Yongji
Will fix.
Thanks
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH linux-next v3 2/6] vdpa: Introduce query of device config layout
在 2021/7/7 上午1:07, Parav Pandit 写道:
From: Jason Wang
Sent: Monday, July 5, 2021 10:05 AM
在 2021/7/2 下午2:04, Parav Pandit 写道:
From: Jason Wang
Sent: Thursday, July 1, 2021 1:13 PM
Actually it depends on what attributes is required for building the config.
We can simply reuse the existing virtio_net_config, if most of the
fields are required.
struct virtio_net_config_set {
__virtio64 features;
union {
struct virtio_net_config;
__virtio64 reserved[64];
}
};
If only few of the is required, we can just pick them and use another
structure.
The point is we define structure based on current fields. Tomorrow a new
RSS or rx scaling scheme appears, and structure size might need change.
And it demands us to go back to length based typecasting code.
and to avoid some length check we pick some arbitrary size reserved
words.
And I do not know what network research group will come up for new rss
algorithm and needed plumbing.
Yes, but as discussed, we may suffer the similar issue at the device level. E.g
we need a command to let PF to "build" the config for a VF or SF.
I am not sure.
Current scope of a VDPA is, once there is a has PF,VF,SF and you configure or
create a vdpa device out of it.
Given the device config is not spelled out in the virtio spec, may be we can
wait for it to define virtio management interface.
Yes.
Wait is needed only if we want to cast U->K UAPI in a structure which is bound
to evolve.
And hence I just want to exchange as individual fields.
It's not arbitrary but with fixed length.
Its fixed, but decided arbitrarily large in anticipation that we likely need to
grow.
And sometimes that fall short when next research comes up with more
creative thoughts.
How about something like TLVs in the virtio spec then?
Possibly yes.
It may only work for netlink (with some duplication with the existing
virtio uAPI). If we can solve it at general virtio layer, it would be
better. Otherwise we need to invent them again in the virtio spec.
Virtio spec will likely define what should be config fields to program and its
layout.
Kernel can always fill up the format that virtio spec demands.
Yes, I wonder if you have the interest to work on the spec to support this.
I am happy to contribute, I need to ask my supervisor to spend some time in
this area.
Let me figure out the logistics.
Good to know that.
I think even for the current mlx5e vDPA it would be better, otherwise we
may have:
vDPA tool -> [netlink specific vDPA attributes(1)] -> vDPA core -> [vDPA
core specific VDPA attributes(2)] -> mlx5e_vDPA -> [mlx5e specific vDPA
attributes(3)] -> mlx5e_core
We need to use a single and unified virtio structure in all the (1), (2)
and (3).
This is where I differ.
Its only vdpa tool -> vdpa core -> vendor_driver
Vdpa tool -> vdpa core = netlink attribute
Vdpa core -> vendor driver = struct_foo. (internal inside the linux kernel)
If tomorrow virtio spec defines struct_foo to be something else, kernel can
always upgrade to struct_bar without upgrading UAPI netlink attributes.
That's fine. Note that actually have an extra level if vendor_driver is
virtio-pci vDPA driver (vp_vdpa).
Then we have
vdpa tool -> vdpa core -> vp_vdpa -> virtio-pci device
So we still need invent commands to configure/build VF/SF config space
between vp_vdpa and virtio-pci device.
Yes. This is needed, but again lets keep the two layers separate.
In the example I provided, we will be able to fill the structure and pass this
internally between vp_vdpa->virtio pci driver.
And I think we may suffer the
similar issue as we met here (vdpa tool -> vdpa core).
Netlink attributes addition will be needed only when struct_foo has newer
fields.
This will be still forward/backward compatible.
An exact example of this is drivers/net/vxlan.c
vxlan_nl2conf().
A vxlan device needs VNI, src ip, dst ip, tos, and more.
Instead of putting all in single structure vxlan_config as UAPI, those
optional fields are netlink attributes.
And vxlan driver internally fills up the config structure.
I am very much convinced with the above vxlan approach that enables all
functionality needed without typecasting code and without defining arbitrary
length structs.
Right, but we had some small differences here:
1) vxlan doesn't have a existing uAPI
2) vxlan configuration is not used for hardware
True but vxlan example doesn’t prevent to do #2.
Basically, I'm not against this approach, I just wonder if it's
better/simpler to solve it at virtio layer because the semantic is
defined by the spec not netlink.
vdpa core will be able to use the virtio spec defined config whenever it occurs.
So I think both of us have strong points. Maybe it's the time for
Michael to decide how it will go.
Michael, please share your thoughts here.
Thanks
___
Virtualization mailing list
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue 06 Jul 13:43 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> > On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > > index c1404d3dae2c..7f6fac618ab2 100644
> > > --- a/drivers/rpmsg/rpmsg_core.c
> > > +++ b/drivers/rpmsg/rpmsg_core.c
> > > @@ -530,7 +530,7 @@ static int rpmsg_dev_probe(struct device *dev)
> > > return err;
> > > }
> > >
> > > -static int rpmsg_dev_remove(struct device *dev)
> > > +static void rpmsg_dev_remove(struct device *dev)
> > > {
> > > struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> > > struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> > > @@ -546,8 +546,6 @@ static int rpmsg_dev_remove(struct device *dev)
> > >
> > > if (rpdev->ept)
> > > rpmsg_destroy_ept(rpdev->ept);
> > > -
> > > - return err;
> >
> > This leaves err assigned but never used, but I don't mind following up
> > with a patch cleaning that up after this has landed.
>
> Ah, good catch. If I send out a v3 I will fold the following into this
> patch:
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index 7f6fac618ab2..9151836190ce 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -534,10 +534,9 @@ static void rpmsg_dev_remove(struct device *dev)
> {
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> - int err = 0;
>
> if (rpdev->ops->announce_destroy)
> - err = rpdev->ops->announce_destroy(rpdev);
> + rpdev->ops->announce_destroy(rpdev);
>
> if (rpdrv->remove)
> rpdrv->remove(rpdev);
>
Sounds good, feel free to keep my ack on this.
> Maybe .announce_destroy() should then be changed to return void, too?
> Something like:
>
Yes, I saw this opportunity as well. But that will fan out further, so
let's postpone that until your series has landed and we can follow up
with such changes through the remoteproc tree.
> diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
> index a76c344253bf..d5204756714c 100644
> --- a/drivers/rpmsg/rpmsg_internal.h
> +++ b/drivers/rpmsg/rpmsg_internal.h
> @@ -40,7 +40,7 @@ struct rpmsg_device_ops {
> struct rpmsg_channel_info chinfo);
>
> int (*announce_create)(struct rpmsg_device *ept);
> - int (*announce_destroy)(struct rpmsg_device *ept);
> + void (*announce_destroy)(struct rpmsg_device *ept);
> };
>
> /**
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index 8e49a3bacfc7..4e05994634f8 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -340,7 +340,7 @@ static int virtio_rpmsg_announce_create(struct
> rpmsg_device *rpdev)
> return err;
> }
>
> -static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
> +static void virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
> {
> struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
> struct virtproc_info *vrp = vch->vrp;
> @@ -360,8 +360,6 @@ static int virtio_rpmsg_announce_destroy(struct
> rpmsg_device *rpdev)
> if (err)
> dev_err(dev, "failed to announce service %d\n", err);
> }
> -
> - return err;
> }
>
> static const struct rpmsg_device_ops virtio_rpmsg_ops = {
>
> though it's not obvious for me that the last hunk is sensible. (OTOH the
> return code is ignored anyhow as rpmsg_dev_remove() is the only caller.
>
I need to backtrack a little bit more to figure out why we ended up with
this...
Thanks,
Bjorn
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 6, 2021 at 8:51 AM Uwe Kleine-König wrote: > > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- For CXL, DAX, and NVDIMM Acked-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their remove callback.
> Additionally some resource leaks were fixed that were caused by drivers
> returning an error code in the expectation that the driver won't go
> away.
>
> With struct bus_type::remove returning void it's prevented that newly
> implemented buses return an ignored error code and so don't anticipate
> wrong expectations for driver authors.
>
Thanks for doing this!
Acked-by: Bjorn Andersson (rpmsg and apr)
[..]
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index c1404d3dae2c..7f6fac618ab2 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -530,7 +530,7 @@ static int rpmsg_dev_probe(struct device *dev)
> return err;
> }
>
> -static int rpmsg_dev_remove(struct device *dev)
> +static void rpmsg_dev_remove(struct device *dev)
> {
> struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver);
> @@ -546,8 +546,6 @@ static int rpmsg_dev_remove(struct device *dev)
>
> if (rpdev->ept)
> rpmsg_destroy_ept(rpdev->ept);
> -
> - return err;
This leaves err assigned but never used, but I don't mind following up
with a patch cleaning that up after this has landed.
> }
>
> static struct bus_type rpmsg_bus = {
Regards,
Bjorn
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [PATCH linux-next v3 2/6] vdpa: Introduce query of device config layout
> From: Jason Wang
> Sent: Monday, July 5, 2021 10:05 AM
>
> 在 2021/7/2 下午2:04, Parav Pandit 写道:
> >
> >> From: Jason Wang
> >> Sent: Thursday, July 1, 2021 1:13 PM
> >>
> >>
> >> Actually it depends on what attributes is required for building the config.
> >>
> >> We can simply reuse the existing virtio_net_config, if most of the
> >> fields are required.
> >>
> >> struct virtio_net_config_set {
> >> __virtio64 features;
> >> union {
> >> struct virtio_net_config;
> >> __virtio64 reserved[64];
> >> }
> >> };
> >>
> >> If only few of the is required, we can just pick them and use another
> >> structure.
> > The point is we define structure based on current fields. Tomorrow a new
> RSS or rx scaling scheme appears, and structure size might need change.
> > And it demands us to go back to length based typecasting code.
> > and to avoid some length check we pick some arbitrary size reserved
> words.
> > And I do not know what network research group will come up for new rss
> algorithm and needed plumbing.
>
>
> Yes, but as discussed, we may suffer the similar issue at the device level.
> E.g
> we need a command to let PF to "build" the config for a VF or SF.
I am not sure.
Current scope of a VDPA is, once there is a has PF,VF,SF and you configure or
create a vdpa device out of it.
> > Given the device config is not spelled out in the virtio spec, may be we can
> wait for it to define virtio management interface.
>
> Yes.
Wait is needed only if we want to cast U->K UAPI in a structure which is bound
to evolve.
And hence I just want to exchange as individual fields.
> >> It's not arbitrary but with fixed length.
> > Its fixed, but decided arbitrarily large in anticipation that we likely
> > need to
> grow.
> > And sometimes that fall short when next research comes up with more
> creative thoughts.
>
>
> How about something like TLVs in the virtio spec then?
Possibly yes.
>
>
> >
> >> It may only work for netlink (with some duplication with the existing
> >> virtio uAPI). If we can solve it at general virtio layer, it would be
> >> better. Otherwise we need to invent them again in the virtio spec.
> >>
> > Virtio spec will likely define what should be config fields to program and
> > its
> layout.
> > Kernel can always fill up the format that virtio spec demands.
>
>
> Yes, I wonder if you have the interest to work on the spec to support this.
>
I am happy to contribute, I need to ask my supervisor to spend some time in
this area.
Let me figure out the logistics.
>
> >
> >> I think even for the current mlx5e vDPA it would be better, otherwise we
> >> may have:
> >>
> >> vDPA tool -> [netlink specific vDPA attributes(1)] -> vDPA core -> [vDPA
> >> core specific VDPA attributes(2)] -> mlx5e_vDPA -> [mlx5e specific vDPA
> >> attributes(3)] -> mlx5e_core
> >>
> >> We need to use a single and unified virtio structure in all the (1), (2)
> >> and (3).
> > This is where I differ.
> > Its only vdpa tool -> vdpa core -> vendor_driver
> >
> > Vdpa tool -> vdpa core = netlink attribute
> > Vdpa core -> vendor driver = struct_foo. (internal inside the linux kernel)
> >
> > If tomorrow virtio spec defines struct_foo to be something else, kernel can
> always upgrade to struct_bar without upgrading UAPI netlink attributes.
>
>
> That's fine. Note that actually have an extra level if vendor_driver is
> virtio-pci vDPA driver (vp_vdpa).
>
> Then we have
>
> vdpa tool -> vdpa core -> vp_vdpa -> virtio-pci device
>
> So we still need invent commands to configure/build VF/SF config space
> between vp_vdpa and virtio-pci device.
Yes. This is needed, but again lets keep the two layers separate.
In the example I provided, we will be able to fill the structure and pass this
internally between vp_vdpa->virtio pci driver.
> And I think we may suffer the
> similar issue as we met here (vdpa tool -> vdpa core).
>
>
> > Netlink attributes addition will be needed only when struct_foo has newer
> fields.
> > This will be still forward/backward compatible.
> >
> > An exact example of this is drivers/net/vxlan.c
> > vxlan_nl2conf().
> > A vxlan device needs VNI, src ip, dst ip, tos, and more.
> > Instead of putting all in single structure vxlan_config as UAPI, those
> optional fields are netlink attributes.
> > And vxlan driver internally fills up the config structure.
> >
> > I am very much convinced with the above vxlan approach that enables all
> functionality needed without typecasting code and without defining arbitrary
> length structs.
>
>
> Right, but we had some small differences here:
>
> 1) vxlan doesn't have a existing uAPI
> 2) vxlan configuration is not used for hardware
>
True but vxlan example doesn’t prevent to do #2.
> Basically, I'm not against this approach, I just wonder if it's
> better/simpler to solve it at virtio layer because the semantic is
> defined by the spec not netlink.
vdpa core will be able to use the virtio
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 6, 2021 at 5:53 PM Uwe Kleine-König wrote: > > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König For the ACPI part: Acked-by: Rafael J. Wysocki > --- > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c| 3 +-- > drivers/amba/bus.c| 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c| 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c| 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c| 4 +--- > drivers/hid/hid-core.c| 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c| 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c| 4 +--- > drivers/mcb/mcb-core.c| 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c| 3 +-- > drivers/misc/mei/bus.c| 4 +--- > drivers/misc/tifm_core.c | 3 +-- > drivers/mmc/core/bus.c| 4 +--- > drivers/mmc/core/sdio_bus.c | 4 +--- > drivers/net/netdevsim/bus.c | 3 +-- > drivers/ntb/core.c| 4 +--- > drivers/ntb/ntb_transport.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- > drivers/pci/endpoint/pci-epf-core.c | 4 +--- > drivers/pci/pci-driver.c | 3 +-- > drivers/pcmcia/ds.c | 4 +--- > drivers/platform/surface/aggregator/bus.c | 4 +--- > drivers/platform/x86/wmi.c| 4 +--- > drivers/pnp/driver.c | 3 +-- > drivers/rapidio/rio-driver.c | 4 +--- > drivers/rpmsg/rpmsg_core.c| 4 +--- > drivers/s390/cio/ccwgroup.c | 4 +--- > drivers/s390/cio/css.c| 4 +--- > drivers/s390/cio/device.c | 4 +--- > drivers/s390/cio/scm.c| 4 +--- > drivers/s390/crypto/ap_bus.c | 4 +--- > drivers/scsi/scsi_debug.c | 3 +-- > drivers/siox/siox-core.c | 4 +--- > drivers/slimbus/core.c| 4 +--- > drivers/soc/qcom/apr.c| 4 +--- > drivers/spi/spi.c | 4 +--- > drivers/spmi/spmi.c | 3 +-- > drivers/ssb/main.c| 4
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 06 2021, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König > --- > > drivers/s390/cio/ccwgroup.c | 4 +--- > drivers/s390/cio/css.c| 4 +--- > drivers/s390/cio/device.c | 4 +--- > drivers/s390/cio/scm.c| 4 +--- > drivers/s390/crypto/ap_bus.c | 4 +--- > drivers/vfio/mdev/mdev_driver.c | 4 +--- For drivers/s390 and drivers/vfio: Reviewed-by: Cornelia Huck ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/2] vdpa: support per virtqueue max queue size
On Mon, Jul 05, 2021 at 03:19:09PM +0800, Jason Wang wrote: > Virtio spec allows the device to specify the per virtqueue max queue > size. vDPA needs to adapt to this flexibility. E.g Qemu advertise a > small control virtqueue for virtio-net. > > So this patch adds a index parameter to get_vq_num_max bus operations > for the device to report its per virtqueue max queue size. > > Both VHOST_VDPA_GET_VRING_NUM and VDPA_ATTR_DEV_MAX_VQ_SIZE assume a > global maximum size. So we iterate all the virtqueues to return the > minimal size in this case. Actually, the VHOST_VDPA_GET_VRING_NUM is > not a must for the userspace. Userspace may choose to check the > VHOST_SET_VRING_NUM for proving or validating the maximum virtqueue > size. Anyway, we can invent a per vq version of > VHOST_VDPA_GET_VRING_NUM in the future if it's necessary. > > Signed-off-by: Jason Wang > --- > drivers/vdpa/ifcvf/ifcvf_main.c | 2 +- > drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +- > drivers/vdpa/vdpa.c | 22 +- > drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +- > drivers/vdpa/virtio_pci/vp_vdpa.c | 2 +- > drivers/vhost/vdpa.c | 9 ++--- > drivers/virtio/virtio_vdpa.c | 2 +- > include/linux/vdpa.h | 5 - > 8 files changed, 36 insertions(+), 10 deletions(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On Tue, 06 Jul 2021, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König > --- > Hello, > > this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove > return void" that is not yet applied, see > https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de. > > I tested it using allmodconfig on amd64 and arm, but I wouldn't be > surprised if I still missed to convert a driver. So it would be great to > get this into next early after the merge window closes. > > I send this mail to all people that get_maintainer.pl emits for this > patch. I wonder how many recipents will refuse this mail because of the > long Cc: list :-) > > Best regards > Uwe > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c| 3 +-- > drivers/amba/bus.c| 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c| 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c| 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c| 4 +--- > drivers/hid/hid-core.c| 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c| 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c| 4 +--- > drivers/mcb/mcb-core.c| 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c| 3 +-- Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.4 09/31] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 88ed5e235e55..fcf9b572ec03 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -233,6 +233,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.4 08/31] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ] The dev->dev_private might not be allocated if virtio_gpu_pci_quirk() or virtio_gpu_init() failed. In this case, we should avoid the cleanup in virtio_gpu_release(). Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 476b9993b068..88ed5e235e55 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -257,6 +257,9 @@ int virtio_gpu_driver_unload(struct drm_device *dev) flush_work(>config_changed_work); vgdev->vdev->config->del_vqs(vgdev->vdev); + if (!vgdev) + return; + virtio_gpu_modeset_fini(vgdev); virtio_gpu_ttm_fini(vgdev); virtio_gpu_free_vbufs(vgdev); -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.9 09/35] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index d8b2027730d0..cde38e14232c 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -234,6 +234,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.9 08/35] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ] The dev->dev_private might not be allocated if virtio_gpu_pci_quirk() or virtio_gpu_init() failed. In this case, we should avoid the cleanup in virtio_gpu_release(). Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index ba7855da7c7f..d8b2027730d0 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -258,6 +258,9 @@ int virtio_gpu_driver_unload(struct drm_device *dev) flush_work(>config_changed_work); vgdev->vdev->config->del_vqs(vgdev->vdev); + if (!vgdev) + return; + virtio_gpu_modeset_fini(vgdev); virtio_gpu_ttm_fini(vgdev); virtio_gpu_free_vbufs(vgdev); -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 21/45] virtio_net: Remove BUG() to avoid machine dead
From: Xianting Tian [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 2d2a307c0231..71052d17c9ae 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1262,7 +1262,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) if (virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), false, 0)) - BUG(); + return -EPROTO; if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 13/45] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index e1a5e74f4080..edca3e827369 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -237,6 +237,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.14 12/45] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ] The dev->dev_private might not be allocated if virtio_gpu_pci_quirk() or virtio_gpu_init() failed. In this case, we should avoid the cleanup in virtio_gpu_release(). Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index bed450fbb216..e1a5e74f4080 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -261,6 +261,9 @@ void virtio_gpu_driver_unload(struct drm_device *dev) flush_work(>config_changed_work); vgdev->vdev->config->del_vqs(vgdev->vdev); + if (!vgdev) + return; + virtio_gpu_modeset_fini(vgdev); virtio_gpu_ttm_fini(vgdev); virtio_gpu_free_vbufs(vgdev); -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 24/55] virtio_net: Remove BUG() to avoid machine dead
From: Xianting Tian [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 0b1c6a8906b9..84a82c4a9535 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1550,7 +1550,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) if (virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), false, 0)) - BUG(); + return -EPROTO; if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 14/55] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 2cfd0016bd70..7e0092fd0703 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -237,6 +237,7 @@ int virtio_gpu_driver_load(struct drm_device *dev, unsigned long flags) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 4.19 13/55] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ] The dev->dev_private might not be allocated if virtio_gpu_pci_quirk() or virtio_gpu_init() failed. In this case, we should avoid the cleanup in virtio_gpu_release(). Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 22397a23780c..2cfd0016bd70 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -261,6 +261,9 @@ void virtio_gpu_driver_unload(struct drm_device *dev) flush_work(>config_changed_work); vgdev->vdev->config->del_vqs(vgdev->vdev); + if (!vgdev) + return; + virtio_gpu_modeset_fini(vgdev); virtio_gpu_ttm_fini(vgdev); virtio_gpu_free_vbufs(vgdev); -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 30/74] virtio_net: Remove BUG() to avoid machine dead
From: Xianting Tian [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index d8ee001d8e8e..5cd55f950032 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1548,7 +1548,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) if (virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), false, 0)) - BUG(); + return -EPROTO; if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 16/74] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 5c0249d3bd53..0727791872f5 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -218,6 +218,7 @@ int virtio_gpu_init(struct drm_device *dev) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.4 15/74] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ] The dev->dev_private might not be allocated if virtio_gpu_pci_quirk() or virtio_gpu_init() failed. In this case, we should avoid the cleanup in virtio_gpu_release(). Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 6dcc05ab31eb..5c0249d3bd53 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -243,6 +243,9 @@ void virtio_gpu_deinit(struct drm_device *dev) vgdev->vdev->config->reset(vgdev->vdev); vgdev->vdev->config->del_vqs(vgdev->vdev); + if (!vgdev) + return; + virtio_gpu_modeset_fini(vgdev); virtio_gpu_ttm_fini(vgdev); virtio_gpu_free_vbufs(vgdev); -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 061/137] virtio_net: Remove BUG() to avoid machine dead
From: Xianting Tian [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index e2c6c5675ec6..91e0e6254a01 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1563,7 +1563,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) if (virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), false, 0)) - BUG(); + return -EPROTO; if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 046/137] virtio-net: Add validation for used length
From: Xie Yongji
[ Upstream commit ad993a95c508417acdeb15244109e009e50d8758 ]
This adds validation for used length (might come
from an untrusted device) to avoid data corruption
or loss.
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20210531135852.113-1-xieyon...@bytedance.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/virtio_net.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 286f836a53bf..e2c6c5675ec6 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -660,6 +660,12 @@ static struct sk_buff *receive_small(struct net_device
*dev,
len -= vi->hdr_len;
stats->bytes += len;
+ if (unlikely(len > GOOD_PACKET_LEN)) {
+ pr_debug("%s: rx error: len %u exceeds max size %d\n",
+dev->name, len, GOOD_PACKET_LEN);
+ dev->stats.rx_length_errors++;
+ goto err_len;
+ }
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
if (xdp_prog) {
@@ -763,6 +769,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
err_xdp:
rcu_read_unlock();
stats->xdp_drops++;
+err_len:
stats->drops++;
put_page(page);
xdp_xmit:
@@ -816,6 +823,12 @@ static struct sk_buff *receive_mergeable(struct net_device
*dev,
head_skb = NULL;
stats->bytes += len - vi->hdr_len;
+ if (unlikely(len > truesize)) {
+ pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
+dev->name, len, (unsigned long)ctx);
+ dev->stats.rx_length_errors++;
+ goto err_skb;
+ }
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
if (xdp_prog) {
@@ -943,13 +956,6 @@ static struct sk_buff *receive_mergeable(struct net_device
*dev,
}
rcu_read_unlock();
- if (unlikely(len > truesize)) {
- pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
-dev->name, len, (unsigned long)ctx);
- dev->stats.rx_length_errors++;
- goto err_skb;
- }
-
head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
metasize);
curr_skb = head_skb;
--
2.30.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 022/137] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 5e716199ccee..618e46afcfc7 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -209,6 +209,7 @@ int virtio_gpu_init(struct drm_device *dev) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.10 021/137] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji
[ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ]
The dev->dev_private might not be allocated if virtio_gpu_pci_quirk()
or virtio_gpu_init() failed. In this case, we should avoid the cleanup
in virtio_gpu_release().
Signed-off-by: Xie Yongji
Link:
http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index eed57a931309..5e716199ccee 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -239,6 +239,9 @@ void virtio_gpu_release(struct drm_device *dev)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
+ if (!vgdev)
+ return;
+
virtio_gpu_modeset_fini(vgdev);
virtio_gpu_free_vbufs(vgdev);
virtio_gpu_cleanup_cap_cache(vgdev);
--
2.30.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.12 069/160] virtio_net: Remove BUG() to avoid machine dead
From: Xianting Tian [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 447582fa20a5..f7ce341bb328 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1558,7 +1558,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) if (virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), false, 0)) - BUG(); + return -EPROTO; if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.12 051/160] virtio-net: Add validation for used length
From: Xie Yongji
[ Upstream commit ad993a95c508417acdeb15244109e009e50d8758 ]
This adds validation for used length (might come
from an untrusted device) to avoid data corruption
or loss.
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20210531135852.113-1-xieyon...@bytedance.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/virtio_net.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0824e6999e49..447582fa20a5 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -660,6 +660,12 @@ static struct sk_buff *receive_small(struct net_device
*dev,
len -= vi->hdr_len;
stats->bytes += len;
+ if (unlikely(len > GOOD_PACKET_LEN)) {
+ pr_debug("%s: rx error: len %u exceeds max size %d\n",
+dev->name, len, GOOD_PACKET_LEN);
+ dev->stats.rx_length_errors++;
+ goto err_len;
+ }
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
if (xdp_prog) {
@@ -761,6 +767,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
err_xdp:
rcu_read_unlock();
stats->xdp_drops++;
+err_len:
stats->drops++;
put_page(page);
xdp_xmit:
@@ -814,6 +821,12 @@ static struct sk_buff *receive_mergeable(struct net_device
*dev,
head_skb = NULL;
stats->bytes += len - vi->hdr_len;
+ if (unlikely(len > truesize)) {
+ pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
+dev->name, len, (unsigned long)ctx);
+ dev->stats.rx_length_errors++;
+ goto err_skb;
+ }
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
if (xdp_prog) {
@@ -938,13 +951,6 @@ static struct sk_buff *receive_mergeable(struct net_device
*dev,
}
rcu_read_unlock();
- if (unlikely(len > truesize)) {
- pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
-dev->name, len, (unsigned long)ctx);
- dev->stats.rx_length_errors++;
- goto err_skb;
- }
-
head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
metasize);
curr_skb = head_skb;
--
2.30.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.12 024/160] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji
[ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ]
The dev->dev_private might not be allocated if virtio_gpu_pci_quirk()
or virtio_gpu_init() failed. In this case, we should avoid the cleanup
in virtio_gpu_release().
Signed-off-by: Xie Yongji
Link:
http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index b375394193be..aa532ad31a23 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -264,6 +264,9 @@ void virtio_gpu_release(struct drm_device *dev)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
+ if (!vgdev)
+ return;
+
virtio_gpu_modeset_fini(vgdev);
virtio_gpu_free_vbufs(vgdev);
virtio_gpu_cleanup_cap_cache(vgdev);
--
2.30.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.12 025/160] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index aa532ad31a23..f3379059f324 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -234,6 +234,7 @@ int virtio_gpu_init(struct drm_device *dev) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On Tue, Jul 06 2021, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Uwe Kleine-König wrote:
>
>> The driver core ignores the return value of this callback because there
>> is only little it can do when a device disappears.
>>
>> This is the final bit of a long lasting cleanup quest where several
>> buses were converted to also return void from their remove callback.
>> Additionally some resource leaks were fixed that were caused by drivers
>> returning an error code in the expectation that the driver won't go
>> away.
>>
>> With struct bus_type::remove returning void it's prevented that newly
>> implemented buses return an ignored error code and so don't anticipate
>> wrong expectations for driver authors.
>
> Yay!
>
>>
>> Signed-off-by: Uwe Kleine-König
>> ---
>> Hello,
>>
>> this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove
>> return void" that is not yet applied, see
>> https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de.
>>
>> I tested it using allmodconfig on amd64 and arm, but I wouldn't be
>> surprised if I still missed to convert a driver. So it would be great to
>> get this into next early after the merge window closes.
>
> I'm afraid you missed the s390-specific busses in drivers/s390/cio/
> (css/ccw/ccwgroup).
The change for vfio/mdev looks good.
The following should do the trick for s390; not sure if other
architectures have easy-to-miss busses as well.
diff --git a/drivers/s390/cio/ccwgroup.c b/drivers/s390/cio/ccwgroup.c
index 9748165e08e9..a66f416138ab 100644
--- a/drivers/s390/cio/ccwgroup.c
+++ b/drivers/s390/cio/ccwgroup.c
@@ -439,17 +439,15 @@ module_exit(cleanup_ccwgroup);
/** driver stuff **/
-static int ccwgroup_remove(struct device *dev)
+static void ccwgroup_remove(struct device *dev)
{
struct ccwgroup_device *gdev = to_ccwgroupdev(dev);
struct ccwgroup_driver *gdrv = to_ccwgroupdrv(dev->driver);
if (!dev->driver)
- return 0;
+ return;
if (gdrv->remove)
gdrv->remove(gdev);
-
- return 0;
}
static void ccwgroup_shutdown(struct device *dev)
diff --git a/drivers/s390/cio/css.c b/drivers/s390/cio/css.c
index a974943c27da..ebc321edba51 100644
--- a/drivers/s390/cio/css.c
+++ b/drivers/s390/cio/css.c
@@ -1371,15 +1371,14 @@ static int css_probe(struct device *dev)
return ret;
}
-static int css_remove(struct device *dev)
+static void css_remove(struct device *dev)
{
struct subchannel *sch;
- int ret;
sch = to_subchannel(dev);
- ret = sch->driver->remove ? sch->driver->remove(sch) : 0;
+ if (sch->driver->remove)
+ sch->driver->remove(sch);
sch->driver = NULL;
- return ret;
}
static void css_shutdown(struct device *dev)
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index 84f659cafe76..61d5d55bd9c8 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1742,7 +1742,7 @@ ccw_device_probe (struct device *dev)
return 0;
}
-static int ccw_device_remove(struct device *dev)
+static void ccw_device_remove(struct device *dev)
{
struct ccw_device *cdev = to_ccwdev(dev);
struct ccw_driver *cdrv = cdev->drv;
@@ -1776,8 +1776,6 @@ static int ccw_device_remove(struct device *dev)
spin_unlock_irq(cdev->ccwlock);
io_subchannel_quiesce(sch);
__disable_cmf(cdev);
-
- return 0;
}
static void ccw_device_shutdown(struct device *dev)
diff --git a/drivers/s390/cio/scm.c b/drivers/s390/cio/scm.c
index 9f26d4310bb3..b6b4589c70bd 100644
--- a/drivers/s390/cio/scm.c
+++ b/drivers/s390/cio/scm.c
@@ -28,12 +28,13 @@ static int scmdev_probe(struct device *dev)
return scmdrv->probe ? scmdrv->probe(scmdev) : -ENODEV;
}
-static int scmdev_remove(struct device *dev)
+static void scmdev_remove(struct device *dev)
{
struct scm_device *scmdev = to_scm_dev(dev);
struct scm_driver *scmdrv = to_scm_drv(dev->driver);
- return scmdrv->remove ? scmdrv->remove(scmdev) : -ENODEV;
+ if (scmdrv->remove)
+ scmdrv->remove(scmdev);
}
static int scmdev_uevent(struct device *dev, struct kobj_uevent_env *env)
diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index d2560186d771..8a0d37c0e2a5 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -884,7 +884,7 @@ static int ap_device_probe(struct device *dev)
return rc;
}
-static int ap_device_remove(struct device *dev)
+static void ap_device_remove(struct device *dev)
{
struct ap_device *ap_dev = to_ap_dev(dev);
struct ap_driver *ap_drv = ap_dev->drv;
@@ -909,8 +909,6 @@ static int ap_device_remove(struct device *dev)
ap_dev->drv = NULL;
put_device(dev);
-
- return 0;
}
struct ap_queue *ap_get_qdev(ap_qid_t qid)
[PATCH AUTOSEL 5.13 082/189] virtio_net: Remove BUG() to avoid machine dead
From: Xianting Tian [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ] We should not directly BUG() when there is hdr error, it is better to output a print when such error happens. Currently, the caller of xmit_skb() already did it. Signed-off-by: Xianting Tian Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 252f6718d730..2debb32a1813 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1625,7 +1625,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) if (virtio_net_hdr_from_skb(skb, >hdr, virtio_is_little_endian(vi->vdev), false, 0)) - BUG(); + return -EPROTO; if (vi->mergeable_rx_bufs) hdr->num_buffers = 0; -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.13 062/189] virtio-net: Add validation for used length
From: Xie Yongji
[ Upstream commit ad993a95c508417acdeb15244109e009e50d8758 ]
This adds validation for used length (might come
from an untrusted device) to avoid data corruption
or loss.
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
Link: https://lore.kernel.org/r/20210531135852.113-1-xieyon...@bytedance.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/virtio_net.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 78a01c71a17c..252f6718d730 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -721,6 +721,12 @@ static struct sk_buff *receive_small(struct net_device
*dev,
len -= vi->hdr_len;
stats->bytes += len;
+ if (unlikely(len > GOOD_PACKET_LEN)) {
+ pr_debug("%s: rx error: len %u exceeds max size %d\n",
+dev->name, len, GOOD_PACKET_LEN);
+ dev->stats.rx_length_errors++;
+ goto err_len;
+ }
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
if (xdp_prog) {
@@ -824,6 +830,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
err_xdp:
rcu_read_unlock();
stats->xdp_drops++;
+err_len:
stats->drops++;
put_page(page);
xdp_xmit:
@@ -877,6 +884,12 @@ static struct sk_buff *receive_mergeable(struct net_device
*dev,
head_skb = NULL;
stats->bytes += len - vi->hdr_len;
+ if (unlikely(len > truesize)) {
+ pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
+dev->name, len, (unsigned long)ctx);
+ dev->stats.rx_length_errors++;
+ goto err_skb;
+ }
rcu_read_lock();
xdp_prog = rcu_dereference(rq->xdp_prog);
if (xdp_prog) {
@@ -1004,13 +1017,6 @@ static struct sk_buff *receive_mergeable(struct
net_device *dev,
}
rcu_read_unlock();
- if (unlikely(len > truesize)) {
- pr_debug("%s: rx error: len %u exceeds truesize %lu\n",
-dev->name, len, (unsigned long)ctx);
- dev->stats.rx_length_errors++;
- goto err_skb;
- }
-
head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
metasize, headroom);
curr_skb = head_skb;
--
2.30.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.13 031/189] drm/virtio: Fix double free on probe failure
From: Xie Yongji [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ] The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure. But such failure will be caught by virtio_gpu_probe() and then virtio_gpu_release() will be called to do some cleanup which will free vgdev and vgdev->vbufs again. So let's set dev->dev_private to NULL to avoid double free. Signed-off-by: Xie Yongji Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyon...@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index aa532ad31a23..f3379059f324 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -234,6 +234,7 @@ int virtio_gpu_init(struct drm_device *dev) err_vbufs: vgdev->vdev->config->del_vqs(vgdev->vdev); err_vqs: + dev->dev_private = NULL; kfree(vgdev); return ret; } -- 2.30.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH AUTOSEL 5.13 030/189] drm/virtio: Fixes a potential NULL pointer dereference on probe failure
From: Xie Yongji
[ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ]
The dev->dev_private might not be allocated if virtio_gpu_pci_quirk()
or virtio_gpu_init() failed. In this case, we should avoid the cleanup
in virtio_gpu_release().
Signed-off-by: Xie Yongji
Link:
http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-1-xieyon...@bytedance.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index b375394193be..aa532ad31a23 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -264,6 +264,9 @@ void virtio_gpu_release(struct drm_device *dev)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
+ if (!vgdev)
+ return;
+
virtio_gpu_modeset_fini(vgdev);
virtio_gpu_free_vbufs(vgdev);
virtio_gpu_cleanup_cap_cache(vgdev);
--
2.30.2
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On Tue, Jul 06 2021, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. Yay! > > Signed-off-by: Uwe Kleine-König > --- > Hello, > > this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove > return void" that is not yet applied, see > https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de. > > I tested it using allmodconfig on amd64 and arm, but I wouldn't be > surprised if I still missed to convert a driver. So it would be great to > get this into next early after the merge window closes. I'm afraid you missed the s390-specific busses in drivers/s390/cio/ (css/ccw/ccwgroup). ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On 06.07.21 11:50, Uwe Kleine-König wrote: The driver core ignores the return value of this callback because there is only little it can do when a device disappears. This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away. With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors. Signed-off-by: Uwe Kleine-König Xen-bits: Acked-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On 06/07/2021 11:50:37+0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König Acked-by: Alexandre Belloni > --- > Hello, > > this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove > return void" that is not yet applied, see > https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de. > > I tested it using allmodconfig on amd64 and arm, but I wouldn't be > surprised if I still missed to convert a driver. So it would be great to > get this into next early after the merge window closes. > > I send this mail to all people that get_maintainer.pl emits for this > patch. I wonder how many recipents will refuse this mail because of the > long Cc: list :-) > > Best regards > Uwe > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c| 3 +-- > drivers/amba/bus.c| 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c| 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c| 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c| 4 +--- > drivers/hid/hid-core.c| 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c| 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c| 4 +--- > drivers/mcb/mcb-core.c| 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c| 3 +-- > drivers/misc/mei/bus.c| 4 +--- > drivers/misc/tifm_core.c | 3 +-- > drivers/mmc/core/bus.c| 4 +--- > drivers/mmc/core/sdio_bus.c | 4 +--- > drivers/net/netdevsim/bus.c | 3 +-- > drivers/ntb/core.c| 4 +--- > drivers/ntb/ntb_transport.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- > drivers/pci/endpoint/pci-epf-core.c | 4 +--- > drivers/pci/pci-driver.c | 3 +-- > drivers/pcmcia/ds.c | 4 +--- > drivers/platform/surface/aggregator/bus.c | 4 +--- > drivers/platform/x86/wmi.c| 4 +--- > drivers/pnp/driver.c | 3 +-- > drivers/rapidio/rio-driver.c | 4 +--- > drivers/rpmsg/rpmsg_core.c| 4 +--- > drivers/scsi/scsi_debug.c | 3 +-- > drivers/siox/siox-core.c | 4 +--- > drivers/slimbus/core.c| 4 +--- > drivers/soc/qcom/apr.c| 4 +--- > drivers/spi/spi.c | 4 +--- > drivers/spmi/spmi.c | 3 +-- > drivers/ssb/main.c| 4 +--- > drivers/staging/fieldbus/anybuss/host.c | 4 +--- > drivers/staging/greybus/gbphy.c | 4 +--- > drivers/target/loopback/tcm_loop.c| 5 ++--- > drivers/thunderbolt/domain.c | 4 +--- > drivers/tty/serdev/core.c | 4 +--- > drivers/usb/common/ulpi.c | 4 +--- > drivers/usb/serial/bus.c | 4 +--- > drivers/usb/typec/bus.c | 4 +--- > drivers/vdpa/vdpa.c
Re: [PATCH v8 10/10] Documentation: Add documentation for VDUSE
On Tue, Jul 06, 2021 at 11:04:18AM +0800, Yongji Xie wrote: > On Mon, Jul 5, 2021 at 8:50 PM Stefan Hajnoczi wrote: > > > > On Mon, Jul 05, 2021 at 11:36:15AM +0800, Jason Wang wrote: > > > > > > 在 2021/7/4 下午5:49, Yongji Xie 写道: > > > > > > OK, I get you now. Since the VIRTIO specification says "Device > > > > > > configuration space is generally used for rarely-changing or > > > > > > initialization-time parameters". I assume the VDUSE_DEV_SET_CONFIG > > > > > > ioctl should not be called frequently. > > > > > The spec uses MUST and other terms to define the precise requirements. > > > > > Here the language (especially the word "generally") is weaker and > > > > > means > > > > > there may be exceptions. > > > > > > > > > > Another type of access that doesn't work with the VDUSE_DEV_SET_CONFIG > > > > > approach is reads that have side-effects. For example, imagine a field > > > > > containing an error code if the device encounters a problem unrelated > > > > > to > > > > > a specific virtqueue request. Reading from this field resets the error > > > > > code to 0, saving the driver an extra configuration space write access > > > > > and possibly race conditions. It isn't possible to implement those > > > > > semantics suing VDUSE_DEV_SET_CONFIG. It's another corner case, but it > > > > > makes me think that the interface does not allow full VIRTIO > > > > > semantics. > > > > > > > > > Note that though you're correct, my understanding is that config space is > > > not suitable for this kind of error propagating. And it would be very hard > > > to implement such kind of semantic in some transports. Virtqueue should > > > be > > > much better. As Yong Ji quoted, the config space is used for > > > "rarely-changing or intialization-time parameters". > > > > > > > > > > Agreed. I will use VDUSE_DEV_GET_CONFIG in the next version. And to > > > > handle the message failure, I'm going to add a return value to > > > > virtio_config_ops.get() and virtio_cread_* API so that the error can > > > > be propagated to the virtio device driver. Then the virtio-blk device > > > > driver can be modified to handle that. > > > > > > > > Jason and Stefan, what do you think of this way? > > > > Why does VDUSE_DEV_GET_CONFIG need to support an error return value? > > > > We add a timeout and return error in case userspace never replies to > the message. > > > The VIRTIO spec provides no way for the device to report errors from > > config space accesses. > > > > The QEMU virtio-pci implementation returns -1 from invalid > > virtio_config_read*() and silently discards virtio_config_write*() > > accesses. > > > > VDUSE can take the same approach with > > VDUSE_DEV_GET_CONFIG/VDUSE_DEV_SET_CONFIG. > > > > I noticed that virtio_config_read*() only returns -1 when we access a > invalid field. But in the VDUSE case, VDUSE_DEV_GET_CONFIG might fail > when we access a valid field. Not sure if it's ok to silently ignore > this kind of error. That's a good point but it's a general VIRTIO issue. Any device implementation (QEMU userspace, hardware vDPA, etc) can fail, so the VIRTIO specification needs to provide a way for the driver to detect this. If userspace violates the contract then VDUSE needs to mark the device broken. QEMU's device emulation does something similar with the vdev->broken flag. The VIRTIO Device Status field DEVICE_NEEDS_RESET bit can be set by vDPA/VDUSE to indicate that the device is not operational and must be reset. The driver code may still process the -1 value read from the configuration space. Hopefully this isn't a problem. There is currently no VIRTIO interface besides DEVICE_NEEDS_RESET to indicate configuration space access failures. On the other hand, drivers need to handle malicious devices so they should be able to cope with the -1 value anyway. Stefan signature.asc Description: PGP signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. Acked-by: Mark Brown signature.asc Description: PGP signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v8 10/10] Documentation: Add documentation for VDUSE
On Tue, Jul 06, 2021 at 10:34:33AM +0800, Jason Wang wrote:
>
> 在 2021/7/5 下午8:49, Stefan Hajnoczi 写道:
> > On Mon, Jul 05, 2021 at 11:36:15AM +0800, Jason Wang wrote:
> > > 在 2021/7/4 下午5:49, Yongji Xie 写道:
> > > > > > OK, I get you now. Since the VIRTIO specification says "Device
> > > > > > configuration space is generally used for rarely-changing or
> > > > > > initialization-time parameters". I assume the VDUSE_DEV_SET_CONFIG
> > > > > > ioctl should not be called frequently.
> > > > > The spec uses MUST and other terms to define the precise requirements.
> > > > > Here the language (especially the word "generally") is weaker and
> > > > > means
> > > > > there may be exceptions.
> > > > >
> > > > > Another type of access that doesn't work with the VDUSE_DEV_SET_CONFIG
> > > > > approach is reads that have side-effects. For example, imagine a field
> > > > > containing an error code if the device encounters a problem unrelated
> > > > > to
> > > > > a specific virtqueue request. Reading from this field resets the error
> > > > > code to 0, saving the driver an extra configuration space write access
> > > > > and possibly race conditions. It isn't possible to implement those
> > > > > semantics suing VDUSE_DEV_SET_CONFIG. It's another corner case, but it
> > > > > makes me think that the interface does not allow full VIRTIO
> > > > > semantics.
> > >
> > > Note that though you're correct, my understanding is that config space is
> > > not suitable for this kind of error propagating. And it would be very hard
> > > to implement such kind of semantic in some transports. Virtqueue should
> > > be
> > > much better. As Yong Ji quoted, the config space is used for
> > > "rarely-changing or intialization-time parameters".
> > >
> > >
> > > > Agreed. I will use VDUSE_DEV_GET_CONFIG in the next version. And to
> > > > handle the message failure, I'm going to add a return value to
> > > > virtio_config_ops.get() and virtio_cread_* API so that the error can
> > > > be propagated to the virtio device driver. Then the virtio-blk device
> > > > driver can be modified to handle that.
> > > >
> > > > Jason and Stefan, what do you think of this way?
> > Why does VDUSE_DEV_GET_CONFIG need to support an error return value?
> >
> > The VIRTIO spec provides no way for the device to report errors from
> > config space accesses.
> >
> > The QEMU virtio-pci implementation returns -1 from invalid
> > virtio_config_read*() and silently discards virtio_config_write*()
> > accesses.
> >
> > VDUSE can take the same approach with
> > VDUSE_DEV_GET_CONFIG/VDUSE_DEV_SET_CONFIG.
> >
> > > I'd like to stick to the current assumption thich get_config won't fail.
> > > That is to say,
> > >
> > > 1) maintain a config in the kernel, make sure the config space read can
> > > always succeed
> > > 2) introduce an ioctl for the vduse usersapce to update the config space.
> > > 3) we can synchronize with the vduse userspace during set_config
> > >
> > > Does this work?
> > I noticed that caching is also allowed by the vhost-user protocol
> > messages (QEMU's docs/interop/vhost-user.rst), but the device doesn't
> > know whether or not caching is in effect. The interface you outlined
> > above requires caching.
> >
> > Is there a reason why the host kernel vDPA code needs to cache the
> > configuration space?
>
>
> Because:
>
> 1) Kernel can not wait forever in get_config(), this is the major difference
> with vhost-user.
virtio_cread() can sleep:
#define virtio_cread(vdev, structname, member, ptr) \
do {\
typeof(((structname*)0)->member) virtio_cread_v;\
\
might_sleep(); \
^^
Which code path cannot sleep?
> 2) Stick to the current assumption that virtio_cread() should always
> succeed.
That can be done by reading -1 (like QEMU does) when the read fails.
Stefan
signature.asc
Description: PGP signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] bus: Make remove callback return void
On Tue, Jul 06, 2021 at 11:50:37AM +0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König Yay! For ARM, Amba and related parts: Acked-by: Russell King (Oracle) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V2 5/6] virtio: add one field into virtio_device for recording if device uses managed irq
On Tue, Jul 06, 2021 at 07:42:03AM +0200, Christoph Hellwig wrote: > On Fri, Jul 02, 2021 at 11:05:54PM +0800, Ming Lei wrote: > > blk-mq needs to know if the device uses managed irq, so add one field > > to virtio_device for recording if device uses managed irq. > > > > If the driver use managed irq, this flag has to be set so it can be > > passed to blk-mq. > > I don't think all this boilerplate code make a whole lot of sense. > I think we need to record this information deep down in the irq code by > setting a flag in struct device only if pci_alloc_irq_vectors_affinity > atually managed to allocate multiple vectors and the PCI_IRQ_AFFINITY > flag was set. Then blk-mq can look at that flag, and also check that > more than one queue is in used and work based on that. How can blk-mq look at that flag? Usually blk-mq doesn't play with physical device(HBA). So far almost all physically properties(segment, max_hw_sectors, ...) are not provided to blk-mq directly, instead by queue limits abstract. Thanks, Ming ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] drm/qxl: Convert to Linux IRQ interfaces
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_irq.c | 9 +
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 31f4c86ceb99..cfd3fbda6df6 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -284,7 +284,6 @@ static struct drm_driver qxl_driver = {
.gem_prime_mmap = qxl_gem_prime_mmap,
.fops = _fops,
.ioctls = qxl_ioctls,
- .irq_handler = qxl_irq_handler,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index dd6abee55f56..717c2d270f04 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -439,7 +439,6 @@ int qxl_gem_prime_mmap(struct drm_gem_object *obj,
/* qxl_irq.c */
int qxl_irq_init(struct qxl_device *qdev);
-irqreturn_t qxl_irq_handler(int irq, void *arg);
void qxl_debugfs_add_files(struct qxl_device *qdev,
struct drm_info_list *files,
diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
index d312322cacd1..665278ee3b6d 100644
--- a/drivers/gpu/drm/qxl/qxl_irq.c
+++ b/drivers/gpu/drm/qxl/qxl_irq.c
@@ -25,11 +25,11 @@
#include
-#include
+#include
#include "qxl_drv.h"
-irqreturn_t qxl_irq_handler(int irq, void *arg)
+static irqreturn_t qxl_irq_handler(int irq, void *arg)
{
struct drm_device *dev = (struct drm_device *) arg;
struct qxl_device *qdev = to_qxl(dev);
@@ -81,7 +81,8 @@ static void qxl_client_monitors_config_work_func(struct
work_struct *work)
int qxl_irq_init(struct qxl_device *qdev)
{
- struct pci_dev *pdev = to_pci_dev(qdev->ddev.dev);
+ struct drm_device *ddev = >ddev;
+ struct pci_dev *pdev = to_pci_dev(ddev->dev);
int ret;
init_waitqueue_head(>display_event);
@@ -95,7 +96,7 @@ int qxl_irq_init(struct qxl_device *qdev)
atomic_set(>irq_received_cursor, 0);
atomic_set(>irq_received_io_cmd, 0);
qdev->irq_received_error = 0;
- ret = drm_irq_install(>ddev, pdev->irq);
+ ret = request_irq(pdev->irq, qxl_irq_handler, IRQF_SHARED,
ddev->driver->name, ddev);
qdev->ram_header->int_mask = QXL_INTERRUPT_MASK;
if (unlikely(ret != 0)) {
DRM_ERROR("Failed installing irq: %d\n", ret);
--
2.32.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
