Thanks Alasdair and Neil, Alasdair G Kergon wrote:
Test with trees of devices too - where a whole tree is suspended -
Suspending maps in the tree and reload one of them? I'll try that.
I don't think you can allocate anywhere in dm_swap_table() without PF_MEMALLOC (which I recently removed and am reluctant to reinstate).
I understand your reluctance and I don't want to revive it either. I think moving sysfs_add_link() outside of dm_swap_table() solves this. Am I right? Or do you want to eliminate the possibility that sysfs_remove_symlink() may require memory allocation in future? Anyway, I'll seek for bd_claim based approach.
Have you considered if anything is feasible based around bd_claim()? Doesn't it make more sense for the links to be set up at table load time - i.e. superset of both tables if present?
I think it makes sense. But I have difficulty with it. What I once thought was extending bd_claim() like: bd_claim_with_owner(bdev, void *holder, struct kobject *owner) where "owner" is a kobject for "slaves" directory. We may have the object embedded in gendisk structure. Then we can create symlinks like: /sys/block/<bdev>/holders/<owner> --> /sys/block/<owner> /sys/block/<owner>/slaves/<bdev> --> /sys/block/<bdev> This should work for md. However, dm needs more for its flexibility. Because multiple dm devices can hold one device and one dm device can hold a device twice (i.e. current table and new table), we need to reference-count per relationship basis, not per slave device. This might be solved by allocating management struct in bd_claim() to reference-counting the relationship. I'll try this. Comments are welcome. -- Jun'ichi Nomura, NEC Solutions (America), Inc. -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
