Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1566406146-7887-1-git-send-email-alex@zadara.com>
 <CAOcd+r0bXefi79dnwrwsDN1OecScfTjc8DYS5_9A8D5XKrh7QQ@mail.gmail.com>
 <20190826133951.GC22759@fieldses.org> <CAOcd+r059fh7J8T=6MdjPSCP39K5fpOZTsXZDUKq5TrPv_RcVQ@mail.gmail.com>
 <20190827205158.GB13198@fieldses.org>
In-Reply-To: <20190827205158.GB13198@fieldses.org>
From:   Alex Lyakas <alex@zadara.com>
Date:   Wed, 28 Aug 2019 18:20:22 +0300
Message-ID: <CAOcd+r0Ybfr1WszjYc1K19Cf7JmKowy=Go6nc8Fexf5KxNyf=A@mail.gmail.com>
Subject: Re: [RFC-PATCH] nfsd: when unhashing openowners, increment
 openowner's refcount
To:     "J. Bruce Fields" <bfields@fieldses.org>
Cc:     chuck.lever@oracle.com, linux-nfs@vger.kernel.org,
        Shyam Kaushik <shyam@zadara.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

Hi Bruce,

Thanks for the clarifications.

On Tue, Aug 27, 2019 at 11:51 PM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Tue, Aug 27, 2019 at 12:05:28PM +0300, Alex Lyakas wrote:
> > Is the described issue familiar to you?
>
> Yep, got it, but I haven't seen anyone try to solve it using the fault
> injection code, that's interesting!
>
> There's also fs/nfsd/unlock_filesystem.  It only unlocks NLM (NFSv3)
> locks.  But it'd probably be reasonable to teach it to get NFSv4 state
> too (locks, opens, delegations, and layouts).
>
> But my feeling's always been that the cleanest way to do it is to create
> two containers with separate net namespaces and run nfsd in both of
> them.  You can start and stop the servers in the different containers
> independently.

I am looking at the code, and currently nfsd creates a single
namespace subsystem in init_nfsd. All nfs4_clients run in this
subsystem.

So the proposal is to use register_pernet_subsys() for every
filesystem that is exported? I presume that current nfsd code cannot
do this, and some rework is required to move away from a single
subsystem to per-export subsystem. Also, grepping through kernel code,
I see that namespace subsystems are created by different modules as
part of module initialization, rather than doing that dynamically.
Furthermore, in our case the same nfsd machine S can export tens or
even hundreds of local filesystems.Is this fine to have hundreds of
subsystems?

Otherwise, I understand that the current behavior is a "won't fix",
and it is expected for the client machine to unmount the export before
un-exporting the file system at nfsd machine. Is this correct?

Thanks,
Alex.


>
> > It is very easily reproducible. What is the way to solve it? To our
> > understanding, if we un-export a FS from nfsd, we should be able to
> > unmount it.
>
> Unexporting has never removed locks or opens or other state, for what
> it's worth.
>
> --b.