aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/target/iscsi/iscsi_target_login.c
diff options
context:
space:
mode:
authorRoland Dreier <roland@purestorage.com>2015-07-23 14:53:32 -0700
committerNicholas Bellinger <nab@linux-iscsi.org>2015-08-02 23:11:52 -0700
commit109e2381749c1cfd94a0d22b2b54142539024973 (patch)
tree9695ecd3738a7bad43edcca4eb641339e7a30060 /drivers/target/iscsi/iscsi_target_login.c
parentqla2xxx: Update tcm_qla2xxx module description to 24xx+ (diff)
downloadwireguard-linux-109e2381749c1cfd94a0d22b2b54142539024973.tar.xz
wireguard-linux-109e2381749c1cfd94a0d22b2b54142539024973.zip
target: Drop iSCSI use of mutex around max_cmd_sn increment
In a performance profile, taking a mutex in iscsit_increment_maxcmdsn() shows up very high. However taking a mutex around "sess->max_cmd_sn += 1" seems pretty silly: we're not serializing against other contexts in any useful way. I did a quick audit and there don't appear to be any other places that use max_cmd_sn within the mutex more than once, so this lock can't be providing any useful serialization. (Get correct values for logging - fix whitespace damage) Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Spencer Baugh <sbaugh@catern.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Diffstat (limited to 'drivers/target/iscsi/iscsi_target_login.c')
-rw-r--r--drivers/target/iscsi/iscsi_target_login.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/target/iscsi/iscsi_target_login.c b/drivers/target/iscsi/iscsi_target_login.c
index 3d0fe4ff5590..bd192f88e1e6 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -330,7 +330,7 @@ static int iscsi_login_zero_tsih_s1(
* The FFP CmdSN window values will be allocated from the TPG's
* Initiator Node's ACL once the login has been successfully completed.
*/
- sess->max_cmd_sn = be32_to_cpu(pdu->cmdsn);
+ atomic_set(&sess->max_cmd_sn, be32_to_cpu(pdu->cmdsn));
sess->sess_ops = kzalloc(sizeof(struct iscsi_sess_ops), GFP_KERNEL);
if (!sess->sess_ops) {