search for: put_dev

On Tue, 5 Dec 2017 19:57:10 +0800 weiping zhang <zhangweiping at didichuxing.com> wrote: > 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 > @pdev->vm_dev.dev.release() too complicated, so...

On Tue, 5 Dec 2017 19:57:10 +0800 weiping zhang <zhangweiping at didichuxing.com> wrote: > 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 > @pdev->vm_dev.dev.release() too complicated, so...

this patchset try to add cleanup for virtio_mmio driver, include virtio_mmio_probe and virtio_mmio_remove weiping zhang (2): virtio_mmio: add cleanup for virtio_mmio_probe virtio_mmio: add cleanup for virtio_mmio_remove drivers/virtio/virtio_mmio.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) -- 2.9.4

this patchset try to add cleanup for virtio_mmio driver, include virtio_mmio_probe and virtio_mmio_remove weiping zhang (2): virtio_mmio: add cleanup for virtio_mmio_probe virtio_mmio: add cleanup for virtio_mmio_remove drivers/virtio/virtio_mmio.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 8 deletions(-) -- 2.9.4

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 @pdev->vm_dev.dev.release() too complicated, so put_device just put the refer...

This series is mainly for testing live migration between 2 vdpa_sim_blk devices. The first patch is preparation and moves the buffer allocation into devices, the second patch adds the `shared_buffer_mutex` parameter to vdpa_sim_blk to use the same ramdisk for all devices. Tested with QEMU v8.0.0-rc2 in this way: modprobe vhost_vdpa modprobe vdpa_sim_blk shared_backend=true vdpa dev add mgmtdev

...om_fork+0x10/0x18 > > > > To fix this, we can simply rip out the explicit cleanup that the devm > > infrastructure will do for us when our probe function returns an error > > code, or when our remove function returns. > > > > We only need to ensure that we call put_device() if a call to > > register_virtio_device() fails in the probe path. > > > > Signed-off-by: Mark Rutland <mark.rutland at arm.com> > > Fixes: 7eb781b1bbb7136f ("virtio_mmio: add cleanup for virtio_mmio_probe") > > Fixes: 25f32223bce5c580 ("virt...

...om_fork+0x10/0x18 > > > > To fix this, we can simply rip out the explicit cleanup that the devm > > infrastructure will do for us when our probe function returns an error > > code, or when our remove function returns. > > > > We only need to ensure that we call put_device() if a call to > > register_virtio_device() fails in the probe path. > > > > Signed-off-by: Mark Rutland <mark.rutland at arm.com> > > Fixes: 7eb781b1bbb7136f ("virtio_mmio: add cleanup for virtio_mmio_probe") > > Fixes: 25f32223bce5c580 ("virt...

Live migration of vdpa would typically require re-instate vdpa device with an idential set of configs on the destination node, same way as how source node created the device in the first place. In order to allow live migration orchestration software to export the initial set of vdpa attributes with which the device was created, it will be useful if the vdpa tool can report the config on demand

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 device mapper & VIRTIO patches. This version has fix for test bot build failure. Keeping all the existing r-o-bs. Jakob CCed also tested the patch series and confirmed the working of v9. --- This patch series has implementation for "virtio pmem". "virtio

Hi Dan, This series has only change in patch 2 for linux-next build failure. There is no functional change. Keeping all the existing review/acks and reposting the patch series for merging via libnvdimm tree. --- This patch series has implementation for "virtio pmem". "virtio pmem" is fake persistent memory(nvdimm) in guest which allows to bypass the guest page

...L); return 0; } diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c index 376e0fd..41af886 100644 --- a/drivers/s390/block/dcssblk.c +++ b/drivers/s390/block/dcssblk.c @@ -655,6 +655,7 @@ dcssblk_add_store(struct device *dev, struct device_attribute *attr, const char goto put_dev; get_device(&dev_info->dev); + /* FIXME: handle error. */ device_add_disk(&dev_info->dev, dev_info->gd, NULL); switch (dev_info->segment_type) { diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c index 6dba6eb..1c7950f 100644 --- a/drivers/s390/bl...

...csi_Host *shost, gfp_t gfp_mask) + { + struct scsi_cmnd *cmd; + +@@ -234,6 +233,7 @@ static struct scsi_cmnd *__scsi_get_comm + + return cmd; + } ++EXPORT_SYMBOL_GPL(__scsi_get_command); + + /* + * Function: scsi_get_command() +@@ -270,9 +270,29 @@ struct scsi_cmnd *scsi_get_command(struc + put_device(&dev->sdev_gendev); + + return cmd; +-} ++} + EXPORT_SYMBOL(scsi_get_command); + ++void __scsi_put_command(struct Scsi_Host *shost, struct scsi_cmnd *cmd, ++ struct device *dev) ++{ ++ unsigned long flags; ++ ++ /* changing locks here, don''t need to restore the irq state...

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create