Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3704805pxj; Mon, 7 Jun 2021 18:32:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwjqw0L7C+HDto5JMcXjW004I5gBKiYmq+6EbaL0ew/zFBnm/ydvZJatxl/vauM8JAgEksw X-Received: by 2002:a17:906:f285:: with SMTP id gu5mr20800260ejb.226.1623115970151; Mon, 07 Jun 2021 18:32:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623115970; cv=none; d=google.com; s=arc-20160816; b=gHLSsViADhEjXE7pAupt+4pR41xtmx1dgc92KPkv4S7mK/mFz1Jy/MyaHnx5dPZ+Ka no8ICvInscT/vPdDvtZQZb9gXU85wpGdGB0F1QUunLeUitixJZNlAShyBYqlzjFlIkjG 0CDhPKaK4wnkUTIVku24AKYXYNS9uWzxMXy0lpISUD6YaITz54zg+KfVIY3/y55Gp+Fl ++mx4CXBNK09YyE/VW509bb/VWqnx+1WTpEy9+BfIjFAqtF4Xl0D0xRkVa4Oobb0CTub NyY4HpRLZHhGFS2ZLeslcBF05YOlW/Euta1eYIP5UHWZnSVvA5n4mqqC/5TXIYh/ns4s ARGA== 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=mE4STUqPVfkwzOIZnLmRGQso//karXsF28k8p/+rgJA=; b=phw3W46MMis6jsnlCI0qmVWfcKh09NAsWHbm74lHVcFMRJsbfcPlyn6xnPqD5vwufz NDq6D3rr57wvVnJBN2GE8Wy6ndnO8SJFC0DQhLPz1RHcCFap4rDpNGoAF904wg/XcCIQ VAW4fzC0/A+u04ugEX0pO641Eaq76C+phs0VETS14h1S+qFQqsJeV1Q9W8plcBpnBhMA XDzLMZgGMBPLnJ+EoJoxuZSmlP4AYCaasIG3evnp8xyjxbDeb7g9OMfXoa0E8voj42Y2 A54OwPjIe/GR99cIRsVUGOnNq5/zvUHz/WG26VQS3bWMu7fZB1DIn2IibOXfP3mwiB4A 12Cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fb.com header.s=facebook header.b=Uou5UW1S; 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 w13si15589360edx.155.2021.06.07.18.32.26; Mon, 07 Jun 2021 18:32:50 -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=Uou5UW1S; 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 S230517AbhFHBd0 (ORCPT + 99 others); Mon, 7 Jun 2021 21:33:26 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:38390 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230351AbhFHBdZ (ORCPT ); Mon, 7 Jun 2021 21:33:25 -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 1581SqT1008134 for ; Mon, 7 Jun 2021 18:31:33 -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=mE4STUqPVfkwzOIZnLmRGQso//karXsF28k8p/+rgJA=; b=Uou5UW1Ssfm0ulvzVe1RP8+ZRHrHm2NjT9KRnnT7a8sFxLEpJfD0CMqdTqxQMntsNiCQ 8KHLoA3FfMNW1bO9UaqaU9gyZtPnAHcLgjCbh7dye/U6vTqEYaMTiSyDYxK3N9Q+kaa0 9MmfkAoeQs15M2sfFLqi5koWWkueIbiBPjw= Received: from mail.thefacebook.com ([163.114.132.120]) by mx0a-00082601.pphosted.com with ESMTP id 390s14se8x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 07 Jun 2021 18:31:33 -0700 Received: from intmgw002.46.prn1.facebook.com (2620:10d:c085:108::8) by mail.thefacebook.com (2620:10d:c085:21d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 7 Jun 2021 18:31:31 -0700 Received: by devvm3388.prn0.facebook.com (Postfix, from userid 111017) id 8C0E081D6D43; Mon, 7 Jun 2021 18:31:29 -0700 (PDT) From: Roman Gushchin To: Jan Kara , Tejun Heo CC: , , , Alexander Viro , Dennis Zhou , Dave Chinner , , Roman Gushchin Subject: [PATCH v8 1/8] writeback, cgroup: do not switch inodes with I_WILL_FREE flag Date: Mon, 7 Jun 2021 18:31:16 -0700 Message-ID: <20210608013123.1088882-2-guro@fb.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20210608013123.1088882-1-guro@fb.com> References: <20210608013123.1088882-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: 6p5bPE2OVxbm96Vbx6NVH8uTsDwkxRCd X-Proofpoint-GUID: 6p5bPE2OVxbm96Vbx6NVH8uTsDwkxRCd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-08_01:2021-06-04,2021-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 mlxscore=0 malwarescore=0 spamscore=0 priorityscore=1501 adultscore=0 suspectscore=0 phishscore=0 mlxlogscore=977 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106080007 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 Acked-by: Tejun Heo Reviewed-by: Jan Kara Acked-by: Dennis Zhou --- 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