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;
Date:   Mon, 19 Jun 2023 23:16:20 -0700
From:   Jaegeuk Kim <jaegeuk@kernel.org>
To:     Jens Axboe <axboe@kernel.dk>
Cc:     Yangtao Li <frank.li@vivo.com>, Lu Hongfei <luhongfei@vivo.com>,
        linux-f2fs-devel@lists.sourceforge.net,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: f2fs async buffered write patch
Message-ID: <ZJFENFDFVx++RmhA@google.com>
References: <1dc1a0f2-9be4-8ae0-da26-3c00c8a71b41@kernel.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1dc1a0f2-9be4-8ae0-da26-3c00c8a71b41@kernel.dk>
Precedence: bulk

On 06/19, Jens Axboe wrote:
> 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.

Thank you for pointing that out. It seems I haven't reviewed it carefully.
Hence I removed it from -next, and hope to have some time to convert iomap
soon.

Thanks,

> 
> -- 
> Jens Axboe