The lk 3.12.0-rc series contained four patches against the
sg driver from Vaughan Cao introduced by this post:
    [PATCH v7 0/4][SCSI] sg: fix race condition in sg_open
    http://marc.info/?l=linux-scsi&m=137774159020002&w=2

Doubt was thrown on the implementation by Madper Xie in
this thread:
    [Bug] 12.864681  BUG: lock held when returning to user space!
    http://marc.info/?l=linux-kernel&m=138121455020314&w=2

There was a second bug report. A patch from me (that needed to
be revised) was judged to be too late in the lk 3.12 rc cycle
to be accepted. Hence Vaughan's patch is queued to be reverted.
That means the sg driver will remain unchanged for at least
three releases: 3.10, 3.11 and 3.12

The patch presented here targets the lk 3.13 merge window
and is functionally equivalent to Vaughan's four part patch
with my revised patch on top.

Testing:
   In the sg3_utils package (version 1.37) examples directory
   there are the sg_tst_excl2 and sg_tst_excl3 ** programs.
   They use multiple threads to bombard the sg driver (or bsg
   or the block layer) with open calls varying the O_EXCL and
   O_NONBLOCK flags. Writer threads check for an even number
   then do a double increment on a given LBA; reader threads
   just read that LBA and check it is even. If the integer
   (4 bytes at the beginning of the LB) starts even, then it
   should remain even, if O_EXCL is doing its job properly.

** sg_tst_excl3 came after version 1.37 was released and is
    in the News section here: http://sg.danny.cz/sg

ChangeLog:
   - introduce a finer grain (per device) lock to protect
     access and changes to the file descriptor objects
   - introduce a semaphore for mutual exclusion of co-incident
     open and release calls to the same device
   - improve the O_EXCL handling of sg_open() when multiple
     callers are waiting for an O_EXCL condition to clear
   - change some seq_printf()s to seq_puts()s as requested
     by checkpatch.pl
   - update copyright notice, version number and date


Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>