Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Message-ID: <1c79ea86a5e813ac24f57f04dab48766570c3f35.camel@kernel.org>
Subject: Re: [PATCH 0/6 v2] support admin-revocation of v4 state
From:   Jeff Layton <jlayton@kernel.org>
To:     NeilBrown <neilb@suse.de>, Chuck Lever <chuck.lever@oracle.com>
Cc:     linux-nfs@vger.kernel.org, Olga Kornievskaia <kolga@netapp.com>,
        Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Date:   Thu, 02 Nov 2023 07:29:29 -0400
In-Reply-To: <20231101010049.27315-1-neilb@suse.de>
References: <20231101010049.27315-1-neilb@suse.de>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-11-01 at 11:57 +1100, NeilBrown wrote:
> This set fixes two issues found by kernel test robot
> 1/ nfsd4_revoke_states() needs to be defined when not CONFIG_NFSD_V4
> 2/ nfs40_last_revoke is larger than a mechine word in 32 bit configs,
>    so needs protection - use nn->client_lock which is already taken when
>    nfs40_last_revoke is accessed.
>=20
> NeilBrown
>=20

In general, the series looks like something reasonable to do (and
something admins would welcome). I have some (long standing) concerns
around the sc_type value though that I think we probably need to address
prior to or in conjunction with this set.

Cheers,
--=20
Jeff Layton <jlayton@kernel.org>