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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBC6FC7EE23 for ; Thu, 1 Jun 2023 16:13:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229681AbjFAQN5 (ORCPT ); Thu, 1 Jun 2023 12:13:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229499AbjFAQN4 (ORCPT ); Thu, 1 Jun 2023 12:13:56 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CCBDE4; Thu, 1 Jun 2023 09:13:55 -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 43B861FDAE; Thu, 1 Jun 2023 16:13:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1685636034; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZJvHyX75bsYrg59/xv8goVF/SY5G71ydpRI3Pzi5140=; b=PZvMYCMQoEFcCHiewgIaHWYAfeoz0QO179rgcwOwjwsxBWYW33SHzYTryDM5y3yV1ixTph umdfykUSKmqOqbf1ixpa7QLeLHr1SrJccO501Zz+AU9Ac1foS50ckQU1ZLD49ZZgKhjsew yB7DLoxcS+1UXGNtc8gNF6pmG8vlddg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1685636034; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZJvHyX75bsYrg59/xv8goVF/SY5G71ydpRI3Pzi5140=; b=U0R/ic9qdjSntJ85EPgaZNvIrEfLVWmdkxYGujNcma/HAtVChmBiwR7uULYLxv9tabZz/v WaBEdlTyPuVETvBA== 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 323DB13441; Thu, 1 Jun 2023 16:13:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id rhIgDMLDeGRlBQAAMHmgww (envelope-from ); Thu, 01 Jun 2023 16:13:54 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id B0704A0754; Thu, 1 Jun 2023 18:13:53 +0200 (CEST) Date: Thu, 1 Jun 2023 18:13:53 +0200 From: Jan Kara To: David Laight Cc: 'Jan Kara' , Christian Brauner , Al Viro , "linux-fsdevel@vger.kernel.org" , Miklos Szeredi , "Darrick J. Wong" , Ted Tso , Jaegeuk Kim , "linux-ext4@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-f2fs-devel@lists.sourceforge.net" , "stable@vger.kernel.org" Subject: Re: [PATCH v2 4/6] fs: Establish locking order for unrelated directories Message-ID: <20230601161353.4o6but7hb7i7qfki@quack3> References: <20230601104525.27897-1-jack@suse.cz> <20230601105830.13168-4-jack@suse.cz> <20230601-gebracht-gesehen-c779a56b3bf3@brauner> <20230601152449.h4ur5zrfqjqygujd@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu 01-06-23 15:37:32, David Laight wrote: > ... > > > > + * 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 > > Not directly relevant to this change but is the 'not an ancestor' > check actually robust? > > I found a condition in which the kernel 'pwd' code (which follows > the inode chain) failed to stop at the base of a chroot. > > I suspect that the ancestor check would fail the same way. Honestly, I'm not sure how this could be the case but I'm not a dcache expert. d_ancestor() works on dentries and the whole dcache code pretty much relies on the fact that there always is at most one dentry for any directory. Also in case we call d_ancestor() from this code, we have the whole filesystem locked from any other directory moves so the ancestor relationship of two dirs cannot change (which is different from pwd code AFAIK). So IMHO no failure is possible in our case. Honza > > IIRC the problematic code used unshare() to 'escape' from > a network natespace. > If it was inside a chroot (that wasn't on a mount point) there > ware two copies of the 'chroot /' inode and the match failed. > > I might be able to find the test case. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > -- Jan Kara SUSE Labs, CR