Differences between revisions 3 and 6 (spanning 3 versions)
Revision 3 as of 2007-04-05 16:30:30
Size: 2509
Editor: ?Eduard Bloch
Comment:
Revision 6 as of 2007-04-05 17:03:50
Size: 5234
Editor: ?Eduard Bloch
Comment:
Deletions are marked like this. Additions are marked like this.
Line 33: Line 33:
In general, all the mechanisms listed below are not optimally appropriate for our purpose. They lack on two places which make then not reliable when used alone:

 * they do not cope with multiple device file which imply the access to the same driver through different files
 * they do not automatically cope with multiple device '''drivers''' accessible through '''different''' user space interfaces, like with sg vs. sr drivers on Linux. No matter how many excuses some kernel developers do present to paper over this obvious shortcomings. Automatic use of /dev/sr instead of /dev/sg is not always possible or may not be wanted by the user.

Finally, they may be sufficient to lower the risk on inappropriate operation. Which exactly are available in the wild?
Line 40: Line 47:
  * 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
  * Possible races unless OS mechanisms are used for exclusive operation on the lock file, see below
  * 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 disallow the creation of lock files (security issues), especially for self-compiled applications and having no root permissions to install them in a required way
Line 44: Line 51:
Currently, following mechanisms can be considered:  * fcntl(2) exclusive file locking

 Principle: lock applied on open file handles. Internally associated with a path, see fcntl(2) for details.
 
 Pros:

  * known (POSIX.1-2001), usually reliable mechanism

 Cons:

  * diverges from flock() implementation on Linux, see below. Results in independent locking.
  * possible problems on network file systems

 * flock(2) exclusive file locking

 Principle: similar to fcntl locks, applied with a different system function.

 Pros: see fcntl(2) locking above

 Cons: see fcntl(2) locking above
  
==== Advanced Linux-specific locking mechanisms ====
Line 52: Line 80:
   Pros:
    - reliable for a device accessible through one driver
   Cons:
 Pros:
  * reliable for a device accessible through one driver
 
 Cons:
  * requires kernel 2.6.x (x>=7 or so)
  * does not automagicaly make the device inaccessible, only applications using O_EXCL will know about the locked state when getting negative result with EBUSY errno value.

=== Applicability on CD/(HD)DVD/BD drives ===

As explained in the introduction, the locking is important on optical media recording due to the delicate operation mode during the recording. Ideally, no application should touch them, even reading from the media is an evil task. But how does the state of the practice look like?

 * mount: the block device is mounted with the O_EXCL flag '''BUT''' the mount executable also uses '''libblkid''' which opens the devices without locking and read magic data from it. This also provides no solution for operation through the sg driver.
 
 * hald (HAL daemon): periodically opens the cdrom block devices with O_EXCL flag. Clashes with operation on sg is possible.

 * wodim: opens the devices with O_EXCL flag. Opening /dev/sg is possible and happens more likely with versions prior to 1.1.4.

 * cdrskin: opens the devices with O_EXCL flag. Opening of /dev/sg is prevented by creation of bus/target/lun table and mapping the request to /dev/sr with it, even when dev=/dev/sgX is specified.

 * cdrecord: no proper locking at all. Author recommends to get rid of applications which may touch the device somehow.

 

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

In general, all the mechanisms listed below are not optimally appropriate for our purpose. They lack on two places which make then not reliable when used alone:

  • they do not cope with multiple device file which imply the access to the same driver through different files
  • they do not automatically cope with multiple device drivers accessible through different user space interfaces, like with sg vs. sr drivers on Linux. No matter how many excuses some kernel developers do present to paper over this obvious shortcomings. Automatic use of /dev/sr instead of /dev/sg is not always possible or may not be wanted by the user.

Finally, they may be sufficient to lower the risk on inappropriate operation. Which exactly are available in the wild?

  • 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, see below
    • 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 disallow the creation of lock files (security issues), especially for self-compiled applications and having no root permissions to install them in a required way
  • fcntl(2) exclusive file locking Principle: lock applied on open file handles. Internally associated with a path, see fcntl(2) for details. Pros:
    • known (POSIX.1-2001), usually reliable mechanism
    Cons:
    • diverges from flock() implementation on Linux, see below. Results in independent locking.
    • possible problems on network file systems
  • flock(2) exclusive file locking Principle: similar to fcntl locks, applied with a different system function. Pros: see fcntl(2) locking above Cons: see fcntl(2) locking above

Advanced Linux-specific locking mechanisms

  • 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:
    • requires kernel 2.6.x (x>=7 or so)

    • does not automagicaly make the device inaccessible, only applications using O_EXCL will know about the locked state when getting negative result with EBUSY errno value.

Applicability on CD/(HD)DVD/BD drives

As explained in the introduction, the locking is important on optical media recording due to the delicate operation mode during the recording. Ideally, no application should touch them, even reading from the media is an evil task. But how does the state of the practice look like?

  • mount: the block device is mounted with the O_EXCL flag BUT the mount executable also uses libblkid which opens the devices without locking and read magic data from it. This also provides no solution for operation through the sg driver.

  • hald (HAL daemon): periodically opens the cdrom block devices with O_EXCL flag. Clashes with operation on sg is possible.
  • wodim: opens the devices with O_EXCL flag. Opening /dev/sg is possible and happens more likely with versions prior to 1.1.4.
  • cdrskin: opens the devices with O_EXCL flag. Opening of /dev/sg is prevented by creation of bus/target/lun table and mapping the request to /dev/sr with it, even when dev=/dev/sgX is specified.
  • cdrecord: no proper locking at all. Author recommends to get rid of applications which may touch the device somehow.