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

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 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 Thu, 7 Sep 2023 14:17:16 +0000, Maximilian Heyne <mheyne at amazon.de> 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. >

On Thu, 7 Sep 2023 14:17:16 +0000, Maximilian Heyne <mheyne at amazon.de> 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. >

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

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

pmd_present() is expected to test positive after pmdp_mknotpresent() as the PMD entry still points to a valid huge page in memory. pmdp_mknotpresent() implies that given PMD entry is just invalidated from MMU perspective while still holding on to pmd_page() referred valid huge page thus also clearing pmd_present() test. This creates the following situation which is counter intuitive.

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

This series renames pmd_mknotpresent() as pmd_mkinvalid(). Before that it drops an existing pmd_mknotpresent() definition from powerpc platform which was never required as it defines it's pmdp_invalidate() through subscribing __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. This rename was suggested by Catalin during a previous discussion while we were trying to change

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

This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it drops an existing pmd_mknotpresent() definition from powerpc platform which was never required as it defines it's pmdp_invalidate() through subscribing __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. This rename was suggested by Catalin during a previous discussion while we were trying to

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:

flight 18753 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18753/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-win7-amd64 8 guest-saverestore fail REGR. vs. 18750 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail

On arm64 the dma_map_ops implementation is based on the swiotlb. swiotlb-xen, used by default in dom0 on Xen, is also based on the swiotlb. Avoid calling into the default arm64 dma_map_ops functions from xen_dma_map_page, xen_dma_unmap_page, xen_dma_sync_single_for_cpu, and xen_dma_sync_single_for_device otherwise we end up calling into the swiotlb twice. When arm64 gets a non-swiotlb based

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

I think not. In virtio_pci_common, vp_dev is allocated by kzalloc so a kfree is needed. Here vm_dev is allocated by devm_kmalloc which is "automatically freed on driver detach" from the comment (drivers/base/devres.c:769). On Thu, Nov 24, 2016 at 6:37 PM, Jason Wang <jasowang at redhat.com> wrote: > > > On 2016?11?24? 08:31, Yuan Liu wrote: > >> From: Yuan Liu

I think not. In virtio_pci_common, vp_dev is allocated by kzalloc so a kfree is needed. Here vm_dev is allocated by devm_kmalloc which is "automatically freed on driver detach" from the comment (drivers/base/devres.c:769). On Thu, Nov 24, 2016 at 6:37 PM, Jason Wang <jasowang at redhat.com> wrote: > > > On 2016?11?24? 08:31, Yuan Liu wrote: > >> From: Yuan Liu

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