Avoid that checkpatch v3.18 reports the following warning for these
two macros:
WARNING: Macros with flow control statements should be avoided
This patch does not change any functionality.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5985 d57e44dd-8a1f-0410-8b47-8ef2f437770f
scsi_setup_cmnd() sets sc_data_direction to DMA_TO_DEVICE for bidirectional
commands. Hence test SCpnt->request->next_rq instead of sc_data_direction
to figure out whether or not a command is bidirectional.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5984 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Changes in this patch:
- Rework the SCSI pass-through code such that for kernel versions
>= 2.6.30 the scst_exec_req_fifo patch is no longer needed.
- Modify the pass-through code such that blk_rq_append_bio() is only
called for kernel version 2.6.30. For later kernel versions
blk_make_request() is called instead.
- Rework scst_scsi_exec_async().
- Add debug tracing of SCSI pass-through result status.
- Add a lockdep_assert_held() call in scsi_end_async().
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5979 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This patch has been tested on a koji build server and also on four
different RPM-based distributions (CentOS 7, Fedora 20, openSuSE 13.2
and SLES 11 SP3).
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5974 d57e44dd-8a1f-0410-8b47-8ef2f437770f
The QLogic firmware and qla2xxx do not register for RSCNs in
target-only mode, so do that explicitly.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5966 d57e44dd-8a1f-0410-8b47-8ef2f437770f
There seems to be a bug in passing sense information to QLA HBAs, where
the last 2 bytes of the sense data (ASC, ASCQ) are not copied to the low
level sense buffer.
We encountered this in ESX, which relies on these 2 bytes to parse the
MISCOMPARE sense code (0xE1, 0x1D, 0x00).
Bellow is a simple test to recreate this issue, but during vMotion
operations (where VMs are moved from one host to another), this may
cause the operation to fail leaving the VM in an inconsistent state.
The test I ran to verify that we are indeed missing the bytes is the
following:
1. Create a SCST based device
2. Expose the device to 2 ESX hosts
3. Format the device as VMFS5, create a test directory
4. From both hosts, I start writing to this directory (no VMs involved,
just write normal files)
At this stage, both ESX hosts try to take access to the directory.
The VMFS filesystem contains a per-directory lock which is managed by
COMPARE AND WRITE command.
Each ESX will attempt to change the VMFS lock location from unlocked to
locked to create the new file.
Obviously there are bound to be failures (which are equivalent to
programming locking conflicts), these are reported by the MISCOMPARE
sense code.
Upon these MISCOMPARE errors, the host will re-try taking the lock until
it succeeds, and will then proceed to perform the write operation on the
directory.
Due to the bug in copying the sense buffer from the SCST core to the QLA
ctio, instead of the full sense code, only the key (0xE) is sent, and
ESX does not know how to handle it resulting in IO error.
Here are the errors as they appear on the command line:
/vmfs/volumes/54a297c4-ca5af1cc-7f94-002219d20f28/ats_test #
./open_close_test-esx2.sh
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_1.txt: Input/output error
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_21.txt: Input/output error
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_110.txt: Input/output error
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_111.txt: Input/output error
In the /var/log/vmkernel.log, we can see that the sense information is
missing (0xE, 0x0, 0x0) instead of (0xE, 0x1D, 0x0).
2014-12-30T12:13:20.714Z cpu6:33519)ScsiDeviceIO: 2338:
Cmd(0x412e84f957c0) 0x89, CmdSN 0x234d from world 519051 to dev
"eui.0024f400d5020007" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x0 0x0.
2014-12-30T12:13:20.766Z cpu6:33519)ScsiDeviceIO: 2338:
Cmd(0x412e84f91d00) 0x89, CmdSN 0x2350 from world 519051 to dev
"eui.0024f400d5020007" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x0 0x0.
2014-12-30T12:13:20.766Z cpu6:33519)ScsiDeviceIO: 2338:
Cmd(0x412e80449fc0) 0x89, CmdSN 0x234f from world 519051 to dev
"eui.0024f400d5020007" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x0 0x0.
This patch fixes this issue, the test will run without a problem with the
fix (no IO errors, all the files are properly written to the directory).
Signed-off-by: Shahar Salzman <shahar.salzman@kaminario.com>
Reviewed-by: Eran Mann <eran.mann@kaminario.com>
[bvanassche: simplified implementation]
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5965 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Persistent reservation commands need thread context because
scst_pr_is_cmd_allowed() locks the PR mutex. Reservation commands
either need BH or thread context. Hence switch from atomic to
thread context before processing such commands.
Reported-by: Shahar Salzman <shahar.salzman@kaminario.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5963 d57e44dd-8a1f-0410-8b47-8ef2f437770f
vfs_read() and vfs_write() ignore the file offset set by llseek().
Hence remove the llseek() calls that occur just before vfs_read() and
vfs_write(). See also the implementation in the Linux kernel of the
pread64() and pwrite64() system calls for examples of code that uses
vfs_read() and vfs_write().
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5942 d57e44dd-8a1f-0410-8b47-8ef2f437770f
