<aggressive snip - we're all using threaded mailreaders, right?> On 08/06/2014 05:22 PM, Jerome Martin wrote:
But I feel that even though the scenario above might be not so problematic, maybe even contrived, there might be other cases we haven't though about yet leading to the same class of problem. And BTW, I do realize that targetcli could request the global lock only when performing an actual configfs write, instead of holding it for the lifetime of a session. But given the very imperative nature of 2.x targetcli, this means that an admin could start a series of changes that only make sense if they are run to completion, and then fail to acquire the lock again because meanwhile some script acquired the lock and decided to hold it forever. And in some cases, 10 minutes might feel like forever. Imagine a session where the admin needs to set login + password + ACL. Depending on the order he does it and when he gets cut out, this might become a problem.
I currently favor the big-configfs-lock/quick-release (BCL) style over fine-grained/release-whenever style. As you rightly point out, all apps including targetcli would need to only hold the BCL across all accesses in a single command or operation, not their entire running time. As for the last part of the hypothetical above, all I can say is that script is buggy, and could be killed by the admin, which would drop the lock and allow everyone else to proceed again.
-- Andy -- 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
