All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux F2FS Dev Mailing List
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [GIT PULL] f2fs update for 6.8-rc1
Date: Fri, 12 Jan 2024 07:12:42 +0000	[thread overview]
Message-ID: <20240112071242.GA1674809@ZenIV> (raw)
In-Reply-To: <CAHk-=wgTbey3-RCz8ZpmTsMhUGf02YVV068k3OzrmOvJPowXfw@mail.gmail.com>

On Thu, Jan 11, 2024 at 09:05:51PM -0800, Linus Torvalds wrote:
> On Thu, 11 Jan 2024 at 10:28, Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git tags/f2fs-for-6.8-rc1
> 
> Hmm. I got a somewhat confusing conflict in f2fs_rename().
> 
> And honestly, I really don't know what the right resolution is. What I
> ended up with was this:
> 
>         if (old_is_dir) {
>                 if (old_dir_entry)
>                         f2fs_set_link(old_inode, old_dir_entry,
>                                                 old_dir_page, new_dir);
>                 else
>                         f2fs_put_page(old_dir_page, 0);

Where would you end up with old_dir_page != NULL and old_dir_entry == NULL?
old_dir_page is initialized to NULL and the only place where it's altered
is
                old_dir_entry = f2fs_parent_dir(old_inode, &old_dir_page);
Which is immediately followed by
                if (!old_dir_entry) {
                        if (IS_ERR(old_dir_page))
                                err = PTR_ERR(old_dir_page);
                        goto out_old;
                }
so we are *not* going to end up at that if (old_is_dir) in that case.

Original would have been more clear as
	if (old_is_dir) {
		if (old_dir != new_dir) {
			/* we have .. in old_dir_page/old_dir_entry */
			if (!whiteout)
	                        f2fs_set_link(old_inode, old_dir_entry,
                                                old_dir_page, new_dir);
			else
	                        f2fs_put_page(old_dir_page, 0);
		}
                f2fs_i_links_write(old_dir, false);
	}
- it is equivalent to what that code used to do.  And "don't update ..
if we are leaving a whiteout behind" was teh bug fixed by commit
in f2fs tree...

The bottom line: your variant is not broken, but only because
f2fs_put_page() starts with
static inline void f2fs_put_page(struct page *page, int unlock)
{
        if (!page)
                return;

IOW, you are doing f2fs_put_page(NULL, 0), which is an explicit no-op.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux F2FS Dev Mailing List
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [GIT PULL] f2fs update for 6.8-rc1
Date: Fri, 12 Jan 2024 07:12:42 +0000	[thread overview]
Message-ID: <20240112071242.GA1674809@ZenIV> (raw)
In-Reply-To: <CAHk-=wgTbey3-RCz8ZpmTsMhUGf02YVV068k3OzrmOvJPowXfw@mail.gmail.com>

On Thu, Jan 11, 2024 at 09:05:51PM -0800, Linus Torvalds wrote:
> On Thu, 11 Jan 2024 at 10:28, Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git tags/f2fs-for-6.8-rc1
> 
> Hmm. I got a somewhat confusing conflict in f2fs_rename().
> 
> And honestly, I really don't know what the right resolution is. What I
> ended up with was this:
> 
>         if (old_is_dir) {
>                 if (old_dir_entry)
>                         f2fs_set_link(old_inode, old_dir_entry,
>                                                 old_dir_page, new_dir);
>                 else
>                         f2fs_put_page(old_dir_page, 0);

Where would you end up with old_dir_page != NULL and old_dir_entry == NULL?
old_dir_page is initialized to NULL and the only place where it's altered
is
                old_dir_entry = f2fs_parent_dir(old_inode, &old_dir_page);
Which is immediately followed by
                if (!old_dir_entry) {
                        if (IS_ERR(old_dir_page))
                                err = PTR_ERR(old_dir_page);
                        goto out_old;
                }
so we are *not* going to end up at that if (old_is_dir) in that case.

Original would have been more clear as
	if (old_is_dir) {
		if (old_dir != new_dir) {
			/* we have .. in old_dir_page/old_dir_entry */
			if (!whiteout)
	                        f2fs_set_link(old_inode, old_dir_entry,
                                                old_dir_page, new_dir);
			else
	                        f2fs_put_page(old_dir_page, 0);
		}
                f2fs_i_links_write(old_dir, false);
	}
- it is equivalent to what that code used to do.  And "don't update ..
if we are leaving a whiteout behind" was teh bug fixed by commit
in f2fs tree...

The bottom line: your variant is not broken, but only because
f2fs_put_page() starts with
static inline void f2fs_put_page(struct page *page, int unlock)
{
        if (!page)
                return;

IOW, you are doing f2fs_put_page(NULL, 0), which is an explicit no-op.

  reply	other threads:[~2024-01-12  7:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 18:28 [f2fs-dev] [GIT PULL] f2fs update for 6.8-rc1 Jaegeuk Kim
2024-01-11 18:28 ` Jaegeuk Kim
2024-01-12  5:05 ` [f2fs-dev] " Linus Torvalds
2024-01-12  5:05   ` Linus Torvalds
2024-01-12  7:12   ` Al Viro [this message]
2024-01-12  7:12     ` Al Viro
2024-01-12 17:08     ` [f2fs-dev] " Jaegeuk Kim
2024-01-12 17:08       ` Jaegeuk Kim
2024-01-12 17:19       ` [f2fs-dev] " Jaegeuk Kim
2024-01-12 17:19         ` Jaegeuk Kim
2024-01-12 18:18     ` [f2fs-dev] " Linus Torvalds
2024-01-12 18:18       ` Linus Torvalds
2024-01-12  5:07 ` [f2fs-dev] " pr-tracker-bot
2024-01-12  5:07   ` pr-tracker-bot
2024-01-16 19:02 ` patchwork-bot+f2fs
2024-01-16 19:02   ` 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=20240112071242.GA1674809@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.