Re: [Qemu-block] [PATCH v8 00/36] block: Image locking series

[Max Reitz]

On 25.10.2016 16:57, Kevin Wolf wrote:
> Am 25.10.2016 um 15:30 hat Max Reitz geschrieben:
>> On 25.10.2016 10:24, Kevin Wolf wrote:
>>> Am 24.10.2016 um 20:03 hat Max Reitz geschrieben:
>>>> On 24.10.2016 12:11, Kevin Wolf wrote:
>>>>
>>>> [...]
>>>>
>>>>> Now, the big question is how to translate this into file locking. This
>>>>> could become a little tricky. I had a few thoughts involving another
>>>>> lock on byte 2, but none of them actually worked out so far, because
>>>>> what we want is essentially a lock that can be shared by readers, that
>>>>> can also be shared by writers, but not by readers and writers at the
>>>>> same time.
>>>>
>>>> You can also share it between readers and writers, as long as everyone
>>>> can cope with volatile data.
>>>
>>> Sorry, that was ambiguous. I meant a file-level lock rather than the
>>> high-level one. If we had a lock that can be shared by one or the other,
>>> but not both, then two locks would be enough to build what we really
>>> want.
>>>
>>>> I agree that it's very similar to the proposed op blocker style, but I
>>>> can't really come up with a meaningful translation either.
>>>>
>>>> Maybe something like this (?): All readers who do not want the file to
>>>> be modified grab a shared lock on byte 1. All writers who can deal with
>>>> volatile data grab a shared lock on byte 2. Exclusive writers grab an
>>>> exclusive lock on byte 1 and 2. Readers who can cope with volatile data
>>>> get no lock at all.
>>>>
>>>> When opening, the first and second group would always have to test
>>>> whether there is a lock on the other byte, respectively. E.g. sharing
>>>> writers would first grab an exclusive lock on byte 1, then the shared
>>>> lock on byte 2 and then release the exclusive lock again.
>>>>
>>>> Would that work?
>>>
>>> I'm afraid it wouldn't. If you start the sharing writer first and then
>>> the writer-blocking reader, the writer doesn't hold a lock on byte 1 any
>>> more,
>>
>> But it holds a lock on byte 2.
>>
>>>       so the reader can start even though someone is writing to the
>>> image.
>>
>> It can't because it would try to grab an exclusive lock on byte 2 before
>> grabbing the shared lock on byte 1.
> 
> Apparently I failed to understand the most important part of the
> proposal. :-)
> 
> So we have two locks. Both are only held for a longer time in shared
> mode. Exclusive mode is only used for testing whether the lock is being
> held and is immediately given up again.
> 
> The meaning of holding a shared lock is:
> 
>     byte 1: I can't allow other processes to write to the image
>     byte 2: I am writing to the image
> 
> The four cases that we have involve:
> 
> * shared writer: Take shared lock on byte 2. Test whether byte 1 is
>   locked using an exclusive lock, and fail if so.

To not be racy, I'd first take the exclusive lock, then the shared lock,
and then release the exclusive lock.

> * exclusive writer: Take shared lock on byte 2. Test whether byte 1 is
>   locked using an exclusive lock, and fail if so. Then take shared lock
>   on byte 1. I suppose this is racy, but we can probably tolerate that.

Well, if you want to have the explicit meanings you gave to two bytes...
Otherwise, you'd just take an exclusive lock on both bytes.

Or you'd start out as a reader that can't tolerate writers (i.e. take
exclusive lock on byte 2, take shared lock on byte 1, release exclusive
lock on byte 2) and then try to upgrade it to be an exclusive writer by
taking an exclusive lock on byte 2 and then downgrading it to a shared lock.

Of course, you can optimize this sequence to: Take exclusive lock on
byte 2, take shared lock on byte 1, downgrade exclusive lock to shared lock.

Max

> * reader that can tolerate writers: Don't do anything
> 
> * reader that can't tolerate writers: Take shared lock on byte 1. Test
>   whether byte 2 is locked, and fail if so.
> 
> Seems to work if I got that right.
> 
> Kevin
>

signature.asc
Description: OpenPGP digital signature