On Wed, 2014-08-13 at 09:02 +0200, Juergen Gross wrote:
> On 08/12/2014 11:13 PM, Nicholas A. Bellinger wrote:
<SNIP>
> >
> >> +
> >> +static int scsiback_port_link(struct se_portal_group *se_tpg,
> >> + struct se_lun *lun)
> >> +{
> >> + struct scsiback_tpg *tpg = container_of(se_tpg,
> >> + struct scsiback_tpg, se_tpg);
> >> +
> >> + mutex_lock(&scsiback_mutex);
> >> +
> >> + mutex_lock(&tpg->tv_tpg_mutex);
> >> + tpg->tv_tpg_port_count++;
> >> + mutex_unlock(&tpg->tv_tpg_mutex);
> >> +
> >> + mutex_unlock(&scsiback_mutex);
> >> +
> >> + return 0;
> >> +}
> >> +
> >
> > AFAICT, no need to hold scsiback_mutex while incrementing
> > tpg->tv_tpg_port_count.
>
> So there is a guarantee that port_link and port_unlink are never
> called in parallel?
>
Correct. configfs_symlink() only calls create_link() once
type->ct_item_ops->allow_link() -> target_fabric_port_link() ->
TFO->fabric_post_link() has successfully completed, effectively
preventing configfs_unlink() + subsequent TFO->fabric_pre_unlink()
execution until after configfs_symlink() completes.
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
