[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 08/14/2014 10:53 AM, Juergen Gross wrote:
Nicholas,

just one more question (see below):

On 08/12/2014 11:13 PM, Nicholas A. Bellinger wrote:
Hi Juergen & Co,

Finally had a chance to review this code.  Comments are inline below..

On Fri, 2014-08-08 at 09:49 +0200, jgross@xxxxxxxx wrote:

...

+    if (IS_ERR(tv_nexus->tvn_se_sess)) {
+        mutex_unlock(&tpg->tv_tpg_mutex);
+        kfree(tv_nexus);
+        return -ENOMEM;
+    }
+    se_sess = tv_nexus->tvn_se_sess;
+    /*
+     * Since we are running in 'demo mode' this call with generate a
+     * struct se_node_acl for the scsiback struct se_portal_group with
+     * the SCSI Initiator port name of the passed configfs group
'name'.
+     */
+    tv_nexus->tvn_se_sess->se_node_acl =
core_tpg_check_initiator_node_acl(
+                se_tpg, (unsigned char *)name);
+    if (!tv_nexus->tvn_se_sess->se_node_acl) {
+        mutex_unlock(&tpg->tv_tpg_mutex);
+        pr_debug("core_tpg_check_initiator_node_acl() failed for %s\n",
+             name);
+        goto out;
+    }

Can I drop the call to core_tpg_check_initiator_node_acl() as well?
Keeping it will result in failing to setup the nexus (which is to be
expected IMHO).

Obviously I can't. transport_lookup_cmd_lun() calls right at start
spin_lock_irqsave(&se_sess->se_node_acl->device_list_lock, flags);
resulting in a page fault...

I guess the hint to just throw away all the node_acl related stuff has
to be adjusted somehow...

So: what is needed, what can be removed?


Juergen

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.