similar to: [PATCH] virtio-mmio: don't break lifecycle of vm_dev

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 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, 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 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 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 > > >

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

Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas at sang-engineering.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c index

On 5/3/2024 11:13 AM, Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" > with more appropriate terms. Inspired by and following on to Wolfram's > series to fix drivers/i2c/[1], fix the terminology for users of > I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > in the specification. >

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 Tue, May 7, 2024 at 2:32?PM Easwar Hariharan <eahariha at linux.microsoft.com> wrote: > > On 5/3/2024 11:13 AM, Easwar Hariharan wrote: > > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" > > with more appropriate terms. Inspired by and following on to Wolfram's > > series to fix drivers/i2c/[1], fix the terminology for

On 5/8/2024 7:53 AM, Alex Deucher wrote: > On Tue, May 7, 2024 at 2:32?PM Easwar Hariharan > <eahariha at linux.microsoft.com> wrote: >> >> On 5/3/2024 11:13 AM, Easwar Hariharan wrote: >>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" >>> with more appropriate terms. Inspired by and following on to Wolfram's

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

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

We are deprecating calls which return NULL in favor of new variants which return an ERR_PTR. Only build tested. Wolfram Sang (6): drm/amdgpu: convert to use i2c_new_client_device() drm/gma500: convert to use i2c_new_client_device() drm/i2c/sil164: convert to use i2c_new_client_device() drm/i2c/tda998x: convert to use i2c_new_client_device() drm/nouveau/therm: convert to use

On 2016?11?25? 10:47, Yuan Liu wrote: > 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). I see, thanks. Reviewed-by: Jason Wang <jasowang at redhat.com> > > On Thu, Nov 24, 2016 at

On Tue, Dec 12, 2017 at 10:26:24PM +0800, weiping zhang wrote: > 2017-12-12 21:45 GMT+08:00 Mark Rutland <mark.rutland at arm.com>: > Hi Mark, Hi, > thanks your patch, I dig into these three devm_xxx funciton, > all of them represented by a struct devres as following, > > struct devres_node { > struct list_head entry; > dr_release_t