On 05/26/2015 08:25 AM, Nicholas A. Bellinger wrote: > From: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx> > > Hi all, > > Here is -v3 series for converting LIO target se_node_acl + se_lun > mapping tables from fixed size arrays to dynamic RCU hlist_heads. > > This turns fast-path I/O into a lock-less RCU reader using existing > percpu based se_lun->lun_ref logic, and converts the RCU updater > path to allow for an arbitrary number of LUNs for both types of > mappings within target-core. > > As per this afternoon's email thread, the se_dev_entry->pr_comp > has been left in place for se_dev_entry shutdown within patch #1. > This completion is still required in order to prevent the configfs > se_lun_acl->se_lun_group from being removed from out below the > core_scsi3_lunacl_depend_item() caller during the special-case PR > ALL_TG_PT=1 registration handling. > > The changes based on -v2 series feedback from HCH & Co include: > > - Remove unused se_dev_entry->se_node_acl > - Drop unnecessary check in lunacl_undepend_item > - target: Drop bogus mutex_unlock in core_disable_device_list_for_node > - Drop left-over se_lun->lun_status > - target: Rename ->pr_regs to ->deve_flags + add bit definitions > - target: Convert se_dev_entry stats to atomic_long_t > - Avoid unnecessary PR target_nacl_find_deve() lookup in registration > - Add se_lun->lun_index for RCU dev->dev_index usage in stat.c > - Add various rcu_dereference and lockless_dereference RCU notation > > Please review. > > --nab > For the whole series: Reviewed-by: Hannes Reinecke <hare@xxxxxxx> Do you have a git tree for these changes? As mentioned earlier, it should be fairly trivial to convert LIO target to use 64-bit LUNs with this patchset. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
