DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1CBF2146D
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: kerberos with v4.20-rc4 heads up
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <d1f07dd56fff6ee1888ca51b1b263825c3a9fd04.camel@hammerspace.com>
Date:   Fri, 30 Nov 2018 15:36:37 -0500
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD8370DF-74BF-45D5-A9AD-41FBE2794779@oracle.com>
References: <028A9DC5-4136-413C-8A79-F32F997A8AB1@oracle.com>
 <d1f07dd56fff6ee1888ca51b1b263825c3a9fd04.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Nov 30, 2018, at 1:40 PM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>=20
> On Fri, 2018-11-30 at 12:08 -0500, Chuck Lever wrote:
>> Hi-
>>=20
>> I'm testing krb5/krb5i/krb5p with stock v4.20-rc4 and NFS/TCP.
>> The workload is synthetic:
>>=20
>> /home/cel/bin/iozone -M -+u -i0 -i1 -s1g -r8k -t16 -c
>>=20
>> The client is a 12-core Xeon system.
>>=20
>>=20
>> I'm seeing all kinds of symptoms:
>>=20
>> - memory leaks: bvec and enc_pages are leaking
>>=20
>> - EBADMSG is reported to user space
>>=20
>> - data corruption
>>=20
>> - connect deadlocks resulting in a mount hang
>>=20
>> - invalid soft IRQ receive buffer warnings
>>=20
>=20
> Does the following patch help?

With this patch applied I am able to reproduce at least the
soft IRQ warnings and the connect deadlock. There is possibly
more than one bug.

I've found and fixed the enc_pages leak. Patch forthcoming.


> 8<----------------------------------------------
> =46rom 8ff4cd9f0f6912e14f657371b6b7eecf6d2091ee Mon Sep 17 00:00:00 =
2001
> From: Trond Myklebust <trond.myklebust@hammerspace.com>
> Date: Fri, 30 Nov 2018 12:48:47 -0500
> Subject: [PATCH] SUNRPC: call_connect_status() must handle tasks that =
got
> transmitted
>=20
> If a task failed to get the write lock in the call to xprt_connect(), =
then
> it will be queued on xprt->sending. In that case, it is possible for =
it
> to get transmitted before the call to call_connect_status(), in which
> case it needs to be handled by call_transmit_status() instead.
>=20
> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> ---
> net/sunrpc/clnt.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>=20
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index ae3b8145da35..e35d642558e7 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -1915,6 +1915,13 @@ call_connect_status(struct rpc_task *task)
> 	struct rpc_clnt *clnt =3D task->tk_client;
> 	int status =3D task->tk_status;
>=20
> +	/* Check if the task was already transmitted */
> +	if (!test_bit(RPC_TASK_NEED_XMIT, &task->tk_runstate)) {
> +		xprt_end_transmit(task);
> +		task->tk_action =3D call_transmit_status;
> +		return;
> +	}
> +
> 	dprint_status(task);
>=20
> 	trace_rpc_connect_status(task);
> --=20
> 2.19.2
>=20
> --=20
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com

--
Chuck Lever