From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Christian Brauner <brauner@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
"Darrick J. Wong" <djwong@kernel.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/6] ext4: Remove ext4 locking of moved directory
Date: Thu, 1 Jun 2023 10:52:22 -0400 [thread overview]
Message-ID: <20230601145222.GB1069561@mit.edu> (raw)
In-Reply-To: <20230601105830.13168-1-jack@suse.cz>
On Thu, Jun 01, 2023 at 12:58:21PM +0200, Jan Kara wrote:
> Remove locking of moved directory in ext4_rename2(). We will take care
> of it in VFS instead. This effectively reverts commit 0813299c586b
> ("ext4: Fix possible corruption when moving a directory") and followup
> fixes.
Remind me --- commit 0813299c586b is not actually causing any
problems; it's just not fully effective at solving the problem. Is
that correct?
In other words, is there a rush in trying to get this revert to Linus
during this cycle as a regression fix?
I think the answer is no, and we can just let this full patch series
go in via the vfs branch during the next merge window, but I just
wanted to make sure.
Thanks!
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
"Darrick J. Wong" <djwong@kernel.org>,
stable@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net,
linux-xfs@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v2 1/6] ext4: Remove ext4 locking of moved directory
Date: Thu, 1 Jun 2023 10:52:22 -0400 [thread overview]
Message-ID: <20230601145222.GB1069561@mit.edu> (raw)
In-Reply-To: <20230601105830.13168-1-jack@suse.cz>
On Thu, Jun 01, 2023 at 12:58:21PM +0200, Jan Kara wrote:
> Remove locking of moved directory in ext4_rename2(). We will take care
> of it in VFS instead. This effectively reverts commit 0813299c586b
> ("ext4: Fix possible corruption when moving a directory") and followup
> fixes.
Remind me --- commit 0813299c586b is not actually causing any
problems; it's just not fully effective at solving the problem. Is
that correct?
In other words, is there a rush in trying to get this revert to Linus
during this cycle as a regression fix?
I think the answer is no, and we can just let this full patch series
go in via the vfs branch during the next merge window, but I just
wanted to make sure.
Thanks!
- Ted
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2023-06-01 14:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 10:58 [PATCH v2 0/6] fs: Fix directory corruption when moving directories Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-01 10:58 ` [PATCH v2 1/6] ext4: Remove ext4 locking of moved directory Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-01 14:52 ` Theodore Ts'o [this message]
2023-06-01 14:52 ` Theodore Ts'o
2023-06-01 15:27 ` Jan Kara
2023-06-01 15:27 ` [f2fs-dev] " Jan Kara
2023-06-01 15:58 ` Christian Brauner
2023-06-01 15:58 ` [f2fs-dev] " Christian Brauner
2023-06-01 10:58 ` [PATCH v2 2/6] Revert "udf: Protect rename against modification of moved directory" Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-01 10:58 ` [PATCH v2 3/6] Revert "f2fs: fix potential corruption when moving a directory" Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-01 10:58 ` [PATCH v2 4/6] fs: Establish locking order for unrelated directories Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-01 13:58 ` Christian Brauner
2023-06-01 13:58 ` [f2fs-dev] " Christian Brauner
2023-06-01 15:24 ` Jan Kara
2023-06-01 15:24 ` [f2fs-dev] " Jan Kara
2023-06-01 15:37 ` David Laight
2023-06-01 15:37 ` [f2fs-dev] " David Laight
2023-06-01 16:13 ` Jan Kara
2023-06-01 16:13 ` [f2fs-dev] " Jan Kara
2023-06-01 16:21 ` Christian Brauner
2023-06-01 16:21 ` [f2fs-dev] " Christian Brauner
2023-06-01 16:33 ` David Laight
2023-06-01 16:33 ` [f2fs-dev] " David Laight
2023-06-02 12:34 ` Christian Brauner
2023-06-02 12:34 ` [f2fs-dev] " Christian Brauner
2023-06-01 15:59 ` Christian Brauner
2023-06-01 15:59 ` [f2fs-dev] " Christian Brauner
2023-06-02 1:36 ` kernel test robot
2023-06-02 1:36 ` [f2fs-dev] " kernel test robot
2023-06-01 10:58 ` [PATCH v2 5/6] fs: Lock moved directories Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-01 10:58 ` [PATCH v2 6/6] fs: Restrict lock_two_nondirectories() to non-directory inodes Jan Kara
2023-06-01 10:58 ` [f2fs-dev] " Jan Kara
2023-06-02 13:05 ` [PATCH v2 0/6] fs: Fix directory corruption when moving directories Christian Brauner
2023-06-02 13:05 ` [f2fs-dev] " Christian Brauner
2023-07-06 0:18 ` patchwork-bot+f2fs
2023-07-06 0:18 ` patchwork-bot+f2fs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230601145222.GB1069561@mit.edu \
--to=tytso@mit.edu \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.