From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:53063 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752244AbcD2C0c (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 28 Apr 2016 22:26:32 -0400
Date: Fri, 29 Apr 2016 03:26:28 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: linux-fsdevel@vger.kernel.org,
	Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: Re: [PoC 2/7] Add kobject to super_block
Message-ID: <20160429022628.GX25498@ZenIV.linux.org.uk>
References: <1461895282-4941-1-git-send-email-rgoldwyn@suse.de>
 <1461895282-4941-3-git-send-email-rgoldwyn@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1461895282-4941-3-git-send-email-rgoldwyn@suse.de>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Apr 28, 2016 at 09:01:17PM -0500, Goldwyn Rodrigues wrote:
> @@ -167,7 +204,8 @@ static void destroy_super(struct super_block *s)
>  	WARN_ON(!list_empty(&s->s_mounts));
>  	kfree(s->s_subtype);
>  	kfree(s->s_options);
> -	call_rcu(&s->rcu, destroy_super_rcu);
> +	if (s->s_type->fs_flags & FS_CREATE_SYSFS)
> +		kobject_del(&s->s_kobj);

So we have kobject_del() under a spinlock.  Wonderful...  Better yet,
you have the sodding kobjects sitting around well past the point when
the filesystem driver has gone through rmmod.

sysfs: lifetime rules made simple.  So simple that they don't fit a lot of
situations, but hey - it sure *looks* easy to use...

NAK.  If you want a description of super_block life cycle, I can describe it
to you.  But please, don't play with it until you understand it.