Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7c2f30279da9f1c927ee3141fa14a7c14ca50297.camel@kernel.org>
Subject: Re: [PATCH 3/6] nfsd: simplify the delayed disposal list code
From:   Jeff Layton <jlayton@kernel.org>
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Wed, 18 Jan 2023 14:42:25 -0500
In-Reply-To: <0BDD4ABB-2470-483A-A2F7-C65B84546FB5@oracle.com>
References: <20230118173139.71846-1-jlayton@kernel.org>
         <20230118173139.71846-4-jlayton@kernel.org>
         <0BDD4ABB-2470-483A-A2F7-C65B84546FB5@oracle.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-01-18 at 19:08 +0000, Chuck Lever III wrote:
>=20
> > On Jan 18, 2023, at 12:31 PM, Jeff Layton <jlayton@kernel.org> wrote:
> >=20
> > When queueing a dispose list to the appropriate "freeme" lists, it
> > pointlessly queues the objects one at a time to an intermediate list.
> >=20
> > Remove a few helpers and just open code a list_move to make it more
> > clear and efficient. Better document the resulting functions with
> > kerneldoc comments.
>=20
> I'd like to freeze the filecache code until we've sorted out the
> destroy_deleg_unhashed crashes. Shall I simply maintain 3/6 and
> 4/6 and any subsequent filecache changes (like my rhltable
> rewrite) on a topic branch?
>=20
> One good reason to do that is to enable an eventual fix to be
> backported to stable kernels without also needing to pull in
> intervening clean-up patches.
>=20
> I've already applied a couple small changes that I would rather
> wait on for this reason. I might move those over to the topic
> branch as well... I promise to keep it based on nfsd-next so it
> makes sense to continue developing filecache work on top of the
> topic branch.
>=20
> The other patches in this series are sensible clean-ups that I
> plan to apply for v6.3 if there are no other objections.
>=20

So that means you won't take patches 3 and 4, but the rest are ok?
--=20
Jeff Layton <jlayton@kernel.org>