Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3604828ybv; Tue, 25 Feb 2020 04:13:27 -0800 (PST) X-Google-Smtp-Source: APXvYqxN5UB9EzjHsR4OG7VgHPv9r7XxqsurKBt+FNcHxOjycb887MPw6zJAJ8ncTl2edGWly2PJ X-Received: by 2002:a9d:674f:: with SMTP id w15mr44297923otm.243.1582632807414; Tue, 25 Feb 2020 04:13:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582632807; cv=none; d=google.com; s=arc-20160816; b=nY3pGRFE9O5Do2UTzCD9exgM64+FtXjfjKZr00QjVrwodTMG1DbHV6sZGug7Oksq6c 07yttilsszRFIagb51ZSWbdDMlob/gZJE3B2Mt52jywbaXAXXSGJgXpav1dYLYeLb4Zc Cp2MXtKHlCD66/dljVMWUBtP478yscSMyrUn7SxcvMB0t8JnT4xpdFcsLonfyG0334oC XYaobtNbwBympcoSHsdResQGzcBQ/p3f/gZCI2gkROgKnu9Zyk+nZasaTL9zAyIcWleg KF+53A8Vnqadl8or19lDGnUB9n26H8lOXPi8sEmyz4wdKWuZB63654XiTSdF9Kfj2anE ZV8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=scJq3BDaDteT8VbVu2RwYw4g7n0o/iEzEs1jO3ygBfk=; b=vA1UfUCbcP7nAhy9+NY3B1c0nSvnussLyIpioqPulP0T2rx4Nyk+S+PFCZhFG5ZWYB yrXw89U91FhrcfmHmxuoJAGVZJ4p2Y03lLiM5ifhtq09Ggb/vi+7g0zk4c/o4DOKHQ+G bcOyHy2XkA4WE2CvT3+gYRU6T4guV3IJOo9+vVz6WwO7d7osKB4XQlgc54a42iYHOJjS oZQjUMjNw1qsZ2sEhalM80tqqKsFAw91qCtTrs8IJEVK7OfKs5bPmW3dWLLk8EIPSjIt +mujzeFBTIMm+4hOo/25qyBtAOCQwFIlYbTaYmHCYmxbFZ6QVCLvhy0jCnGPcRStAyA3 3n4g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h138si6664292oib.6.2020.02.25.04.13.11; Tue, 25 Feb 2020 04:13:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725851AbgBYMIH (ORCPT + 99 others); Tue, 25 Feb 2020 07:08:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:42428 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729390AbgBYMIH (ORCPT ); Tue, 25 Feb 2020 07:08:07 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DC428AFBF; Tue, 25 Feb 2020 12:08:05 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 491951E0EA2; Tue, 25 Feb 2020 13:08:05 +0100 (CET) From: Jan Kara To: Cc: "J. R. Okajima" , Jan Kara Subject: [PATCH v2] ext2: Silence lockdep warning about reclaim under xattr_sem Date: Tue, 25 Feb 2020 13:08:03 +0100 Message-Id: <20200225120803.7901-1-jack@suse.cz> X-Mailer: git-send-email 2.16.4 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Lockdep complains about a chain: sb_internal#2 --> &ei->xattr_sem#2 --> fs_reclaim and shrink_dentry_list -> ext2_evict_inode -> ext2_xattr_delete_inode -> down_write(ei->xattr_sem) creating a locking cycle in the reclaim path. This is however a false positive because when we are in ext2_evict_inode() we are the only holder of the inode reference and nobody else should touch xattr_sem of that inode. So we cannot ever block on acquiring the xattr_sem in the reclaim path. Silence the lockdep warning by using down_write_trylock() in ext2_xattr_delete_inode() to not create false locking dependency. Reported-by: "J. R. Okajima" Signed-off-by: Jan Kara --- fs/ext2/xattr.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) Changes since v1: - changed WARN_ON to WARN_ON_ONCE diff --git a/fs/ext2/xattr.c b/fs/ext2/xattr.c index 0456bc990b5e..9ad07c7ef0b3 100644 --- a/fs/ext2/xattr.c +++ b/fs/ext2/xattr.c @@ -790,7 +790,15 @@ ext2_xattr_delete_inode(struct inode *inode) struct buffer_head *bh = NULL; struct ext2_sb_info *sbi = EXT2_SB(inode->i_sb); - down_write(&EXT2_I(inode)->xattr_sem); + /* + * We are the only ones holding inode reference. The xattr_sem should + * better be unlocked! We could as well just not acquire xattr_sem at + * all but this makes the code more futureproof. OTOH we need trylock + * here to avoid false-positive warning from lockdep about reclaim + * circular dependency. + */ + if (WARN_ON_ONCE(!down_write_trylock(&EXT2_I(inode)->xattr_sem))) + return; if (!EXT2_I(inode)->i_file_acl) goto cleanup; -- 2.16.4