On 4/12/23 17:11, Greg KH wrote: > On Wed, Apr 12, 2023 at 05:04:16PM +0900, Damien Le Moal wrote: >> On 4/12/23 12:19, Yangtao Li wrote: >>> kobject_put() actually covers kobject removal automatically, which is >>> single stage removal. So kill kobject_del() directly. >>> >>> Signed-off-by: Yangtao Li <frank.li@xxxxxxxx> >>> --- >>> fs/zonefs/sysfs.c | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/fs/zonefs/sysfs.c b/fs/zonefs/sysfs.c >>> index 8ccb65c2b419..a535bdea1097 100644 >>> --- a/fs/zonefs/sysfs.c >>> +++ b/fs/zonefs/sysfs.c >>> @@ -113,7 +113,6 @@ void zonefs_sysfs_unregister(struct super_block *sb) >>> if (!sbi || !sbi->s_sysfs_registered) >>> return; >>> >>> - kobject_del(&sbi->s_kobj); >>> kobject_put(&sbi->s_kobj); >>> wait_for_completion(&sbi->s_kobj_unregister); >>> } >> >> What I am not sure about here is that if CONFIG_DEBUG_KOBJECT_RELEASE is >> enabled, the kobj release is delayed, so the kobject will stay in sysfs >> potentially after the umount() returns. Not exactly nice as that potentially >> create races in user space... Not 100% sure though. >> >> Greg ? Any thoughts on this ? > > Yes, it's all a mess :( > > See the other messatges in this thread: > https://lore.kernel.org/r/20230406120716.80980-1-frank.li@xxxxxxxx > > Please don't take this patch for now, this all needs to be revisited. > > We have two reference counted objects with different lifespans trying to > be embedded in the same structure, causing a mess. > > But, if we split them apart, that too has issues. I've been thinking > about how to resolve this, but don't have any solid ideas yet, and been > swamped with other things... > > For now, let's just leave this all alone, it's not unique to this one > filesystem, they all have the same pattern, and we need to solve them > all properly at the same time by moving the common code into the driver > core so that filesystems don't have to worry about this mess. That was my thinking. Will try to think about a solution as well. Likely, some helpers for FSes sysfs attributes somewhere in fs/*.c are needed to not use the kobj directly as part of the fs_info structs.
