On 9/6/2015 10:28 AM, Sagi Grimberg wrote:
I just rebased to target-pending for-next and I see
strange behavior in iscsi target (and iser).
So I reverted any patches I had on top but the issue
still persist. I didn't detect what went wrong at the moment
but I figured I send it out.
bisected down to this one:
commit 93f62b0170e34b756e0f16ec9aaf8746f218f6da
Author: Roland Dreier <roland@xxxxxxxxxxxxxxx>
Date: Thu Jul 23 14:53:32 2015 -0700
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@xxxxxxxxxxxxxxx>
Signed-off-by: Spencer Baugh <sbaugh@xxxxxxxxxx>
Signed-off-by: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>
While the patch looks OK, it definitely introduces a regression.
Roland, Spencer, care to have a look?
Thanks,
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
