[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] scsi: add block job opblockers

From: Paolo Bonzini
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] scsi: add block job opblockers for scsi-block
Date: Mon, 12 Feb 2018 15:00:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 12/02/2018 14:52, Kevin Wolf wrote:
> Am 08.02.2018 um 11:42 hat Paolo Bonzini geschrieben:
>> On 08/02/2018 02:35, Fam Zheng wrote:
>>> On Wed, 02/07 17:36, Paolo Bonzini wrote:
>>>> @@ -2626,6 +2656,36 @@ static void scsi_block_realize(SCSIDevice *dev, 
>>>> Error **errp)
>>>>      scsi_realize(&s->qdev, errp);
>>>>      scsi_generic_read_device_identification(&s->qdev);
>>>> +
>>>> +    /* For op blockers, due to lack of support for dirty bitmaps.  */
>>>> +    error_setg(&sb->mirror_source,
>>>> +               "scsi-block does not support acting as a mirroring 
>>>> source");
>>>> +    error_setg(&sb->commit_source,
>>>> +               "scsi-block does not support acting as an active commit 
>>>> source");
>>> An alternative way would be adding BLOCK_OP_TYPE_DIRTY_BITMAP. The error 
>>> message
>>> will not be as nice but it can be useful for another (blockjob) operation 
>>> that
>>> requires dirty bitmap support, or another device that doesn't support dirty
>>> bitmaps. Though there isn't one for now.
>> Yeah, I thought about it.  Another possibility is make BLOCK_OP_TYPE_* a
>> bitmask.  Then you can easily add a single Error * for multiple
>> blockers, and BLOCK_OP_TYPE_DIRTY_BITMAP can be defined as
>> notifiers below.
> We shouldn't be adding new instances of BLOCK_OP_* at all. I couldn't
> find the time yet to remove the existing ones, but any new protections
> should be using the permission system.

I agree.  But does this include not fixing bugs wherever clients are
using the old op blockers?


> I propose a new BLK_PERM_BYPASS that allows its users to bypass the
> block layer I/O functions. In other words, bdrv_aio_ioctl() would
> require that you got this permission. A dirty bitmap would keep a
> BdrvChild with perm=0, shared=BLK_PERM_ALL & ~BLK_PERM_BYPASS, so you
> can never have a dirty bitmap and a device using ioctls attached to the
> BDS at the same time.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]