linux-kernel - Re: [RFC] ib_srpt: initial .40-rc1 drivers/infiniband/ulp/srpt merge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2011 21:18:14 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Roland Dreier <roland@...estorage.com>
Cc:	Bart Van Assche <bvanassche@....org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-rmda <linux-rdma@...r.kernel.org>,
	Vu Pham <vu@...lanox.com>, David Dillow <dillowda@...l.gov>,
	James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [RFC] ib_srpt: initial .40-rc1 drivers/infiniband/ulp/srpt
	merge

On Wed, 2011-05-18 at 12:17 -0700, Roland Dreier wrote:
> On Wed, May 18, 2011 at 11:02 AM, Bart Van Assche <bvanassche@....org> wrote:
> > Thanks for the feedback. I'm still wondering though about the
> > usefulness of disabling / enabling SRPT per HCA port. For the use
> > cases I know about SRP communication over all target ports will be
> > enabled as soon as target configuration has finished and more
> > fine-grained access configuration will occur by allowing/disallowing
> > certain initiators to log in.
> 
> I definitely think that allowing the flexibility to configure ports individually
> is required.  It's easy to imagine a case with a separate front-end and
> back-end networks on the two HCA ports (this would be a pretty normal
> ethernet config), where only one port should be a target port.
> 
> It may not be how people do things now but it should at least be possible.
> 

Hey guys,

Apologies for the slightly delay response here..  Just to clarify on
Bart's point above.  The srpt_port->port_wwn patch in question does
current ensure that sport->enabled has been set via an configfs
attribute at:

   /sys/kernel/config/target/srpt/$IB_PORT_GUID/tpgt_1/enable

and will reject all SRP login attempts to an individual struct srpt_port
until the attribute has been explictly triggered.

This allows ib_srpt to follow what is expected by rtsadmin-v2 +
lio-utils, and used to generate /etc/target/srpt_start.sh used to save
persistent fabric configuration.  Currently other fabrics like
iscsi-target and tcm_qla2xxx expect to be able to reject fabric login
requests before the full set of WWPN endpoints, LUNs, NodeACLs +
MappedLUNs have been recreated during an typical init.d/target start
operation.

I think it makes sense to do the same for the SRPT control plane on an
individual HCA port GUID basis as long as there are no underlying fabric
issues, and that Roland is happy.  In terms of supporting more than one
type of /sys/kernel/config/target/srpt/$WWPN/$TPGT/ layout, I would
really like to avoid this for mainline code unless there is a really
good reason..

Also, I think ib_srpt needs to properly support 'demo-mode' operation
in /var/target/fabric/ib_srpt.spec as this is very useful for testing
and development purposes.  I go ahead and get this added to upstream LIO
v4.1 in the next days and respin for mainline with Hch's review + Bart's
changes.

Thanks folks,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/