similar to: [PATCH v2] virtio-mmio: fix memory leak of vm_dev

On Tue, Sep 05, 2023 at 09:42:28AM +0000, Maximilian Heyne wrote: > With the recent removal of vm_dev from devres its memory is only freed > via the callback virtio_mmio_release_dev. However, this only takes > effect after device_add is called by register_virtio_device. Until then > it's an unmanaged resource and must be explicitly freed on error exit. > > This bug was

On Fri, Sep 08, 2023 at 11:38:40AM +0000, Maximilian Heyne wrote: > On Thu, Sep 07, 2023 at 05:28:25PM +0100, Catalin Marinas wrote: > > On Thu, Sep 07, 2023 at 02:17:16PM +0000, Maximilian Heyne wrote: > > > With the recent removal of vm_dev from devres its memory is only freed > > > via the callback virtio_mmio_release_dev. However, this only takes > > >

On Fri, Sep 08, 2023 at 11:38:40AM +0000, Maximilian Heyne wrote: > On Thu, Sep 07, 2023 at 05:28:25PM +0100, Catalin Marinas wrote: > > On Thu, Sep 07, 2023 at 02:17:16PM +0000, Maximilian Heyne wrote: > > > With the recent removal of vm_dev from devres its memory is only freed > > > via the callback virtio_mmio_release_dev. However, this only takes > > >

On Thu, Sep 07, 2023 at 02:17:16PM +0000, Maximilian Heyne wrote: > With the recent removal of vm_dev from devres its memory is only freed > via the callback virtio_mmio_release_dev. However, this only takes > effect after device_add is called by register_virtio_device. Until then > it's an unmanaged resource and must be explicitly freed on error exit. > > This bug was

On Thu, Sep 07, 2023 at 02:17:16PM +0000, Maximilian Heyne wrote: > With the recent removal of vm_dev from devres its memory is only freed > via the callback virtio_mmio_release_dev. However, this only takes > effect after device_add is called by register_virtio_device. Until then > it's an unmanaged resource and must be explicitly freed on error exit. > > This bug was

On Thu, 29 Jun 2023 14:05:26 +0200, Wolfram Sang <wsa+renesas at sang-engineering.com> wrote: > vm_dev has a separate lifecycle because it has a 'struct device' > embedded. Thus, having a release callback for it is correct. > > Allocating the vm_dev struct with devres totally breaks this protection, device? or driver? And why? > though. Instead of waiting for the

As mentioned at drivers/base/core.c: /* * NOTE: _Never_ directly free @dev after calling this function, even * if it returned an error! Always use put_device() to give up the * reference initialized in this function instead. */ Normal we do cleanup for @vm_dev by contianer_of(@dev), but in this case we need release @mem resource from @pdev and vm_dev->base. It make

cleanup all resource allocated by virtio_mmio_probe. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_mmio.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c index 74dc717..3fd0e66 100644 --- a/drivers/virtio/virtio_mmio.c +++

cleanup all resource allocated by virtio_mmio_probe. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_mmio.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c index 74dc717..3fd0e66 100644 --- a/drivers/virtio/virtio_mmio.c +++

As mentioned at drivers/base/core.c: /* * NOTE: _Never_ directly free @dev after calling this function, even * if it returned an error! Always use put_device() to give up the * reference initialized in this function instead. */ so we don't free vm_dev until vm_dev.dev.release be called. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_mmio.c

On Tue, 12 Dec 2017 12:53:02 +0000 Mark Rutland <mark.rutland at arm.com> wrote: > Recent rework of the virtio_mmio probe path balanced a devm_ioremap() > with an iounmap() rather than its devm variant. This ends up corrupting > the devm datastructures, and results in the following boot failure on > arm64 under QEMU 2.9.0: > > [ 3.450397] ------------[ cut here

2017-12-12 21:45 GMT+08:00 Mark Rutland <mark.rutland at arm.com>: > Recent rework of the virtio_mmio probe/remove paths balanced a > devm_ioremap() with an iounmap() rather than its devm variant. This ends > up corrupting the devm datastructures, and results in the following > boot-time splat on arm64 under QEMU 2.9.0: > > [ 3.450397] ------------[ cut here

Recent rework of the virtio_mmio probe path balanced a devm_ioremap() with an iounmap() rather than its devm variant. This ends up corrupting the devm datastructures, and results in the following boot failure on arm64 under QEMU 2.9.0: [ 3.450397] ------------[ cut here ]------------ [ 3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844) [ 3.460534] WARNING: CPU: 1 PID: 1

Recent rework of the virtio_mmio probe path balanced a devm_ioremap() with an iounmap() rather than its devm variant. This ends up corrupting the devm datastructures, and results in the following boot failure on arm64 under QEMU 2.9.0: [ 3.450397] ------------[ cut here ]------------ [ 3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844) [ 3.460534] WARNING: CPU: 1 PID: 1

On Sat, 2 Dec 2017 01:51:40 +0800 weiping zhang <zwp10758 at gmail.com> wrote: > cleanup all resource allocated by virtio_mmio_probe. > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- > drivers/virtio/virtio_mmio.c | 34 ++++++++++++++++++++++++++-------- > 1 file changed, 26 insertions(+), 8 deletions(-) > > diff --git

From: Li Liu <john.liuli at huawei.com> Add a new register offset VIRTIO_MMIO_ISRMEM which help to estblish a shared memory region between virtio-mmio driver and qemu with two purposes: 1.Guest virtio-mmio driver can get the interrupt reason. 2.Check irqfd enabled or not to register different irq handler. Signed-off-by: Li Liu <john.liuli at huawei.com> ---

Recent rework of the virtio_mmio probe/remove paths balanced a devm_ioremap() with an iounmap() rather than its devm variant. This ends up corrupting the devm datastructures, and results in the following boot-time splat on arm64 under QEMU 2.9.0: [ 3.450397] ------------[ cut here ]------------ [ 3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844) [ 3.460534] WARNING: CPU:

Recent rework of the virtio_mmio probe/remove paths balanced a devm_ioremap() with an iounmap() rather than its devm variant. This ends up corrupting the devm datastructures, and results in the following boot-time splat on arm64 under QEMU 2.9.0: [ 3.450397] ------------[ cut here ]------------ [ 3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844) [ 3.460534] WARNING: CPU:

On Sat, Oct 25, 2014 at 04:24:53PM +0800, john.liuli wrote: > From: Li Liu <john.liuli at huawei.com> > > Add a new register offset VIRTIO_MMIO_ISRMEM which help to > estblish a shared memory region between virtio-mmio driver > and qemu with two purposes: > > 1.Guest virtio-mmio driver can get the interrupt reason. > 2.Check irqfd enabled or not to register

Use devm_platform_ioremap_resource() to simplify code, which contains platform_get_resource, devm_request_mem_region and devm_ioremap. Signed-off-by: Yangtao Li <tiny.windzz at gmail.com> --- drivers/virtio/virtio_mmio.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c index