dual scan thread bug fix
authorJames Bottomley <JBottomley@Parallels.com>
Tue, 21 Jan 2014 15:01:41 +0000 (07:01 -0800)
committerBen Hutchings <ben@decadent.org.uk>
Fri, 11 Jul 2014 12:33:56 +0000 (13:33 +0100)
commitf935bf46b0748d78d5d8c9725312aee3443f19d0
tree71cbc8ea5c4677208b040dfb0f3ad8e7de4dfae0
parent181086c6cc8a186f26bbb87872e48bb7973fdc28
dual scan thread bug fix

commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.

In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it.  In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.

Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.

Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
drivers/scsi/scsi_scan.c