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>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RFC 4/8] NFSD: Refactor NFSv3 CREATE
Thread-Topic: [PATCH RFC 4/8] NFSD: Refactor NFSv3 CREATE
Thread-Index: AQHYVOTG+zUxidLhnk2/5Z2owSaWoqz5Kt4AgAAFtgA=
Date:   Wed, 20 Apr 2022 19:31:09 +0000
Message-ID: <D7DC153B-F946-46EA-9A02-B29B0FE6EDC4@oracle.com>
References: <165047903719.1829.18357114060053600197.stgit@manet.1015granger.net>
 <165047934027.1829.4170855794285748158.stgit@manet.1015granger.net>
 <20220420191042.GA27805@fieldses.org>
In-Reply-To: <20220420191042.GA27805@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?hjo427KI2NDg73D/8Qav/5q7EQB6wYf1uB2gCF693DGV6DpkYYCWA4GukpsH?=
 =?us-ascii?Q?NpSCmSBbGF+oG1e0QxvEFRl4ZWVt+eUA8UABZUdqGf/VKAlSpUMqiKljHNNX?=
 =?us-ascii?Q?R6MDLgRD2/+AC45mNjbEsBoJcBRUQpemIOxBV0cZX4q4SRdqw27Hu78h+bz0?=
 =?us-ascii?Q?uInlCesGuItE4WrEZ9Gal+TZ2ZaIm+kOGnGydxt4hsp7tHHB14c7AIQ4l8l7?=
 =?us-ascii?Q?0n3Yh1p++/BePMryBLFoHANXy8N0+LCk1KgyAo8KTnKE+zpK8qS4U0c7NTeD?=
 =?us-ascii?Q?BO65NI+cq7S2JJbqzM7n/0o1a6hGaGwOkW3m/SnRKWyspj13Agnk6vc85L+z?=
 =?us-ascii?Q?ESIczvRJ12SJd7INcw/2Og3g31nKegocUFyDi55GQi8BJyVAt4PbqQM/os85?=
 =?us-ascii?Q?5AMY9ApGF7tFxPaJsQhmNu1EPq0W8RvfoOMLlsrGAGhv5vTay73RWCU9/v5w?=
 =?us-ascii?Q?HJisDTghAssfh0Fy4azflLq/k8rI7gDBFC3O/WXFCUKJem8SXfYop1nSy1TK?=
 =?us-ascii?Q?6ux+Ew1Rmngc+g6uM5CyIy5Hzvo84jIaH8mfdBrEwzMXWglKZHAuABHhM9Wt?=
 =?us-ascii?Q?QMrv9EdEdBHOFV0dH5frhZDO1DtAv+QqB0o/gVWTKbtqKCyKKgOkn7iyp6JR?=
 =?us-ascii?Q?/my+ISDBuJIcyiQRxdU+d0oYP8WWhE7rYF5H+UuSV56RkSaSESGVj2shwqNC?=
 =?us-ascii?Q?Q7FmSMNTjqvmifQrHt/X7Gobt407TuvI2At5Xo16Z58JWXAYOvgkv5yCNndE?=
 =?us-ascii?Q?MUT5QduSVM6Rky85U3kfVItIVQ/yL5rtkL3HREQhEqCPprbrLSJk568xDg3v?=
 =?us-ascii?Q?h1YLAaCeAHyVjGdVhgm91s9i+b2gO2fQFp6IXkIGYJ24KdjprhfTHo4AnvtP?=
 =?us-ascii?Q?J+5bDtwqf/V+lUQNuKomO3AZGQWxow2DRl6BMGvGGmQC5uLW+CeDzM8GwHuX?=
 =?us-ascii?Q?rGnz0/Fh23v4tetXb2XG+kxuanYSj17/X7GzaYwmEpha4IMPKX3iJvHk6YBv?=
 =?us-ascii?Q?7TTR37i61wfmq0/T9koIE6jdjlzic01jMGtwnqCaZcnyYnovF8qEvQfWHM8U?=
 =?us-ascii?Q?3NAuBdnz2gUWC4fjedua0GDsuVkRoCPOtr6HWx/Aftg1h2EunGCXKejNAtOO?=
 =?us-ascii?Q?eEPGEN4zqDVDtUbMlPdgPQZtSPSZrGTWxOZitpHxClwOFNLAT7k0oGXrHXy1?=
 =?us-ascii?Q?8t7qxQPigvU+ED2A9qSgdYSNW81dk1RhUdRfBeHOwESxSQdx8eNnfBOVx2Cn?=
 =?us-ascii?Q?66MgakpR/ibthlzrhOz004SuffijUjtE0uxPhblt+eWt9j+psV2fPP4k2Pd1?=
 =?us-ascii?Q?DJENaRYru18xKlHPUJ5cQ8iyTv7yT9O5ywyWZUDFkVHkSdK9QW92NbhEl2oZ?=
 =?us-ascii?Q?mtmxOkdCyri5PZaxoAQr2pC28VUEyzwAfuKdKm3gwQ4gNdka9MEq3FpCElrN?=
 =?us-ascii?Q?dkPD8itFRsaF+2VV+Rbhl79qMutuPWMOc8uP6jJs2lSYr9DWIz4huwoKrZsV?=
 =?us-ascii?Q?5Q8JRc5yVrAqSUkR8mdxIkrJlNiB3L4TfVS4kRDAYbJBvNRQ2GZso8kfMOLK?=
 =?us-ascii?Q?0sz0bRD1h2GZhFIgGiPcb/e1RKzcOpB3YGqXezAXlv5jQauNf2DvIbO2a6oP?=
 =?us-ascii?Q?1yZ+lp1dSgI5Dt04PcMB4++HJR9pHPd2U4G8ZW3S+oMmbxpg/5jI9mborwGy?=
 =?us-ascii?Q?kwo1D+4JZJHbtZmIuLFQnAIwJiahuRZOffcwKHkDvPBw9Ax2Aud1qW/ajM3z?=
 =?us-ascii?Q?Vd3uZS0tLYuiOKYYrLTOYlgqvJLHpKI=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C982321B42CC0A4BAB86D884BCEBB7A8@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: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 30420bea-ed05-4cc4-1120-08da23045227
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2022 19:31:09.0542
 (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: ODBIKvreHQ6YBVKhWR7/ocF57Z96tWILATiw/9Wfy1GsjGPvf/BAnUE2pf136S7wFmxa6B8mJ/YR0YL5u9rDzQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5271
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-20_05:2022-04-20,2022-04-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 suspectscore=0
 malwarescore=0 mlxlogscore=738 adultscore=0 mlxscore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2204200114
X-Proofpoint-GUID: vETdIr9fwUiVHI12g_7mIerpSLhv9-vS
X-Proofpoint-ORIG-GUID: vETdIr9fwUiVHI12g_7mIerpSLhv9-vS
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_H5,RCVD_IN_MSPIKE_WL,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 Apr 20, 2022, at 3:10 PM, J. Bruce Fields <bfields@fieldses.org> wrote=
:
>=20
> On Wed, Apr 20, 2022 at 02:29:00PM -0400, Chuck Lever wrote:
>> The NFSv3 CREATE and NFSv4 OPEN(CREATE) use cases are about to
>> diverge such that it makes sense to split do_nfsd_create() into one
>> version for NFSv3 and one for NFSv4.
>>=20
>> As a first step, copy do_nfsd_create() to nfs3proc.c and remove
>> NFSv4-specific logic.
>>=20
>> One immediate legibility benefit is that the logic for handling
>> NFSv3 createhow is now quite straightforward. NFSv4 createhow
>> has some subtleties that IMO do not belong in generic code.
>=20
> That makes sense to me, though just eyeballing the two resulting
> functions, you end up with a *lot* of duplication.

About 200 lines. I would feel a little more agreeable to
this if we didn't already have a separate "create" function
for NFSv2 (ie, nfsd_proc_create).


> I wonder if it'd be
> possible to keep the two paths free of complications from each other
> while sharing more code, e.g. if there are logical blocks of code that
> could now be pulled out into common helpers.

I'm open to suggestions, but after the final patch in this
series, I don't see much else that is meaningful that can be
re-used by both. nfsd_create_setattr() was the one area that
seemed both common and heavyweight. The other areas are just
lightweight sanity checks.

And honestly, in this case, I don't think these code paths
are well-served by aggressive code de-duplication. The code
in each case is more readable and less brittle this way. The
NFSv4 code path now has some comments that mark the subtle
differences with NFSv3 exclusive create, and now you can't
break NFSv3 CREATE by making a change to NFSv4 OPEN, which
is far more complex.


--
Chuck Lever