On Mon, 2015-04-06 at 23:17 -0700, Christoph Hellwig wrote: > On Thu, Apr 02, 2015 at 01:57:10PM -0700, Nicholas A. Bellinger wrote: > > > mempools are for I/O path that make guaranteed progress. While the > > > callers of core_enable_device_list_for_node are in the control path, > > > and not in a very deep callstack, fairly shallow below the configfs > > > interface. This is not a use case for mempools, as there is no need > > > to guarantee progress in deep I/O callstacks. > > > > > > > I was more concerned about the creation of se_dev_entry for dynamically > > generated se_node_acl in the login path. > > > > Having to back out everything upon se_dev_entry allocation failure is > > annoying. > > But unless you specificly pre-create the number of entries that > core_dev_add_lun may create that's the only way to handle it. mempool > rely on the fact the objects get freed to the mempool again to make > forward progress, which isn't the case for a lon-lived se_dev_entry > allocation. > --
Point taken. Dropping the extra mempool_t usage for this case. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
