[PATCH] resctrl: Do not open directory for writing

Martin Kletzander mkletzan at redhat.com
Fri Jul 10 19:03:15 UTC 2020

On Fri, Jul 10, 2020 at 04:00:13PM +0200, Michal Privoznik wrote:
>On 7/10/20 3:39 PM, Andrea Bolognani wrote:
>> On Fri, 2020-07-10 at 15:13 +0200, Martin Kletzander wrote:
>>> On Fri, Jul 10, 2020 at 10:47:22AM +0200, Michal Privoznik wrote:
>>>> On 7/9/20 6:30 PM, Andrea Bolognani wrote:
>>>>> This is all bikeshedding, of course: what actually matters is making
>>>>> that lock exclusive once again :)
>>>> Just realized that for exclusive (aka write) lock, the FD must be opened
>>>> for writing (working on patches for the following report [1] and been
>>>> experimenting a bit and that's what I'm seeing).
>>> Good point, but luckily not related to flock(2).
>> That seems to be the case: according to flock(2),
>>    A shared or exclusive lock can be placed on a file regardless
>>    of the mode in which the file was opened.
>> Michal, does that sound reasonable to you?
>D'oh! of course this is another case of file locking exemptions. The
>patches I sent earlier today fix code around virFileLock() which is
>fcntl() which is POSIX locking. flock(2) is BSD lock which may or may
>not be implementedusing POSIX locks.
>So I think we're okay on that front.
>Alternatively, we may switch to OFD (F_OFD_SETLK from fcntl(2)) and
>experience proper file locking. Those are Linux only (but so is resctrl).

Unfortunately it is not stated anywhere that it would have to stay Linux-only
and moreover the kernel recommendation is to use flock(2) which means there are
other applications that will use flock(2) which means we cannot really switch to
any other lock unless guaranteed that it is mutually exclusive with the current
one.  But it would be nice ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200710/916feee1/attachment-0001.sig>

More information about the libvir-list mailing list