aboutsummaryrefslogtreecommitdiff
path: root/Documentation/cris
diff options
context:
space:
mode:
authormdr@sgi.com <mdr@sgi.com>2006-05-01 13:07:04 -0500
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>2006-05-10 09:54:42 -0500
commit6dd727da92290193d0f74fa39f3ad53f423524db (patch)
tree156b847c2d65ab8679ab6805256244e5cf80805f /Documentation/cris
parent0b18ac42aa036c7fa217f178aa6a02c66e19e0a1 (diff)
[SCSI] mptfc: race between mptfc_register_dev and mptfc_target_alloc
A race condition exists in mptfc between the thread registering a device with the fc transport and the scan work generated by the transport. This race existed prior to the application of the mptfc bug fix patch. mptfc_register_dev() calls fc_remote_port_add() with the FC_RPORT_ROLE_TARGET bit set in the rport ids passed to the function. Having this bit set causes fc_remote_port_add() to schedule a scan of the device. This scan can execute before mptfc_register_dev() can fill in the dd_data in the rport structure. When this happens, mptfc_target_alloc() will fail because dd_data is null. Attached is a patch which fixes the problem. The patch changes the rport ids passed to fc_remote_port_add() to not have the TARGET bit set. This prevents the scan from being scheduled. After mptfc_register_dev() fills in the rport dd_data field, fc_remote_port_rolechg() is called, changing the role of the rport to TARGET. Thus, the scan is scheduled after dd_data is filled in which prevents the failure in mptfc_target_alloc(). Signed-off-by: Michael Reed <mdr@sgi.com> Signed-off-by: Eric Moore <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'Documentation/cris')
0 files changed, 0 insertions, 0 deletions