Displaying 7 results from an estimated 7 matches for "cache_type_store".
2020 Apr 30
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...; + *
> > + * 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?
No, because del_gendisk() in virtblk_remove() deletes the sysfs
attributes before vblk->vdev is set to NULL. kernfs deactivat...
2020 Apr 30
2
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...; + *
> > + * 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?
No, because del_gendisk() in virtblk_remove() deletes the sysfs
attributes before vblk->vdev is set to NULL. kernfs deactivat...
2020 Apr 30
0
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
...ng 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->vde...
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
...before vdev
> + * is 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...
2020 Sep 01
10
remove revalidate_disk()
Hi Jens,
this series removes the revalidate_disk() function, which has been a
really odd duck in the last years. The prime reason why most people
use it is because it propagates a size change from the gendisk to
the block_device structure. But it also calls into the rather ill
defined ->revalidate_disk method which is rather useless for the
callers. So this adds a new helper to just