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:     Amir Goldstein <amir73il@gmail.com>
CC:     Jeff Layton <jlayton@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2] nfsd: more robust allocation failure handling in
 nfsd_file_cache_init
Thread-Topic: [PATCH v2] nfsd: more robust allocation failure handling in
 nfsd_file_cache_init
Thread-Index: AQHYKZoEe5El1hMKYEiEq+uh3pv5TKyjI9OA
Date:   Thu, 24 Feb 2022 20:17:16 +0000
Message-ID: <BB7DEB92-1E3D-4BF5-A723-650C2B95877D@oracle.com>
References: <20220224161705.1041788-1-amir73il@gmail.com>
In-Reply-To: <20220224161705.1041788-1-amir73il@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?E/6DxnF1seuIkfN/AjpJo9jvSepCxSzgZdKLBMcqQPcr+IrMuHYItfmmI2Aw?=
 =?us-ascii?Q?GGYogdmgCp80GHuwpAEknyR6V3xZzKY9jn/JA/B3MsZ6rHgMNxegYMXfrW4l?=
 =?us-ascii?Q?HIO1r98oDwJ4POld5+axVy81T4pGnyn156FwBTh5cjaoOvH8FTaIuKBv5/j7?=
 =?us-ascii?Q?Y+0EbWcGTP3nU/d1Ntq9l9xPSv98/PCfWaojVtWEWVWmpo8i9MnXUgrq/xB7?=
 =?us-ascii?Q?VtSJnaX/KTBpErNcLmLnYCsukXoMHj1tHI9W4MNJXHPdKj+/bDa4NH/Xp5g9?=
 =?us-ascii?Q?JhNywUJU+Q0Sm+KOFTgTtwbIy6ri6plncmOMt2MLAoTWteBpTrVY0+Gp2gi3?=
 =?us-ascii?Q?gMFNCktgQRr3ZHnDtihHg70fjrWgZUo5Sznk+sdChJ2Z1hXHGEy3GgnJplPr?=
 =?us-ascii?Q?h07OGAuhHA1MHNjg2zYIX3KKhygqJp1gDZo/TL7pIbw0tZnFKSnoZMWnFCD2?=
 =?us-ascii?Q?97MfBsj+5QXMoyt4bSNuIySJwVvqAV+GFt3Xp05DZOZhpCoWFzIQPaGqqSQX?=
 =?us-ascii?Q?gqQl3Uk1P0Vjt4ieiE7yZpXhgheBKJJIr0IvE6ceD8/pmwb6eKKSZcko3voL?=
 =?us-ascii?Q?r0gKconq3bpjF1/f+HY0TrOxskfewO4eGLoZ2hEMCt5KZbuIBRRsaX1u/HQn?=
 =?us-ascii?Q?73H51pHsynSHa/3DayGXsCbiap+neNwAfwHr8AW1K5ypVBwY+/wPSb/qrYVP?=
 =?us-ascii?Q?YPGkszVTCj93PFd9Ks3MqvfpOv5uRzf8AJdjKnLCEUde2CPi8WxTmB5/LHje?=
 =?us-ascii?Q?e8FCBMwf4SOpCCO/qlMxy1yVKxRqbn7YMQ5eSplb9/tvellVmbgEFCu3X6+A?=
 =?us-ascii?Q?7p/OM1VX5FLSJK9p0syOgiyccyX5kAXZnXe8+FaypeBKizMB614E16Z+nPXI?=
 =?us-ascii?Q?DCVVmEl3QcNTXaeVLEdCjgBIc9l54+Op9Ry+UavCmtg2SCd0VbVeWatsX15x?=
 =?us-ascii?Q?SXdcc9lqzodUoAn4WL6Zu7m44F/cCiqZD/jF6b0nGK331FC0JO60il/P+/b3?=
 =?us-ascii?Q?8Dm1d1YU4ZGUC/HIjytw7R4tSI52eFqt6ODB6YaQnhfcM9QcewC2ad29Hv1T?=
 =?us-ascii?Q?0vMkyO6XRYCahzjtfeJTe7k4vkRwGZ7NWbXXQaLu7KeUbbLy49YeKct8rKFR?=
 =?us-ascii?Q?Lj6aW4H3bhe0qaNgjEJA/V5UlRvXjiMhEySu4fM86k82LKQqvJ1PL6mQY6Lh?=
 =?us-ascii?Q?jQkpeVmupBIjIkQBCL6xgLdV54+Tt2XU3HlvvcRc+akAsm6NfMKrLwGSlkBu?=
 =?us-ascii?Q?HyVU5pb3/wOsKzVZU7icbjFhPee3/4KC2Olgl9VtMk6QFt95E314i0XqAKzZ?=
 =?us-ascii?Q?TdgoC1NgdxAD/zZLiijz5I7Pz6Eu5vgfud95yH+LfJm4qRnuSaZdR1VF7Fk8?=
 =?us-ascii?Q?zeA+GJGc4ZscZdQkIQvaLAsaLUoNvF45IEPgHcFoVUKEO4LVy61XTeZ5tRf5?=
 =?us-ascii?Q?whU0sE5SurowToQD5ErDY+wvhBKovw08/aBiD0cKldpGfOD9D3l4jj4OopUK?=
 =?us-ascii?Q?L3mnsFDS+ES6cqNzCacYWFsfJDD+p5uN4x11qdo/lHs8tkjJ5BcOVyauTDRk?=
 =?us-ascii?Q?Cn4Q+Ibv8NfWQ0GqpF/fu9c//5Mgi+tOyXGOT7ufIK3UKl++uYgoY+mBPX/P?=
 =?us-ascii?Q?u5t7zwvrhGNptIQbVj+JO6A=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7259812126D4A5418C1FB386D69499A2@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: c4288e36-aedb-4242-5066-08d9f7d2a6cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 20:17:16.2389
 (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: G0iAnpimlOCbBqfyvXid6F4SQoTzLM5FL6LaBOa5C+1UJzkg5ou6gOSGHqCmjXzv0HITFJ+X5aHz2A+AfqDKbg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1254
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10268 signatures=684655
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 spamscore=0
 mlxscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202240112
X-Proofpoint-GUID: _WS4RxAm9MXNsYeJLAv0WrPL2EIJwEPo
X-Proofpoint-ORIG-GUID: _WS4RxAm9MXNsYeJLAv0WrPL2EIJwEPo
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,
        T_SCC_BODY_TEXT_LINE 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

Hi Amir-

> On Feb 24, 2022, at 11:17 AM, Amir Goldstein <amir73il@gmail.com> wrote:
>=20
> The nfsd file cache table can be pretty large and its allocation
> may require as many as 80 contigious pages.
>=20
> Employ the same fix that was employed for similar issue that was
> reported for the reply cache hash table allocation several years ago
> by commit 8f97514b423a ("nfsd: more robust allocation failure handling
> in nfsd_reply_cache_init").
>=20
> Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfs=
d")
> Link: https://lore.kernel.org/linux-nfs/e3cdaeec85a6cfec980e87fc294327c03=
81c1778.camel@kernel.org/
> Suggested-by: Jeff Layton <jlayton@kernel.org>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>=20
> Since v1:
> - Use kvcalloc()
> - Use kvfree()
>=20
> fs/nfsd/filecache.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)

v2 passes some simple testing, so I've applied it to NFSD for-next.
It should get 0-day and merge testing and is available for others
to try out.

I don't have anything that exercises low memory scenarios, though.
Do you have anything like this to try?


> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index 8bc807c5fea4..cc2831cec669 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -632,7 +632,7 @@ nfsd_file_cache_init(void)
> 	if (!nfsd_filecache_wq)
> 		goto out;
>=20
> -	nfsd_file_hashtbl =3D kcalloc(NFSD_FILE_HASH_SIZE,
> +	nfsd_file_hashtbl =3D kvcalloc(NFSD_FILE_HASH_SIZE,
> 				sizeof(*nfsd_file_hashtbl), GFP_KERNEL);
> 	if (!nfsd_file_hashtbl) {
> 		pr_err("nfsd: unable to allocate nfsd_file_hashtbl\n");
> @@ -700,7 +700,7 @@ nfsd_file_cache_init(void)
> 	nfsd_file_slab =3D NULL;
> 	kmem_cache_destroy(nfsd_file_mark_slab);
> 	nfsd_file_mark_slab =3D NULL;
> -	kfree(nfsd_file_hashtbl);
> +	kvfree(nfsd_file_hashtbl);
> 	nfsd_file_hashtbl =3D NULL;
> 	destroy_workqueue(nfsd_filecache_wq);
> 	nfsd_filecache_wq =3D NULL;
> @@ -811,7 +811,7 @@ nfsd_file_cache_shutdown(void)
> 	fsnotify_wait_marks_destroyed();
> 	kmem_cache_destroy(nfsd_file_mark_slab);
> 	nfsd_file_mark_slab =3D NULL;
> -	kfree(nfsd_file_hashtbl);
> +	kvfree(nfsd_file_hashtbl);
> 	nfsd_file_hashtbl =3D NULL;
> 	destroy_workqueue(nfsd_filecache_wq);
> 	nfsd_filecache_wq =3D NULL;
> --=20
> 2.25.1
>=20

--
Chuck Lever