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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: pynfs clean_init issue
Thread-Topic: pynfs clean_init issue
Thread-Index: AQHYqBYvcZZh6BVquE68kijT9LgD6K2e4EEAgAABlICAACn1gIAAAm6A
Date:   Thu, 4 Aug 2022 18:22:48 +0000
Message-ID: <75259D5F-8C42-403D-B687-7412327CCD07@oracle.com>
References: <F80796C9-DFCE-4C7A-A2EE-4EB2075B9007@oracle.com>
 <20220804153816.GB9019@fieldses.org>
 <1C391A45-B2CC-4C90-86DD-1FB9C2000E7E@oracle.com>
 <20220804181405.GC9019@fieldses.org>
In-Reply-To: <20220804181405.GC9019@fieldses.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?3xsoCJ2erKWKenexspOfCBL2xhiKDbvsG2TFkwahw3RFcNjbjH9uIiyitveK?=
 =?us-ascii?Q?Fe3FaaBs8FXnrkEnqZhbGJebIK35VWSGmBWwnV70iMPSVqnfjPU7oPdciT6M?=
 =?us-ascii?Q?eu8pbgvZlB1UXnR3Uk2rJK7xVKkA3NOG2Iz9WwA30T9t5QsYQ8JB1+YkZK75?=
 =?us-ascii?Q?4/nS2r+kkPEmkSUgOUnxj3AQSH8CtHIRspaALbUmLpLzRgnFvy4JYq7q82n6?=
 =?us-ascii?Q?gVhBdVQ3nA4/SsaDuYWdbGdalg08/xz0a8h8/doi6JlSPjZoSETtjP4CJ+t2?=
 =?us-ascii?Q?52E4YKcZAunM9t3UPUROGvumybFBvJDFvLSzmXbbshYA3zAaLW1mbPVBSTK8?=
 =?us-ascii?Q?/VQDzliLQipIM+Jh3ChSC8wE6TL8MMReC6Ny1I06/+yFULmdx7gu0rskhl2P?=
 =?us-ascii?Q?ttCdNj5Z7sE3m/HnFvb9SQrpuJqY0HSrlo5B/OdhgW7YHLFu0C3u+LGVkbOT?=
 =?us-ascii?Q?/UzRglTwuNkV+HEiCHDrbT3fTQ/SvHtFP4KUOnjgHIWcaY3jLJJkG55msqEY?=
 =?us-ascii?Q?v7ODPszjxLgNA9BEPqv54PUCD5FYqJDJBuE7lyf5HkqrHSvVlI9692DM7xI4?=
 =?us-ascii?Q?C6U9DAuxThp1NFpgyFoqTmeTD/0jWR2xBhOQSE0kQ1M/OmTbTx2HHuKrLzb2?=
 =?us-ascii?Q?OexNPqcIzYatEFxRUIgkF5g8igEGcYUd/FFcKQlGRJJDfDGlR16Js2u7QcFB?=
 =?us-ascii?Q?HHL1kpmWCmjwTXD7l+6vGhpD5tSEldIZl/pIDKm3r0kBAoqfof9zoJMliwUr?=
 =?us-ascii?Q?u0ZR5iuf2KgViEp3guNHgftrAaurJXfbvm6cM3ohYNoVnBX4IhA2h/CplBo5?=
 =?us-ascii?Q?FTZu78WzeoHkNeoIfIDA/JqJklihdpRgagL/DY71mvIuWtxDEmM2tQSD1Ezn?=
 =?us-ascii?Q?EX72AnLk8AHEtnhRRdSttfhl/hdyG6eVGA1lB4SJt4KnTgq3YpUdX5cVUn4n?=
 =?us-ascii?Q?k6L2uDOecOpzmTx1N+Pn18VhRDa8lBFTBY3W394w1wOILgn6CC2exj2sYrE8?=
 =?us-ascii?Q?1BbzUuYoh2+As8MKyKUn75UrGVNyxkW3Sjzw8wJjvp7E1okD/3C53Zzgb3Zp?=
 =?us-ascii?Q?NJuFZ3aJVK91+sLEz7Yas70Wa2wCZYodu7SaOxr7e2UZKs0qLEWd56bST2Jy?=
 =?us-ascii?Q?VOFdfhS657QpcqcW3XTWGxTO7P6IQzBnYw4Vppcmyj+BOdbMeI1MVA+J8GN7?=
 =?us-ascii?Q?MbRPnVCHtMIG4o9PT1oznPqnmRQa47bdljFQm8N3+gJvl2eCnPZclmzFeeQN?=
 =?us-ascii?Q?HNei7pAkAvEr8lLdxxQ7TnOeMkN3HPMeCuVwCByhEOZ9TbeAc50thO853b/r?=
 =?us-ascii?Q?2J+8uEeBGavXiE6bQsObNg5Hl5phqZUa9FOiD9AV9PpIFjae7yHo7EEAaS2o?=
 =?us-ascii?Q?V1Fx+AX8wU1pnCPv1kJv1uP5f6ZfPmRrk3qkTd8SN907VAVID/oEGclyjA1m?=
 =?us-ascii?Q?/zwT9eNCVrnrIysXFbQUVoagRN0h7QAg3scVXIvOoYwLbKDAWn2ohmR6Sv4R?=
 =?us-ascii?Q?RNz30vkNKAiR9c15BmaVwWBv7ygjguCUJgZ0EosuoEuN97w1eGeI0A4zWnoH?=
 =?us-ascii?Q?GoVpmaD6zsIIjwVOwt4QusR1xHRxAVpCR7i7hqOG6FNB6XoTzFCeoGiMEAMT?=
 =?us-ascii?Q?3w=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A4C6E615EE99094CAABE01AED244F045@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB5134.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2136a5c-c4a3-445d-3085-08da76465596
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2022 18:22:48.1728
 (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: pUH+7vQuNz92DskLiDBQT0Bo9SvjoyaS+TdIrKY7wsj4XfPRLgKmf2jl5mp6bANC1QxsvnEUEcUYi74qPBL1tw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR10MB5936
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-08-04_03,2022-08-04_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 spamscore=0
 suspectscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2208040079
X-Proofpoint-GUID: a1BdsquDAqoF4WwYW8LDIB7a2F9wBwwH
X-Proofpoint-ORIG-GUID: a1BdsquDAqoF4WwYW8LDIB7a2F9wBwwH
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Aug 4, 2022, at 2:14 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>=20
> On Thu, Aug 04, 2022 at 03:43:56PM +0000, Chuck Lever III wrote:
>> It passes, but leaves the test file so that clean_dir does not work
>> again until the old lease expires.
>=20
> Oh, right.
>=20
>>> But possibly cleanup should also be better.
>>=20
>> This bug might prevent running these tests in an automation harness.
>> I'd say cleanup does need to be better about this.
>>=20
>>> I'm not sure what the right fix is.
>>=20
>> Brute force: keep trying to delete that file if clean_dir receives
>> NFS4ERR_DELAY?
>=20
> Delegations block unlinks too so that probably doesn't help.

Just keep trying until the lease expires. But that's a naive
approach.


>> init_connection somewhere needs to set up a callback service and
>> leave it running.
>=20
> The callback isn't too important, I think, if we want to return the
> delegation at the end of the test we can do that without waiting for the
> server to remind us.

That would help a lot, I think, and would not require an active
callback service on the client.

Btw, DELEG5 has the same problem... and btw, it's final OPEN fails
with EACCES... I'm looking into that too.


> Or maybe destroy the client at the end.  We have no DESTROY_CLIENTID
> (this is 4.0), but we could do a client-rebooting SETCLIENTID/CONFIRM to
> wipe out its state.

--
Chuck Lever