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 ;-)
signature.asc
Description: PGP signature
