Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp723865pxj; Thu, 3 Jun 2021 18:35:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9AlzJ79y5H4OEQ52sSVCBq2RWlykEdeyHnoxaW3dnVor9lpee8PfZUDQ0X+buJ8rPfB+W X-Received: by 2002:a05:6402:416:: with SMTP id q22mr2166179edv.204.1622770505568; Thu, 03 Jun 2021 18:35:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622770505; cv=none; d=google.com; s=arc-20160816; b=BrBSSHjG+mAYonwb6p/+3qVk3tbJZUb49S9disPDAAuAxMdSvVSOT3w4kYX1yKOFA1 pEgp4vsZXOaiHBjNHHiwTOGNILuj+I0xVfCI5SaJ/KT/WOqbhD7rxLwkYqw6FuVUayDJ ofVh6drEV3JXxT4JWQ/85z54yaQ3HfmX2cjDpGazImVliuF0rAdRzDMCUUT8NaoPziEv 06PA/EfzTijV6ccYQNV/BAAYvlWOsBEf9Bf+qIf6cdhCwklSOY6YPDEaGCAGCg/wFQrR y8xX9qfLJozYRtD09LGj7xkDkl4x1X8fBH4YhbjSJKWzz/xeUXd/0XCULSnvFa3rIQHC 44Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=0gZxeDTVwwISi0mUQNjyH9+4fnDHEWwqdGc5QqFQf6Q=; b=zY93l24QhAZgJ1LyGs66yEfx/z6o/YDbTlbZ8O8BsWuEuE9xqRqykJkZODr7r9KeoY 1E7lM/qY8lZOwTPBgGNIHi34LJRsOZGHaK4nPkkCh2tyj7WsmzDN5uuUm7+OnunNrM2e ToYGkSKADlcEGkDNdNVGvqNxH3SuCdN9ecDwfCBGLn+A8QczWzDNwt7uSeqICCdwaS0r qJqGcSHI8VkC7M1AJLAKG6oggB5JLe/4Pb6THFY/yhlbMyb5zHrhcFvPhT7OGIv8x7YA 6WPfOz1YGNuZeioZSnhrLasF9sSvnvLQPO9MQWuyROi8az6Jl2g4O+A+vVPsPcy0k4jH euxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fb.com header.s=facebook header.b=HhVza4Lo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=fb.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk3si3459229edb.476.2021.06.03.18.34.41; Thu, 03 Jun 2021 18:35:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@fb.com header.s=facebook header.b=HhVza4Lo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=fb.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230153AbhFDBdy (ORCPT + 99 others); Thu, 3 Jun 2021 21:33:54 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:2472 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230145AbhFDBdw (ORCPT ); Thu, 3 Jun 2021 21:33:52 -0400 Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1541Ub8f031530 for ; Thu, 3 Jun 2021 18:32:06 -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=0gZxeDTVwwISi0mUQNjyH9+4fnDHEWwqdGc5QqFQf6Q=; b=HhVza4LorKtpD1j6N2ASKf7VUTEXpzbqgg8Ze6a0E/CZ8jaXoGBBem7TxNweH+PHyTs2 onC5tbV47NFkOFm5lrAJzJn+vdEL2qvrWwP0cmyAaQuIN8CM0DyhpwNZMZEnEnCyVhoE 09Sf2g5B6fZD2n1kuVc8kf96+KDKMriVvbg= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 38xj5kg1tk-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 03 Jun 2021 18:32:06 -0700 Received: from intmgw003.48.prn1.facebook.com (2620:10d:c0a8:1b::d) by mail.thefacebook.com (2620:10d:c0a8:83::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 3 Jun 2021 18:32:04 -0700 Received: by devvm3388.prn0.facebook.com (Postfix, from userid 111017) id 733C27FA36D2; Thu, 3 Jun 2021 18:32:00 -0700 (PDT) From: Roman Gushchin To: Jan Kara , Tejun Heo CC: , , , Alexander Viro , Dennis Zhou , Dave Chinner , , Roman Gushchin Subject: [PATCH v7 1/6] writeback, cgroup: do not switch inodes with I_WILL_FREE flag Date: Thu, 3 Jun 2021 18:31:54 -0700 Message-ID: <20210604013159.3126180-2-guro@fb.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210604013159.3126180-1-guro@fb.com> References: <20210604013159.3126180-1-guro@fb.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-FB-Internal: Safe Content-Type: text/plain X-Proofpoint-GUID: Y-12iCuvO9X2Vv6bZoepuUZyhv-1oZCj X-Proofpoint-ORIG-GUID: Y-12iCuvO9X2Vv6bZoepuUZyhv-1oZCj X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-04_01:2021-06-04,2021-06-03 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 impostorscore=0 bulkscore=0 malwarescore=0 phishscore=0 spamscore=0 adultscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106040009 X-FB-Internal: deliver Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If an inode's state has I_WILL_FREE flag set, the inode will be freed soon, so there is no point in trying to switch the inode to a different cgwb. I_WILL_FREE was ignored since the introduction of the inode switching, so it looks like it doesn't lead to any noticeable issues for a user. This is why the patch is not intended for a stable backport. Suggested-by: Jan Kara Signed-off-by: Roman Gushchin --- fs/fs-writeback.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index e91980f49388..bd99890599e0 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -389,10 +389,10 @@ static void inode_switch_wbs_work_fn(struct work_st= ruct *work) xa_lock_irq(&mapping->i_pages); =20 /* - * Once I_FREEING is visible under i_lock, the eviction path owns - * the inode and we shouldn't modify ->i_io_list. + * Once I_FREEING or I_WILL_FREE are visible under i_lock, the eviction + * path owns the inode and we shouldn't modify ->i_io_list. */ - if (unlikely(inode->i_state & I_FREEING)) + if (unlikely(inode->i_state & (I_FREEING | I_WILL_FREE))) goto skip_switch; =20 trace_inode_switch_wbs(inode, old_wb, new_wb); @@ -517,7 +517,7 @@ static void inode_switch_wbs(struct inode *inode, int= new_wb_id) /* while holding I_WB_SWITCH, no one else can update the association */ spin_lock(&inode->i_lock); if (!(inode->i_sb->s_flags & SB_ACTIVE) || - inode->i_state & (I_WB_SWITCH | I_FREEING) || + inode->i_state & (I_WB_SWITCH | I_FREEING | I_WILL_FREE) || inode_to_wb(inode) =3D=3D isw->new_wb) { spin_unlock(&inode->i_lock); goto out_free; --=20 2.31.1