Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever <chuck.lever@oracle.com>
To:     Timo Rothenpieler <timo@rothenpieler.org>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Olga Kornievskaia <aglo@umich.edu>,
        Dai Ngo <dai.ngo@oracle.com>
Subject: Re: [PATCH] nfsd: set RPC_CLNT_CREATE_NO_IDLE_TIMEOUT on callback
 client
Thread-Topic: [PATCH] nfsd: set RPC_CLNT_CREATE_NO_IDLE_TIMEOUT on callback
 client
Thread-Index: AQHXCH83nfMXcY7VqUGg5DZ3Kqzkv6pi/gcAgAGtWICAAAwzgA==
Date:   Mon, 22 Feb 2021 21:47:16 +0000
Message-ID: <C99EA5DE-814A-418B-9685-D400F4E7B964@oracle.com>
References: <20210221182700.1494-1-timo@rothenpieler.org>
 <EF096827-F543-429E-AC9B-1E93C6A35B02@oracle.com>
 <3701466e-6c0a-93e1-1953-f2839b6fa37d@rothenpieler.org>
In-Reply-To: <3701466e-6c0a-93e1-1953-f2839b6fa37d@rothenpieler.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <44F87F68A06E4C4F8B836CB147B9D856@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b649142a-0432-4b25-8d86-08d8d77b6bb8
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2021 21:47:16.0374
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EiG/F7Wie4LEXGr4tqUuLibpEd2wv3vLpYW8SsaglN5/PmV4Y1mRorXeN/9Grv9ZatTh8mQlbGIoQlXjteAl3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4146
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9903 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0
 malwarescore=0 mlxlogscore=999 adultscore=0 bulkscore=0 mlxscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2102220188
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9903 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0
 priorityscore=1501 impostorscore=0 bulkscore=0 mlxscore=0 malwarescore=0
 clxscore=1015 phishscore=0 mlxlogscore=999 lowpriorityscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2102220187
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Feb 22, 2021, at 4:03 PM, Timo Rothenpieler <timo@rothenpieler.org> wr=
ote:
>=20
> On 21.02.2021 20:26, Chuck Lever wrote:
>> Thanks, Timo. A handful of nits below:
>>> On Feb 21, 2021, at 1:27 PM, Timo Rothenpieler <timo@rothenpieler.org> =
wrote:
>>>=20
>>> This tackles an issue where the callback client times out from
>>> inactivity, causing operations like server side copy to never return on
>>> the client side.
>>> I was observing that issue frequently on my RDMA connected clients, it
>>> does not seem to manifest on tcp connected clients.
>> Indeed, it is curious that the COPY issue does not occur on TCP
>> connections. You could try using the same tracing technique to
>> collect some data on TCP to see what is different.
>=20
> I did pretty much the same procedure, mount, copy, wait 10 minutes, copy =
again, just with it mounted via TCP instead of RDMA.
> (And I made sure to boot the server on an unpatched kernel).
> Worked perfectly fine.
> The pcap and trace are attached.
>=20
> To me it looks like it just never hits xprt_disconnect_auto, despite the =
no timeout flag not being set.
> Maybe it gets set implicitly somewhere for TCP? Or there is some keep ali=
ve going on for TCP, that never gives it a chance to time out.

net/sunrpc/xprtsock.c:

2999         /* backchannel */
3000         xprt_set_bound(xprt);
3001         xprt->bind_timeout =3D 0;
3002         xprt->reestablish_timeout =3D 0;
3003         xprt->idle_timeout =3D 0;

But no similar setting for net/sunrpc/xprtrdma/svc_rdma_backchannel.c:

253         xprt_set_bound(xprt);
254         xprt_set_connected(xprt);
255         xprt->bind_timeout =3D RPCRDMA_BIND_TO;
256         xprt->reestablish_timeout =3D RPCRDMA_INIT_REEST_TO;
257         xprt->idle_timeout =3D RPCRDMA_IDLE_DISC_TO;

And perhaps these have been wrong since 5d252f90a800 ("svcrdma: Add
class for RDMA backwards direction transport").

Try replacing your previous patch with one that changes all these
backchannel settings to 0. It should have the same effect as using
NO_IDLE_TIMEOUT.


>>> However, it does not fix the actual issue of the callback channel
>>> not getting re-established and the client being stuck in the call
>>> forever. It just makes it a lot less likely to occur, as long as no
>>> other circumstances cause the callback channel to be disconnected.
>> Agreed. I'm hoping Olga or Dai will look further into why recovery
>> is failing in this case (and whether that missing recovery action
>> is also observed only on RDMA transports!).
>> Please add a Signed-off-by: tag. See the "Sign your work" section
>> in Documentation/process/submitting-patches.rst
>=20
> <trace.dat.xz><traffic.pcap.xz>

--
Chuck Lever