Displaying 20 results from an estimated 1100 matches similar to: "[PATCH 4/4] virtio_blk: Rename a jump label in virtblk_get_id()"
2016 Oct 03
1
[PATCH 4/4] virtio_blk: Rename a jump label in virtblk_get_id()
On Tue, Sep 13, 2016 at 1:15 PM, SF Markus Elfring
<elfring at users.sourceforge.net> wrote:
> From: Markus Elfring <elfring at users.sourceforge.net>
> Date: Tue, 13 Sep 2016 13:50:56 +0200
>
> Adjust a jump label according to the current Linux coding style convention.
I think you mean "goto label". "Jump label" has a different meaning,
see
2016 Oct 03
1
[PATCH 4/4] virtio_blk: Rename a jump label in virtblk_get_id()
On Tue, Sep 13, 2016 at 1:15 PM, SF Markus Elfring
<elfring at users.sourceforge.net> wrote:
> From: Markus Elfring <elfring at users.sourceforge.net>
> Date: Tue, 13 Sep 2016 13:50:56 +0200
>
> Adjust a jump label according to the current Linux coding style convention.
I think you mean "goto label". "Jump label" has a different meaning,
see
2009 Sep 29
0
[PATCH 3/4] virtio_blk: implement a request-based ID command, VIRTIO_BLK_T_GET_ID
This is fairly simple: we create a request pointing at the 1k kmalloc,
then just change the type so our do_req() knows to mark it as a GET_ID
for the server.
Seems to work here; the only issue is that the error didn't get passed
back from __blk_end_request_all to blk_execute_rq, so we set ->errors
to 1 on error.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
Cc: Jens Axboe
2009 Sep 29
0
[PATCH 3/4] virtio_blk: implement a request-based ID command, VIRTIO_BLK_T_GET_ID
This is fairly simple: we create a request pointing at the 1k kmalloc,
then just change the type so our do_req() knows to mark it as a GET_ID
for the server.
Seems to work here; the only issue is that the error didn't get passed
back from __blk_end_request_all to blk_execute_rq, so we set ->errors
to 1 on error.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
Cc: Jens Axboe
2010 Jun 18
4
[PATCH 1/2] Add 'serial' attribute to virtio-blk devices
Create a new attribute for virtio-blk devices that will fetch the serial number
of the block device. This attribute can be used by udev to create disk/by-id
symlinks for devices that don't have a UUID (filesystem) associated with them.
ATA_IDENTIFY strings are special in that they can be up to 20 chars long
and aren't required to be NULL-terminated. The buffer is also zero-padded
2010 Jun 18
4
[PATCH 1/2] Add 'serial' attribute to virtio-blk devices
Create a new attribute for virtio-blk devices that will fetch the serial number
of the block device. This attribute can be used by udev to create disk/by-id
symlinks for devices that don't have a UUID (filesystem) associated with them.
ATA_IDENTIFY strings are special in that they can be up to 20 chars long
and aren't required to be NULL-terminated. The buffer is also zero-padded
2016 Oct 03
0
[PATCH 3/4] virtio_blk: Delete an unnecessary initialisation in init_vq()
On Tue, Sep 13, 2016 at 1:14 PM, SF Markus Elfring
<elfring at users.sourceforge.net> wrote:
> From: Markus Elfring <elfring at users.sourceforge.net>
> Date: Tue, 13 Sep 2016 13:43:50 +0200
>
> The local variable "err" will be set to an appropriate value
> by a following statement.
> Thus omit the explicit initialisation at the beginning.
>
>
2016 Oct 03
0
[PATCH 3/4] virtio_blk: Delete an unnecessary initialisation in init_vq()
On Tue, Sep 13, 2016 at 1:14 PM, SF Markus Elfring
<elfring at users.sourceforge.net> wrote:
> From: Markus Elfring <elfring at users.sourceforge.net>
> Date: Tue, 13 Sep 2016 13:43:50 +0200
>
> The local variable "err" will be set to an appropriate value
> by a following statement.
> Thus omit the explicit initialisation at the beginning.
>
>
2020 May 04
0
[PATCH v4] virtio-blk: handle block_device_operations callbacks after hot unplug
On Thu, 30 Apr 2020 15:04:42 +0100
Stefan Hajnoczi <stefanha at redhat.com> wrote:
> 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
2020 Apr 28
0
[PATCH v2] virtio-blk: handle block_device_operations callbacks after hot unplug
On Tue, Apr 28, 2020 at 03:30:09PM +0100, Stefan Hajnoczi wrote:
> A userspace process holding a file descriptor to a virtio_blk device can
> still invoke block_device_operations after hot unplug. For example, a
> program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot
> unplug to invoke virtblk_getgeo().
which causes what? a use after free?
>
> Introduce a
2020 Apr 30
0
[PATCH v3] virtio-blk: handle block_device_operations callbacks after hot unplug
On Wed, Apr 29, 2020 at 05:53:45PM +0100, Stefan Hajnoczi wrote:
> 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
2020 May 14
0
[PATCH AUTOSEL 5.6 32/62] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 May 14
0
[PATCH AUTOSEL 4.19 22/31] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 May 14
0
[PATCH AUTOSEL 4.14 31/39] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 May 14
0
[PATCH AUTOSEL 5.4 29/49] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 Apr 28
1
[PATCH v2] virtio-blk: handle block_device_operations callbacks after hot unplug
On Tue, Apr 28, 2020 at 11:25:07AM -0400, Michael S. Tsirkin wrote:
> On Tue, Apr 28, 2020 at 03:30:09PM +0100, Stefan Hajnoczi wrote:
> > A userspace process holding a file descriptor to a virtio_blk device can
> > still invoke block_device_operations after hot unplug. For example, a
> > program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot
> > unplug to
2020 Apr 30
3
[PATCH v4] 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
3
[PATCH v4] 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 28
2
[PATCH v2] 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. For example, a
program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot
unplug to invoke virtblk_getgeo().
Introduce a reference count in struct virtio_blk so that its lifetime
covers both virtio_driver probe/remove and block_device_operations
open/release
2020 Apr 28
2
[PATCH v2] 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. For example, a
program that has /dev/vdb open can call ioctl(HDIO_GETGEO) after hot
unplug to invoke virtblk_getgeo().
Introduce a reference count in struct virtio_blk so that its lifetime
covers both virtio_driver probe/remove and block_device_operations
open/release