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: <1dc1a0f2-9be4-8ae0-da26-3c00c8a71b41@kernel.dk>
Date:   Mon, 19 Jun 2023 14:43:56 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Content-Language: en-US
To:     Yangtao Li <frank.li@vivo.com>
Cc:     Jaegeuk Kim <jaegeuk@kernel.org>, Lu Hongfei <luhongfei@vivo.com>,
        linux-f2fs-devel@lists.sourceforge.net,
        LKML <linux-kernel@vger.kernel.org>
From:   Jens Axboe <axboe@kernel.dk>
Subject: f2fs async buffered write patch
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

I came across this patch in a news posting:

https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=d618126911829523e35a61f4a5a4ad159b1b2c8d

which has me a bit worried. As far as I can tell, all that patch does is
set FMODE_BUF_WASYNC, and then just hope that the lower layers handle
the rest?

What happens if iocb->ki_flags & IOCB_NOWAIT is true, and now we do:

generic_perform_write(iocb, from)
	...
	->write_begin() <- does this block?
	...
	->write_end() <- or this one?
	...
	balance_dirty_pages_ratelimited() <- this one surely does...

If you look just one level down the latter to
balance_dirty_pages_ratelimited_flags(), you'll even see the 'flags'
argument documented there.

This looks pretty haphazard and cannot possibly work as-is, so please
get this reverted until f2fs is converted to iomap, or IOCB_NOWAIT is
handled by generic_perform_write() and below.

-- 
Jens Axboe