On Mon, 2012-02-27 at 09:47 -0800, Roland Dreier wrote: > On Mon, Feb 27, 2012 at 4:12 AM, Nicholas A. Bellinger > <nab@xxxxxxxxxxxxxxx> wrote: > > This series is a WIP for adding se_session->sess_kref into target core to > > address a long standing set of issues wrt to active session shutdown and > > explict NodeACL group configuration. > > > > This includes changing iscsi-target to co-exist with internal reference > > counting, and converting qla2xxx internal qla_tgt_sess->sess_kref to use > > se_session->sess_kref for all cases. It also re-factors qla_tgt_sess > > shutdown -> release code to run outside of qla_hw_data->hardware_lock + > > interrupt execution using system_wq process context. > > > > So far the changes have been tested with normal session creation/deletion > > for iscsi-target, loopback, tcm_fc(fcoe) and qla2xxx WWPNs, but need > > more testing with active I/O shutdown. Please have a look.. > > I was thinking about this stuff over the weekend, and I'm starting to wonder > if the core notion of "session" is a good match for the way qla2xxx uses it. > > Recall that qla2xxx creates a "global" session when firmware tells it about > an initiator logging in, and a "local" session when it gets a command from > someone that it doesn't have a global session for yet. > > [The creation of local sessions is obviously racy if multiple commands > come in before any session is created, but that's not the main point > here] > > In any case, if we tear down the TCM session structure when we remove > ACLs for an initiator talking to qla2xxx, that doesn't log the initiator out > on the FC side, and it doesn't stop the initiator from continuing to send > commands (and triggering creation of a new local session). > As per current generate_node_acls=1 usage, the session is restarted after explict NodeACL removal and only has access to read-only LUN=0 RAMDISK_MCP. > For qla2xxx at least, ACLs are really about which LUNs an initiator sees. > Even if an initiator has no LUNs mapped to it, it can still do a PLOGI into > us etc. In brief I guess I wonder if tcm_qla2xxx sessions should be more > like tcm_loop sessions, instead of trying to act like iSCSI. (and maybe > we need to make the core stuff more generic, and leave the iSCSI > semantics in the iSCSI fabric module...) > I'm not sure what you mean here wrt to tcm_loop, as sessions are generated from a configfs attribute and mapped 1:1 with target endpoints. Any more thoughts here..? > I should probably read the tcm_fc code and see what it does too... > tcm_fc currently uses it's own session referencing that can be converted to se_sess->sess_kref usage without too much effort. --nab -- 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
