From patchwork Tue May 9 06:28:38 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve French X-Patchwork-Id: 13235377 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9729C7EE22 for ; Tue, 9 May 2023 06:28:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233784AbjEIG2y (ORCPT ); Tue, 9 May 2023 02:28:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234648AbjEIG2x (ORCPT ); Tue, 9 May 2023 02:28:53 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C87265A4 for ; Mon, 8 May 2023 23:28:52 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-4f24ddf514eso2396299e87.0 for ; Mon, 08 May 2023 23:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683613730; x=1686205730; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=PR8MLH39bpVXuYi/n+DI0wKNumvoHpECw2yLEsV+23E=; b=r0jjvirKiQxy7rvMqGCOiO6kkkTwBXaeJ6NrbzsaF9HUwqSQoMOqjOSxNsVSyevx6O /CTnZ+UBD2nHHT8yhLOQGT79pPTsB0ZRn5NKnI4JIxQ6rVkzGYvIK5gNbQxjO11G+MN8 x5xh6AV+7UowQzA0ir2ny+8ojSu+yQRRhpS1u2dA9vMUEycISXSm7As3CDwcQoF0Gx8Q 3wuQ+oRQcm6446n/39H/S5EipDkfzhoijyGTr1d3RAJ9sGwr8Y6OTlhf9qbD0DeEQyhR tfHuzT4izqdjxr9thXuJQMu8tirIBUEHu/qTGkSLtKkZPCfNt7125jtjB4Mq1+jHTyrU GVkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683613730; x=1686205730; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PR8MLH39bpVXuYi/n+DI0wKNumvoHpECw2yLEsV+23E=; b=kR5AAyKzOyKGnQu1pTi/eq5AQplFeiCQM48wZvqaBjjw2Aag5KUaTJxppovxK3riZN tDAHOeahEJWu1/ExUMTmr85J/7yF/Mp0T4YF5Rmzx/MX+Mn2V7Ek8v0PQ/eakebnNAo1 e2dlCj7pZnO14W4ZTf0t3o7pvy0VIbMmGMYuNCBDfCLUTBIGtoYUlfeOdE4DzqddJTW7 KENFKd6Mt/DvyhNWTGukUrLH9ziANaHBaPGjFokUurPHQEnEQepBX0DY8FHr2+qSpKdl tP69HfGZmaOJNPIQqXFYlmtWj7JoQU2ceepzqM/l1EjP+yOkDWL9FX06dgl3jLUEJ7Ec tD2w== X-Gm-Message-State: AC+VfDx8DOcNgxiEWFPakspMwMRjvTgdDCS074Owv27JRCA20pmwnxYA WlUg+PhgiNQ56Wc3eFdpS3uwOCFjybKHem3NRuO96OqHLhKBMw== X-Google-Smtp-Source: ACHHUZ4BMRC2xz2nUpO8W0FQD213rcVkEOoET5lLZsMHj17lR6C0q0TYvSblRN4C/vpPCbNpF3IdTYJfBn8wfs1r9rk= X-Received: by 2002:ac2:4f8e:0:b0:4f1:3eea:eaf9 with SMTP id z14-20020ac24f8e000000b004f13eeaeaf9mr403645lfs.24.1683613729915; Mon, 08 May 2023 23:28:49 -0700 (PDT) MIME-Version: 1.0 From: Steve French Date: Tue, 9 May 2023 01:28:38 -0500 Message-ID: Subject: [PATCH] SMB3: force unmount was failing to close deferred close files To: CIFS Cc: David Howells , Bharath S M , rohiths msft Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org In investigating a failure with xfstest generic/392 it was noticed that mounts were reusing a superblock that should already have been freed. This turned out to be related to deferred close files keeping a reference count until the closetimeo expired. Currently the only way an fs knows that mount is beginning is when force unmount is called, but when this, ie umount_begin(), is called all deferred close files on the share (tree connection) should be closed immediately (unless shared by another mount) to avoid using excess resources on the server and to avoid reusing a superblock which should already be freed. In umount_begin, close all deferred close handles for that share if this is the last mount using that share on this client (ie send the SMB3 close request over the wire for those that have been already closed by the app but that we have kept a handle lease open for and have not sent closes to the server for yet). Reported-by: David Howells Cc: Fixes: 78c09634f7dc ("Cifs: Fix kernel oops caused by deferred close for files.") See attached From 6c840c704d9dc3f02970c46ebebb359e423c0548 Mon Sep 17 00:00:00 2001 From: Steve French Date: Tue, 9 May 2023 01:00:42 -0500 Subject: [PATCH] SMB3: force unmount was failing to close deferred close files In investigating a failure with xfstest generic/392 it was noticed that mounts were reusing a superblock that should already have been freed. This turned out to be related to deferred close files keeping a reference count until the closetimeo expired. Currently the only way an fs knows that mount is beginning is when force unmount is called, but when this, ie umount_begin(), is called all deferred close files on the share (tree connection) should be closed immediately (unless shared by another mount) to avoid using excess resources on the server and to avoid reusing a superblock which should already be freed. In umount_begin, close all deferred close handles for that share if this is the last mount using that share on this client (ie send the SMB3 close request over the wire for those that have been already closed by the app but that we have kept a handle lease open for and have not sent closes to the server for yet). Reported-by: David Howells Cc: Fixes: 78c09634f7dc ("Cifs: Fix kernel oops caused by deferred close for files.") Signed-off-by: Steve French --- fs/cifs/cifsfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 81430abacf93..8b6b3b6985f3 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -744,6 +744,7 @@ static void cifs_umount_begin(struct super_block *sb) spin_unlock(&tcon->tc_lock); spin_unlock(&cifs_tcp_ses_lock); + cifs_close_all_deferred_files(tcon); /* cancel_brl_requests(tcon); */ /* BB mark all brl mids as exiting */ /* cancel_notify_requests(tcon); */ if (tcon->ses && tcon->ses->server) { -- 2.34.1