On Fri, 2016-01-08 at 09:52 +0100, Bart Van Assche wrote:
> On 01/08/2016 08:15 AM, Nicholas A. Bellinger wrote:
> > @@ -2574,24 +2558,18 @@ static int srpt_cm_req_recv(struct ib_cm_id *cm_id,
> >
> > pr_debug("registering session %s\n", ch->sess_name);
> >
> > - nacl = srpt_lookup_acl(sport, ch->i_port_id);
> > - if (!nacl) {
> > + se_acl = core_tpg_get_initiator_node_acl(&sport->port_tpg_1, ch->sess_name);
> > + if (!se_acl) {
> > pr_info("Rejected login because no ACL has been"
> > " configured yet for initiator %s.\n", ch->sess_name);
> > rej->reason = cpu_to_be32(
> > - SRP_LOGIN_REJ_CHANNEL_LIMIT_REACHED);
> > + SRP_LOGIN_REJ_CHANNEL_LIMIT_REACHED);
> > + transport_free_session(ch->sess);
> > goto destroy_ib;
> > }
> > + ch->sess->se_node_acl = se_acl;
>
> This is a backwards-incompatible change. Today the ib_srpt target driver
> accepts initiator port names with and without leading "0x". With this
> change the "0x" prefix becomes mandatory.
The internally ib_srpt formatted ch->sess_name already needs to match
se_node_acl->initiatorname for se_node_acl->acl_group configfs group
shutdown reference..
How does this patch become a backworks-incompatible change for that..?
>
> > diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.h b/drivers/infiniband/ulp/srpt/ib_srpt.h
> > index 5faad8ac..bb4fbe2 100644
> > --- a/drivers/infiniband/ulp/srpt/ib_srpt.h
> > +++ b/drivers/infiniband/ulp/srpt/ib_srpt.h
> > @@ -364,11 +364,9 @@ struct srpt_port {
> > u16 sm_lid;
> > u16 lid;
> > union ib_gid gid;
> > - spinlock_t port_acl_lock;
> > struct work_struct work;
> > struct se_portal_group port_tpg_1;
> > struct se_wwn port_wwn;
> > - struct list_head port_acl_list;
> > struct srpt_port_attrib port_attrib;
> > };
>
> With this patch applied the following srpt_node_acl members are no
> longer read: i_port_id, sport and list. Hence please remove the
> srpt_node_acl structure definition and use struct se_node_acl instead.
>
Dropping these now.
--
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
