Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp568475rwd; Thu, 1 Jun 2023 04:07:26 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4WK/oGKMTyHEdEDVXMYN5w/2G16VciqV+Xozg94rbe1nxsGgLNbxU1NdLB8Fu3YPdrMPnG X-Received: by 2002:a05:6a20:7d96:b0:10c:ef9f:ddbd with SMTP id v22-20020a056a207d9600b0010cef9fddbdmr7390796pzj.8.1685617645584; Thu, 01 Jun 2023 04:07:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685617645; cv=none; d=google.com; s=arc-20160816; b=d3gAQSXVojrYBA8w4+yoBUUtRN8bOEHO6e8XiW09fHP4wG/sIwAHVCWpNWg6ck281G IJlgOPuGrjl88B0zeV2jv7QgSFCtN/sEd0Y8ZfQ/sIMqx1nvLmkVfSUwUDF5zjULo67w WBdbL+4dRzHAkSAwB32j4ybFD240UT1uiouSjm2Z2ddmd1UurXY5fp8s9xEdC/TfbvLg rc90/ns3b5cUNprPSDxuUzObW4fkfZCQ4OVMgujjzFsXytyZL+f0F0QTZEzr7lB1mmQ9 MYB8ifF2v1g0nd64G9x3Qm2wHnAd+GSKAEWKfXA8I2SbL9OkldwsFoXbpYcxTMm/p1Lf quxg== 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:dkim-signature; bh=9GkePM4DubixxF/Togl9EDjSplXJHzVlt1TjjubXI6U=; b=MLZ1PczNwDPBYqMZNh5vh/CmowuatNb9PReXLcILRPjNX9eZBPJsrxyStch9Iu21Wl 2iOvg55jHLaGdNo2Kz2pbBOAfvgwMWQ2RzKVN3bu2o3hx5EReSxDPFTDWrKSxA3rZgX8 F3lfl+CsQ9m0KKFfO0K68ilNxmAr1A5Qh/JZFWmi0Oye/TO5eYQ6tFIafLH4nLihqrcx C9GTbKcfZAPAcbmBpNX+0/HNtnjSNAuJMLYwpudtVQp+08lzCA/9+buJlm/AomwfPU+u tsWG4XUSrNsMJUDacPW8s/5/YigOtfY0/ser9AIwmgofUFu79KVvJcSPKSMkS832Ilvu S2rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=slatgofT; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b="+PZusY3/"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q13-20020a63750d000000b00534780446d9si2561964pgc.640.2023.06.01.04.07.09; Thu, 01 Jun 2023 04:07:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=slatgofT; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b="+PZusY3/"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233151AbjFAK6i (ORCPT + 99 others); Thu, 1 Jun 2023 06:58:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233075AbjFAK6f (ORCPT ); Thu, 1 Jun 2023 06:58:35 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F459128; Thu, 1 Jun 2023 03:58:32 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id BED651FDA8; Thu, 1 Jun 2023 10:58:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1685617110; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9GkePM4DubixxF/Togl9EDjSplXJHzVlt1TjjubXI6U=; b=slatgofTC1FAmauPjXvaRavFj1ucK0rmX6U3pkMK7g8nnmx0Jo/kPtINHqLNXw7GUbwb1w /ztD5ytaQnOXlejb0d4lmm7cfRqFIKFN7+b1BzZ+hSlyw6VPDv8T6ZTn0jHFKTjUi32r0b HyxQ2KcxqucQD2QVIBQ6/adQk9TM9Wc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1685617110; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9GkePM4DubixxF/Togl9EDjSplXJHzVlt1TjjubXI6U=; b=+PZusY3/jcoS/JUtfNuVliL6Ytt+jkK3M6rPOZB1ovGNIOIvQy1cZP0jFs/SQOjbk2U4cW fRa4ig8VkCobYsBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B060513A34; Thu, 1 Jun 2023 10:58:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kqQMK9Z5eGRzWAAAMHmgww (envelope-from ); Thu, 01 Jun 2023 10:58:30 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 23FB1A0762; Thu, 1 Jun 2023 12:58:30 +0200 (CEST) From: Jan Kara To: Al Viro Cc: , Christian Brauner , Miklos Szeredi , "Darrick J. Wong" , Ted Tso , Jaegeuk Kim , , , linux-f2fs-devel@lists.sourceforge.net, Jan Kara , stable@vger.kernel.org Subject: [PATCH v2 4/6] fs: Establish locking order for unrelated directories Date: Thu, 1 Jun 2023 12:58:24 +0200 Message-Id: <20230601105830.13168-4-jack@suse.cz> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20230601104525.27897-1-jack@suse.cz> References: <20230601104525.27897-1-jack@suse.cz> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3496; i=jack@suse.cz; h=from:subject; bh=5xE40J+PulDN9eVzw5lw6aBn+txq+yIpzvhj12wC0EY=; b=owEBbQGS/pANAwAIAZydqgc/ZEDZAcsmYgBkeHnPY8LB6Lx7l0td+dFkItKAtx61uKArJSscpjR8 raeoUD2JATMEAAEIAB0WIQSrWdEr1p4yirVVKBycnaoHP2RA2QUCZHh5zwAKCRCcnaoHP2RA2cjOB/ 9DhZsLwCaOA84pjyOo2bXNwruEQ6X3HjIwB8zJp9WHd8TLG9ud81Oc6FDDNJmY35Ub7hou0NB8b9XN /1hOOJvVjjumxLrI62LrSHiDVlHogm1aiZ0qEjxLGfQkNA/sl4m21EKgnm6IXMsRjFUo3Vo/zq6Qar jFG5pq7ToYOY79cf3zAMe5D3eiEXxC/OlE0ykzstffroAMZwmxvhuKnw1Mn1g1VUfJ4EV7PvLyiA5Z 2eHvwxOzoVxM6fgw9IRhS5REEZdXLLJcSf2vYbBqinmAHS019XRmm9DoY4cNFd/pDOs2GeKKHCrARV ylAmHIYNsLlC/8HMRTjuuMkI8unfU5 X-Developer-Key: i=jack@suse.cz; a=openpgp; fpr=93C6099A142276A28BBE35D815BC833443038D8C Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Currently the locking order of inode locks for directories that are not in ancestor relationship is not defined because all operations that needed to lock two directories like this were serialized by sb->s_vfs_rename_mutex. However some filesystems need to lock two subdirectories for RENAME_EXCHANGE operations and for this we need the locking order established even for two tree-unrelated directories. Provide a helper function lock_two_inodes() that establishes lock ordering for any two inodes and use it in lock_two_directories(). CC: stable@vger.kernel.org Signed-off-by: Jan Kara --- fs/inode.c | 42 ++++++++++++++++++++++++++++++++++++++++++ fs/internal.h | 2 ++ fs/namei.c | 4 ++-- 3 files changed, 46 insertions(+), 2 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 577799b7855f..4000ab08bbc0 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -1103,6 +1103,48 @@ void discard_new_inode(struct inode *inode) } EXPORT_SYMBOL(discard_new_inode); +/** + * lock_two_inodes - lock two inodes (may be regular files but also dirs) + * + * Lock any non-NULL argument. The caller must make sure that if he is passing + * in two directories, one is not ancestor of the other. Zero, one or two + * objects may be locked by this function. + * + * @inode1: first inode to lock + * @inode2: second inode to lock + * @subclass1: inode lock subclass for the first lock obtained + * @subclass2: inode lock subclass for the second lock obtained + */ +void lock_two_inodes(struct inode *inode1, struct inode *inode2, + unsigned subclass1, unsigned subclass2) +{ + if (!inode1 || !inode2) + /* + * Make sure @subclass1 will be used for the acquired lock. + * This is not strictly necessary (no current caller cares) but + * let's keep things consistent. + */ + if (!inode1) + swap(inode1, inode2); + goto lock; + } + + /* + * If one object is directory and the other is not, we must make sure + * to lock directory first as the other object may be its child. + */ + if (S_ISDIR(inode2->i_mode) == S_ISDIR(inode1->i_mode)) { + if (inode1 > inode2) + swap(inode1, inode2); + } else if (!S_ISDIR(inode1->i_mode)) + swap(inode1, inode2); +lock: + if (inode1) + inode_lock_nested(inode1, subclass1); + if (inode2 && inode2 != inode1) + inode_lock_nested(inode2, subclass2); +} + /** * lock_two_nondirectories - take two i_mutexes on non-directory objects * diff --git a/fs/internal.h b/fs/internal.h index bd3b2810a36b..377030a50aca 100644 --- a/fs/internal.h +++ b/fs/internal.h @@ -152,6 +152,8 @@ extern long prune_icache_sb(struct super_block *sb, struct shrink_control *sc); int dentry_needs_remove_privs(struct mnt_idmap *, struct dentry *dentry); bool in_group_or_capable(struct mnt_idmap *idmap, const struct inode *inode, vfsgid_t vfsgid); +void lock_two_inodes(struct inode *inode1, struct inode *inode2, + unsigned subclass1, unsigned subclass2); /* * fs-writeback.c diff --git a/fs/namei.c b/fs/namei.c index e4fe0879ae55..148570aabe74 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -3028,8 +3028,8 @@ static struct dentry *lock_two_directories(struct dentry *p1, struct dentry *p2) return p; } - inode_lock_nested(p1->d_inode, I_MUTEX_PARENT); - inode_lock_nested(p2->d_inode, I_MUTEX_PARENT2); + lock_two_inodes(p1->d_inode, p2->d_inode, + I_MUTEX_PARENT, I_MUTEX_PARENT2); return NULL; } -- 2.35.3