more unpleasant bugs in ipathfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 32E1700B9017364D9B60AED9960492BC211C9165@FMSMSX107.amr.corp.intel.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20131114203313.GI13318-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org
Quoted 8 lines
Fair warning: debugfs suffers the same problems - its use for any dynamic objects will require the same kind of protection against IO after the underlying object goes away. As I said, we really need generic revoke infrastructure; as it is, procfs and sysfs have it special-cased and everything else pretty much ad-hoc. Some things manage to do it right, some do not and since debugfs is greatly oversold as easy solution to all problems... pretty much all of its users are badly broken whenever you have objects with non-static lifetime.
So how about this general approach:
1. Move all ipathfs handling to debugfs.
2. Input on dynamic objects referencing dd/ibd increment a refcount (inited to zero) in the "start" method
3. The "end" method decrements the ref count
The entrance in debugfs to do the recursive remove waits for refcount to drive to zero.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html