Displaying 6 results from an estimated 6 matches for "cache_type_show".
2020 Apr 30
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...hing else must hold this mutex when accessing vdev and must
> > + * handle the case where vdev is NULL after virtblk_remove() has been
> > + * called.
> > + */
> > + struct mutex vdev_mutex;
>
> The patch LGTM, I'm just worried about cache_type_store() and
> cache_type_show() because IIUC they aren't in blk-mq and virtqueue code
> paths, but they use vdev.
>
> Do we have to take the mutex there too?
No, because del_gendisk() in virtblk_remove() deletes the sysfs
attributes before vblk->vdev is set to NULL. kernfs deactivates the
kernfs nodes so that...
2020 Apr 30
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...hing else must hold this mutex when accessing vdev and must
> > + * handle the case where vdev is NULL after virtblk_remove() has been
> > + * called.
> > + */
> > + struct mutex vdev_mutex;
>
> The patch LGTM, I'm just worried about cache_type_store() and
> cache_type_show() because IIUC they aren't in blk-mq and virtqueue code
> paths, but they use vdev.
>
> Do we have to take the mutex there too?
No, because del_gendisk() in virtblk_remove() deletes the sysfs
attributes before vblk->vdev is set to NULL. kernfs deactivates the
kernfs nodes so that...
2020 Apr 30
0
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...accessing vdev and must
> > > + * handle the case where vdev is NULL after virtblk_remove() has been
> > > + * called.
> > > + */
> > > + struct mutex vdev_mutex;
> >
> > The patch LGTM, I'm just worried about cache_type_store() and
> > cache_type_show() because IIUC they aren't in blk-mq and virtqueue code
> > paths, but they use vdev.
> >
> > Do we have to take the mutex there too?
>
> No, because del_gendisk() in virtblk_remove() deletes the sysfs
> attributes before vblk->vdev is set to NULL. kernfs deacti...
2020 Apr 29
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
A userspace process holding a file descriptor to a virtio_blk device can
still invoke block_device_operations after hot unplug. This leads to a
use-after-free accessing vblk->vdev in virtblk_getgeo() when
ioctl(HDIO_GETGEO) is invoked:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90
2020 Apr 29
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
A userspace process holding a file descriptor to a virtio_blk device can
still invoke block_device_operations after hot unplug. This leads to a
use-after-free accessing vblk->vdev in virtblk_getgeo() when
ioctl(HDIO_GETGEO) is invoked:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90
2020 Apr 30
0
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...s freed.
> + *
> + * Everything else must hold this mutex when accessing vdev and must
> + * handle the case where vdev is NULL after virtblk_remove() has been
> + * called.
> + */
> + struct mutex vdev_mutex;
The patch LGTM, I'm just worried about cache_type_store() and
cache_type_show() because IIUC they aren't in blk-mq and virtqueue code
paths, but they use vdev.
Do we have to take the mutex there too?
Thanks,
Stefano
> struct virtio_device *vdev;
>
> /* The disk structure for the kernel. */
> @@ -44,6 +54,13 @@ struct virtio_blk {
> /* Process co...