Differences between revisions 2 and 3
Revision 2 as of 2007-04-05 16:28:20
Size: 2310
Editor: ?Eduard Bloch
Comment:
Revision 3 as of 2007-04-05 16:30:30
Size: 2509
Editor: ?Eduard Bloch
Comment:
Deletions are marked like this. Additions are marked like this.
Line 42: Line 42:
   * Permission problems may make the creation of lock files impossible (security issues), especially for self-compiled applications and having no root permissions to install them in a required way

On Locking Schemes on Linux Device Drivers

Hello fellow application developer or maintainer,

recently we (cdrkit and cdrskin developers) came accross increasing problems with reliable and safe device locking. This paper enlightens the issues behind the scenes and presents possible future solutions.

Introduction

Our original concern is the influence of even read-only operations on optical media drives (recorders) during their duty as recorders -- depending on the device model such read-only work may interrupt the process badly practically destroying the medium.

Since many programs already do act on such devices in an unsafe manner, either willingly (e.g. liblkid) or accidentally (e.g. hald, opening with O_EXCL but still clashing with cdr applications working on the competing sg driver), we see the need for reliable communication in order to ensure proper device locking where appropriate, in a way which is appropriate for the particular application. In the following document, first the currently possible mechanisms are itemized with their advantages and their problems, followed by a draft of a locking scheme which shall cope with the particular requirements and which may be implemented in a library shared by our applications later.

State of the practice

There are various locking techniques used in other areas which are more or less applicable in our case.

General inter-process locking mechanisms

  • Lock files associated with target file Principle: an additional file is created during the action on the real target file. Pros: regular filesystem operation, no additional infrastructure required Cons:
    • Possible races unless OS mechanisms are used for exclusive operation on the lock file
    • The location and name of the lock file need to be known and discussed upfront among all application developers, or be documented excessively
    • Permission problems may make the creation of lock files impossible (security issues), especially for self-compiled applications and having no root permissions to install them in a required way

Currently, following mechanisms can be considered:

  • O_EXCL locking
    • Principle: passing of the O_EXCL flag to the open call. The device is locked exclusively for the calling PID, the lock is maintained in the device driver to the particular major/minor combination. Pros:
      • - reliable for a device accessible through one driver
      Cons: