search for: toregister_virtio_device

...gister), but this made me look at our error handling if a virtio > device failed to register. > > We hold an extra reference to the struct device, even after a failed > register, and it is the responsibility of the caller to give up that > reference once no longer needed. As callers toregister_virtio_device() > embed the struct virtio_device, it needs to be their responsibility. > Looking at the existing callers, > > - ccw does a put_device > - pci, mmio and remoteproc do nothing, causing a leak > - vop does a free on the embedding structure, which is a big no-no > > Thoughts...

...gister), but this made me look at our error handling if a virtio > device failed to register. > > We hold an extra reference to the struct device, even after a failed > register, and it is the responsibility of the caller to give up that > reference once no longer needed. As callers toregister_virtio_device() > embed the struct virtio_device, it needs to be their responsibility. > Looking at the existing callers, > > - ccw does a put_device > - pci, mmio and remoteproc do nothing, causing a leak > - vop does a free on the embedding structure, which is a big no-no > > Thoughts...

index can be reused by other virtio device. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c index 48230a5..bf7ff39 100644 --- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -333,6 +333,8 @@ int register_virtio_device(struct

index can be reused by other virtio device. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c index 48230a5..bf7ff39 100644 --- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -333,6 +333,8 @@ int register_virtio_device(struct

...index if we failed to register), but this made me look at our error handling if a virtio device failed to register. We hold an extra reference to the struct device, even after a failed register, and it is the responsibility of the caller to give up that reference once no longer needed. As callers toregister_virtio_device() embed the struct virtio_device, it needs to be their responsibility. Looking at the existing callers, - ccw does a put_device - pci, mmio and remoteproc do nothing, causing a leak - vop does a free on the embedding structure, which is a big no-no Thoughts?

...il.com> wrote: > On Wed, Nov 29, 2017 at 10:50:44AM +0100, Cornelia Huck wrote: > > We hold an extra reference to the struct device, even after a failed > > register, and it is the responsibility of the caller to give up that > > reference once no longer needed. As callers toregister_virtio_device() > > embed the struct virtio_device, it needs to be their responsibility. > > Looking at the existing callers, > > > > - ccw does a put_device > > - pci, mmio and remoteproc do nothing, causing a leak > > - vop does a free on the embedding structure, which is a...