Re: [Xen-devel] [PATCH V4 3/4] Introduce XEN scsiback module

["Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel