search for: devm_kmalloc

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 <liuyuan at google.com>...

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 <liuyuan at google.com>...

...size_t size; > #endif > > }; > > struct devres { > struct devres_node node; > /* -- 3 pointers */ > unsigned long long data[]; /* guarantee ull alignment */ > }; > 2) devm_kzalloc -> devm_kmalloc > > dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev)); > "devm_kmalloc_release" is noop, do nothing. Please note that the release function is there to perform cleanup prior to the devm infrastructure releasing the memory. The devm_kmalloc_release function is a n...

...size_t size; > #endif > > }; > > struct devres { > struct devres_node node; > /* -- 3 pointers */ > unsigned long long data[]; /* guarantee ull alignment */ > }; > 2) devm_kzalloc -> devm_kmalloc > > dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev)); > "devm_kmalloc_release" is noop, do nothing. Please note that the release function is there to perform cleanup prior to the devm infrastructure releasing the memory. The devm_kmalloc_release function is a n...

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 6:37 PM, Jason Wang <jasowang at redhat.com > <mailto:jasowang at...

From: Yuan Liu <liuyuan at google.com> Fix a warning thrown from virtio_mmio_remove(): Device 'virtio0' does not have a release() function The fix is according to virtio_pci_probe() of drivers/virtio/virtio_pci_common.c Signed-off-by: Yuan Liu <liuyuan at google.com> --- drivers/virtio/virtio_mmio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

From: Yuan Liu <liuyuan at google.com> Fix a warning thrown from virtio_mmio_remove(): Device 'virtio0' does not have a release() function The fix is according to virtio_pci_probe() of drivers/virtio/virtio_pci_common.c Signed-off-by: Yuan Liu <liuyuan at google.com> --- drivers/virtio/virtio_mmio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

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:

...nsigned long long data[]; /* guarantee ull alignment */ }; 1) devm_request_mem_region -> __devm_request_region dr = devres_alloc(devm_region_release, sizeof(struct region_devres), "devm_region_release" will call __release_region to release resource 2) devm_kzalloc -> devm_kmalloc dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev)); "devm_kmalloc_release" is noop, do nothing. 3) devm_ioremap -> ... -> __devres_alloc_node ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL); devm_ioremap_release do iounmap so for case 2) above, w...

...fig, tag), > + &tag_buf, sizeof(tag_buf)); > + end = memchr(tag_buf, '\0', sizeof(tag_buf)); > + if (end == tag_buf) > + return -EINVAL; /* empty tag */ > + if (!end) > + end = &tag_buf[sizeof(tag_buf)]; > + > + len = end - tag_buf; > + fs->tag = devm_kmalloc(&vdev->dev, len + 1, GFP_KERNEL); > + if (!fs->tag) > + return -ENOMEM; > + memcpy(fs->tag, tag_buf, len); > + fs->tag[len] = '\0'; > + return 0; > +} > + > +/* Work function for hiprio completion */ > +static void virtio_fs_hiprio_done_work(struc...

...fig, tag), > + &tag_buf, sizeof(tag_buf)); > + end = memchr(tag_buf, '\0', sizeof(tag_buf)); > + if (end == tag_buf) > + return -EINVAL; /* empty tag */ > + if (!end) > + end = &tag_buf[sizeof(tag_buf)]; > + > + len = end - tag_buf; > + fs->tag = devm_kmalloc(&vdev->dev, len + 1, GFP_KERNEL); > + if (!fs->tag) > + return -ENOMEM; > + memcpy(fs->tag, tag_buf, len); > + fs->tag[len] = '\0'; > + return 0; > +} > + > +/* Work function for hiprio completion */ > +static void virtio_fs_hiprio_done_work(struc...

...fig, tag), > + &tag_buf, sizeof(tag_buf)); > + end = memchr(tag_buf, '\0', sizeof(tag_buf)); > + if (end == tag_buf) > + return -EINVAL; /* empty tag */ > + if (!end) > + end = &tag_buf[sizeof(tag_buf)]; > + > + len = end - tag_buf; > + fs->tag = devm_kmalloc(&vdev->dev, len + 1, GFP_KERNEL); > + if (!fs->tag) > + return -ENOMEM; > + memcpy(fs->tag, tag_buf, len); > + fs->tag[len] = '\0'; > + return 0; > +} > + > +/* Work function for hiprio completion */ > +static void virtio_fs_hiprio_done_work(struc...

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is marked as an RFC because firstly it depends on the RPMsg API series and secondly it is currently being reviewed on ALSA and SOF mailing lists, but any early comments from virtualisation developers would be highly appreciated too! Thanks Guennadi [1]

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is marked as an RFC because firstly it depends on the RPMsg API series and secondly it is currently being reviewed on ALSA and SOF mailing lists, but any early comments from virtualisation developers would be highly appreciated too! Thanks Guennadi [1]