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> <CAOcd+r0Ybfr1WszjYc1K19Cf7JmKowy=Go6nc8Fexf5KxNyf=A@mail.gmail.com>
 <20190828165429.GC26284@fieldses.org> <CAOcd+r3e52q_ds3zjya98whYarqoXf5C2umNEX-AGp4-R6=Cuw@mail.gmail.com>
 <20190830195443.GC5053@fieldses.org>
In-Reply-To: <20190830195443.GC5053@fieldses.org>
From:   Alex Lyakas <alex@zadara.com>
Date:   Tue, 3 Sep 2019 16:48:48 +0300
Message-ID: <CAOcd+r0XkLxLPnjBQ_R1pRyreJXkOZ27gJSqVn9c2bs=b792Eg@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,

On Fri, Aug 30, 2019 at 10:54 PM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Thu, Aug 29, 2019 at 09:12:49PM +0300, Alex Lyakas wrote:
> > Would moving this code into the "unlock_filesystem" infrastructure be
> > acceptable? Since the "share_id" approach is very custom for our
> > usage, what criteria would you suggest for selecting the openowners to
> > be "forgotten"?
>
> Have you looked at what unlock_filesystem()?  It's just translating the
> given path to a superblock, then matching that against inodes in
> nlmsvc_match_sb().
>
> It's a little more complicated for nfs4_files since they don't have a
> pointer to the inode. (Maybe it should.)  You can see how I get around
> this in e.g.  fs/nfsd/nfs4state.c:nfs4_show_lock().
>
> A superblock isn't the same thing as an export, thanks to bind mounts
> and subdirectory exports.  But if the goal is to be able to unmount,
> then a superblock is probably what you want.
Thanks for your suggestion.The superblock approach works very well for
us. Initial patch is on its way.

Thanks,
Alex.

>
> --b.