From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B9BEC47082 for ; Tue, 8 Jun 2021 23:08:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 462166135D for ; Tue, 8 Jun 2021 23:08:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235356AbhFHXJy (ORCPT ); Tue, 8 Jun 2021 19:09:54 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:35852 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S235351AbhFHXJx (ORCPT ); Tue, 8 Jun 2021 19:09:53 -0400 Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.43/8.16.0.43) with SMTP id 158N59uS002186 for ; Tue, 8 Jun 2021 16:07:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=facebook; bh=Wat9OU0kdkYsu0broEQrIYlR9g8uY2amIQn7zLLGWCw=; b=X3N+3hI2zVA2eBExpz77q+Zqg8uVyD3H9fGk6mbYNV+QrhnceJrFYKrmPma1ppmkRG3h pr170e1V6oAiJ+lk4UBeMgniVTEcNvwBRiRC29h23o08EblmBTgQfZLiT1z/M6FBq4rC recGjnn3+n52FcAwsyC15A7ma0wJeJWMlOg= Received: from mail.thefacebook.com ([163.114.132.120]) by m0089730.ppops.net with ESMTP id 391nwp9svv-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 08 Jun 2021 16:07:59 -0700 Received: from intmgw002.46.prn1.facebook.com (2620:10d:c085:208::f) by mail.thefacebook.com (2620:10d:c085:11d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 8 Jun 2021 16:07:54 -0700 Received: by devvm3388.prn0.facebook.com (Postfix, from userid 111017) id 3AF3182542CB; Tue, 8 Jun 2021 16:02:28 -0700 (PDT) From: Roman Gushchin To: Andrew Morton , Tejun Heo CC: , , , Alexander Viro , Jan Kara , Dennis Zhou , Dave Chinner , , Roman Gushchin , Jan Kara Subject: [PATCH v9 3/8] writeback, cgroup: increment isw_nr_in_flight before grabbing an inode Date: Tue, 8 Jun 2021 16:02:20 -0700 Message-ID: <20210608230225.2078447-4-guro@fb.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210608230225.2078447-1-guro@fb.com> References: <20210608230225.2078447-1-guro@fb.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-FB-Internal: Safe Content-Type: text/plain X-Proofpoint-ORIG-GUID: G4RkKvHxp8GJ-W626gDEwWjSxKKWwEFd X-Proofpoint-GUID: G4RkKvHxp8GJ-W626gDEwWjSxKKWwEFd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-08_17:2021-06-04,2021-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 impostorscore=0 spamscore=0 suspectscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 priorityscore=1501 bulkscore=0 mlxscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106080146 X-FB-Internal: deliver Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org isw_nr_in_flight is used do determine whether the inode switch queue should be flushed from the umount path. Currently it's increased after grabbing an inode and even scheduling the switch work. It means the umount path can be walked past cleanup_offline_cgwb() with active inode references, which can result in a "Busy inodes after unmount." message and use-after-free issues (with inode->i_sb which gets freed). Fix it by incrementing isw_nr_in_flight before doing anything with the inode and decrementing in the case when switching wasn't scheduled. The problem hasn't yet been seen in the real life and was discovered by Jan Kara by looking into the code. Suggested-by: Jan Kara Signed-off-by: Roman Gushchin Reviewed-by: Jan Kara --- fs/fs-writeback.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index b6fc13a4962d..4413e005c28c 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -505,6 +505,8 @@ static void inode_switch_wbs(struct inode *inode, int= new_wb_id) if (!isw) return; =20 + atomic_inc(&isw_nr_in_flight); + /* find and pin the new wb */ rcu_read_lock(); memcg_css =3D css_from_id(new_wb_id, &memory_cgrp_subsys); @@ -535,11 +537,10 @@ static void inode_switch_wbs(struct inode *inode, i= nt new_wb_id) * Let's continue after I_WB_SWITCH is guaranteed to be visible. */ call_rcu(&isw->rcu_head, inode_switch_wbs_rcu_fn); - - atomic_inc(&isw_nr_in_flight); return; =20 out_free: + atomic_dec(&isw_nr_in_flight); if (isw->new_wb) wb_put(isw->new_wb); kfree(isw); --=20 2.31.1