This is v2 of a patch presented a few days ago: http://marc.info/?l=linux-scsi&m=138282446708844&w=2 Vaughan Cao's patch is still in lk 3.12-rc7 but it is assumed that it will be reverted before lk 3.12 release. Further testing raised some issues when the device was removed (detached) while being bombarded with open()s. There is also a move to favour non O_EXCL open()s more strongly. Rationale: important SCSI commands like INQUIRY and REPORT LUNS should be answered promptly. They do not need and should not use open(dev, O_EXCL) to access the pass-through. Only commands that write to the device or change its state that might conflict with other users of the device doing something similar should used open(dev, O_EXCL). ChangeLog v2: - favour non O_EXCL open()s over open(dev, O_EXCL)s - wake all open(dev)s if dev is removed (detached) - wake all read(dev_fd)s that are waiting for a response if dev is removed (detached) - other cleanups requested by checkpatch.pl ChangeLog v1: - 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 Testing: sg_tst_excl, sg_tst_excl2 and sg_tst_excl3 in the examples directory of sg3_utils-1.38 beta 1 (see News section of http://sg.danny.cz/sg ) have been refined to test the strength of O_EXCL and related mechanisms. Here is a typical test, each run on separate terminals at the same time: sg_tst_excl -f -t 100 -n 2000 /dev/sg4 sg_tst_excl2 -f -b -t 100 -n 2000 /dev/sg4 sg_tst_excl2 -f -t 100 -n 2000 /dev/sg4 sg_tst_excl3 -f -R -x -t 100 -n 2000 /dev/sg4 See usage messages ('-h') for the meaning of those options. The last one (reader with no O_EXCL opens()s) runs much faster than the first three. It is important that /dev/sg4 is either a scsi_debug device or a disk that you don't mind overwriting LBA 1000. Signed-off-by: Douglas Gilbert