Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <280400a1-2dfa-fc8f-92e0-0087b10b37e8@linaro.org>
Date:   Fri, 31 Mar 2023 15:22:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [f2fs-dev] [PATCH v3] f2fs: change the current atomic write way
Content-Language: en-US
To:     Daeho Jeong <daeho43@gmail.com>, linux-kernel@vger.kernel.org,
        linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com,
        jaegeuk@kernel.org
Cc:     Daeho Jeong <daehojeong@google.com>,
        Lee Jones <joneslee@google.com>,
        syzbot <syzbot+b9c67110e04430822b08@syzkaller.appspotmail.com>
References: <20220428181809.2352352-1-daeho43@gmail.com>
From:   Tudor Ambarus <tudor.ambarus@linaro.org>
In-Reply-To: <20220428181809.2352352-1-daeho43@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi!

On 4/28/22 19:18, Daeho Jeong wrote:
> From: Daeho Jeong <daehojeong@google.com>
> 
> Current atomic write has three major issues like below.
>  - keeps the updates in non-reclaimable memory space and they are even
>    hard to be migrated, which is not good for contiguous memory
>    allocation.
>  - disk spaces used for atomic files cannot be garbage collected, so
>    this makes it difficult for the filesystem to be defragmented.
>  - If atomic write operations hit the threshold of either memory usage
>    or garbage collection failure count, All the atomic write operations
>    will fail immediately.
> 
> To resolve the issues, I will keep a COW inode internally for all the
> updates to be flushed from memory, when we need to flush them out in a
> situation like high memory pressure. These COW inodes will be tagged
> as orphan inodes to be reclaimed in case of sudden power-cut or system
> failure during atomic writes.
> 
> Signed-off-by: Daeho Jeong <daehojeong@google.com>
> ---
> v2: removed inmem tracepoints. changed page flush timing. fixed hole
> handling.
> v3: removed unused atomic related page flag.
> ---
>  fs/f2fs/data.c              | 180 +++++++++++------
>  fs/f2fs/debug.c             |  12 +-
>  fs/f2fs/f2fs.h              |  33 +---
>  fs/f2fs/file.c              |  48 ++---
>  fs/f2fs/gc.c                |  27 +--
>  fs/f2fs/inode.c             |   3 +-
>  fs/f2fs/namei.c             |  28 ++-
>  fs/f2fs/node.c              |   4 -
>  fs/f2fs/node.h              |   1 -
>  fs/f2fs/segment.c           | 380 ++++++++++++------------------------
>  fs/f2fs/segment.h           |   4 +-
>  fs/f2fs/super.c             |   6 +-
>  include/trace/events/f2fs.h |  22 ---
>  13 files changed, 302 insertions(+), 446 deletions(-)

This patch fixes the bug reported at:
LINK:
https://syzkaller.appspot.com/bug?id=50ac8d898487cade14315bf673e8d74fd4716ecf

One may find the strace log at:
LINK: https://syzkaller.appspot.com/text?tag=CrashLog&x=11f5de2ac80000
and the C reproducer at:
LINK: https://syzkaller.appspot.com/text?tag=ReproC&x=111facdcc80000

The patch does not apply cleanly on stable/linux-5.15.y. Backporting the
patch is a bit risky for me as I'm not familiar with f2fs. I'm seeking
for some guidance. Is there a plan to backport this patch to Linux
stable? If not, shall I try to backport it? Would you advise me to try
to find all the prerequisite patches for this patch to apply cleanly on
stable/linux-5.15.y, or just to fix the conflicts?

Thanks,
ta