On 10/20/2015 07:15 PM, Joel Becker wrote:
On Tue, Oct 20, 2015 at 02:32:32PM +0200, Andrzej Pietrasiewicz wrote:From: Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx> This change is necessary for the SCSI target usb gadget composed with configfs. In this case configfs will be used for two different purposes: to compose a usb gadget and to configure the target part. If an instance of tcm function is created in $CONFIGFS_ROOT/usb_gadget/<gadget>/functions a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget/<wwn>/, but after a tpg is created the tcm function must not be removed until its corresponding tpg is gone. While the configfs_depend/undepend_item() are meant exactly for creating this kind of dependencies, they are not suitable if the other kernel subsystem happens to be another subsystem in configfs, so this patch adds unlocked versions meant for configfs callbacks. Signed-off-by: Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx> [updated the commit log] Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@xxxxxxxxxxx> --- fs/configfs/dir.c | 29 +++++++++++++++++++++++++++++ include/linux/configfs.h | 9 +++++++++ 2 files changed, 38 insertions(+) diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c index c81ce7f..1e1ae76 100644 --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -1152,6 +1152,35 @@ void configfs_undepend_item(struct configfs_subsystem *subsys, } EXPORT_SYMBOL(configfs_undepend_item); +int configfs_depend_item_unlocked(struct config_item *target) +{ + struct configfs_dirent *sd; + int ret = -ENOENT; + + spin_lock(&configfs_dirent_lock); + BUG_ON(!target->ci_dentry); + + sd = target->ci_dentry->d_fsdata; + if ((sd->s_type & CONFIGFS_DIR) && + ((sd->s_type & CONFIGFS_USET_DROPPING) || + (sd->s_type & CONFIGFS_USET_CREATING))) + goto out_unlock_dirent_lock; + + sd->s_dependent_count += 1; + ret = 0; + +out_unlock_dirent_lock: + spin_unlock(&configfs_dirent_lock); + return ret; +} +EXPORT_SYMBOL(configfs_depend_item_unlocked);
Sorry for some delay but I wrote this patch almost half a year ago and I needed some time to get back into configfs internals to respond you in a way that makes any sense;)
This version lacks configfs_depend_prep(); how do you guard against parents being in the middle of removal? It's not just this entry being DROPPING, it's also parents.
Well, that's true. I didn't think about scenario in which Andrzej used this patch (two different subsystems) I was thinking only about scenario with one subsystem and dependences only between entities created by user so they are always a root of sub tree which is being removed. But as I see now it was wrong assumption as this may be called for any arbitrary config item and from different subsystem, so this needs to be fixed. Unfortunately to make this working in both situations (caller and target in the same subsystem or different) this method has to be more complex. I will send a patch with updated version shortly.
I also worry about the lack of pinning the fs. I think that might be OK, because your source already has a hold on the fs, but I'm not 100% sure.
In my opinion we don't have to pin the fs as those functions should be called only from configfs callbacks and that's what I wrote in documentation:) as a result we may be called only if configfs is in a proper state. But of course I'm not a fs expert and if anyone knows something more about this it please correct me if I'm wrong.
Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
