Project

General

Profile

Bug #7427

Double flock(3C) causes undue block

Added by Robert Mustacchi about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2016-09-27
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

While investigating an issue on LX, I found troubling behavior with flock(2). If this test program is run twice, it will block on the second invocation, waiting to acquire the OFD lock:

#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/file.h>

int main()
{
        int fd;

        fd = open("testlock", O_CREAT|O_TRUNC|O_RDWR, 0644);

        flock(fd, LOCK_EX);
        flock(fd, LOCK_EX);

        exit(0);
}

If the flock(2) isn't performed twice in one run, it works fine. The behavior is the same on both native and LX. On Linux, the second (and subsequent) invocations do not block.

The issue here is that during the lock request flk_relation() replaces the old lock record with a new one constructed as part of the request, and frees the old. The code for freeing nulls out the f_filock field assuming that it points towards the structure being freed. This is not the case if it has been replaced, though. Before nulling out the field, it should first check that the field does indeed point to the record being cleaned up.

Because this field was nulled out, ofdcleanlock() couldn't find any locks to remove while closing all open file descriptors for the exiting process. Explicitly unlocking the file would succeed though because it would actually check the lock graph.

History

#1

Updated by Electric Monk about 3 years ago

  • Status changed from New to Closed

git commit 90221f9148b67fdc90178b67f9600b7bd4e3bc7c

commit  90221f9148b67fdc90178b67f9600b7bd4e3bc7c
Author: Cody Peter Mello <cody.mello@joyent.com>
Date:   2016-10-18T18:10:15.000Z

    7427 Double flock(3C) causes undue block
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: Patrick Mooney <patrick.mooney@joyent.com>
    Reviewed by: Gordon Ross <gordon.w.ross@gmail.com>
    Approved by: Dan McDonald <danmcd@omniti.com>

Also available in: Atom PDF