bd_holder

bd_holder

[Christian Brauner]

I've been looking into reducing sb_lock and replacing it mostly with a
new file_system_type->fs_super_lock which would be a
per-file-system-type spinlock protecting fs_type->fs_supers.

With the changes in vfs.super bd_holder always stores the super_block
and so we should be able to get rid of get_super() and user_get_super()
completely. Am I right in this or is there something that would prevent
us from doing something like the following (completely untested sketch)?:

struct super_block *get_super(struct block_device *bdev)
{
        struct super_block *sb;

        if (!bdev)
                return NULL;

        spin_lock(&sb_lock);

        sb = bdev->bd_holder;
        if (!sb)
                goto out_unlock;

        if (hlist_unhashed(&sb->s_instances))
                goto out_unlock;

        sb->s_count++;
        spin_unlock(&sb_lock);
        down_read(&sb->s_umount);
        /* still alive? */
        if (sb->s_root && (sb->s_flags & SB_BORN))
                return sb;
        up_read(&sb->s_umount);
        /* nope, got unmounted */
        spin_lock(&sb_lock);
        __put_super(sb);

out_unlock:
        spin_unlock(&sb_lock);
        return NULL;
}

instead of looping through super_blocks? The only thing that irritates
me is the restart logic in the current helpers.

Re: bd_holder

[Christoph Hellwig]

On Mon, Aug 07, 2023 at 11:28:54AM +0200, Christian Brauner wrote:
> I've been looking into reducing sb_lock and replacing it mostly with a
> new file_system_type->fs_super_lock which would be a
> per-file-system-type spinlock protecting fs_type->fs_supers.
> 
> With the changes in vfs.super bd_holder always stores the super_block
> and so we should be able to get rid of get_super() and user_get_super()
> completely. Am I right in this or is there something that would prevent
> us from doing something like the following (completely untested sketch)?:

I have a series killing get_super, and it looks pretty similar to what
you've proposed.  I'm completely under water right now but I hope can
get it into a good enough shape to post it later today or tomorrow.

user_get_super OTOH can't go away.  It's only used in two legacy APIs
where it must only work for the device in s_dev.  It's not performance
critical and we could use other lookup schemes.

get_active_super can go away, but with Darrick having queued up work
in this area it'll have to wait for next merge window.