linux-kernel - Re: [PATCH] f2fs: f2fs supports uncached buffered I/O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51168786-6c30-4065-be82-6d07b2ae74a8@kernel.dk>
Date: Tue, 15 Jul 2025 21:43:33 -0600
From: Jens Axboe <axboe@...nel.dk>
To: hanqi <hanqi@...o.com>, jaegeuk@...nel.org, chao@...nel.org
Cc: linux-f2fs-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] f2fs: f2fs supports uncached buffered I/O

On 7/15/25 9:34 PM, hanqi wrote:
> 
> 
> ? 2025/7/15 22:28, Jens Axboe ??:
>> On 7/14/25 9:10 PM, Qi Han wrote:
>>> Jens has already completed the development of uncached buffered I/O
>>> in git [1], and in f2fs, the feature can be enabled simply by setting
>>> the FOP_DONTCACHE flag in f2fs_file_operations.
>> You need to ensure that for any DONTCACHE IO that the completion is
>> routed via non-irq context, if applicable. I didn't verify that this is
>> the case for f2fs. Generally you can deduce this as well through
>> testing, I'd say the following cases would be interesting to test:
>>
>> 1) Normal DONTCACHE buffered read
>> 2) Overwrite DONTCACHE buffered write
>> 3) Append DONTCACHE buffered write
>>
>> Test those with DEBUG_ATOMIC_SLEEP set in your config, and it that
>> doesn't complain, that's a great start.
>>
>> For the above test cases as well, verify that page cache doesn't grow as
>> IO is performed. A bit is fine for things like meta data, but generally
>> you want to see it remain basically flat in terms of page cache usage.
>>
>> Maybe this is all fine, like I said I didn't verify. Just mentioning it
>> for completeness sake.
> 
> Hi, Jens
> Thanks for your suggestion. As I mentioned earlier in [1], in f2fs,
> the regular buffered write path invokes folio_end_writeback from a
> softirq context. Therefore, it seems that f2fs may not be suitable
> for DONTCACHE I/O writes.
> 
> I?d like to ask a question: why is DONTCACHE I/O write restricted to
> non-interrupt context only? Is it because dropping the page might be
> too time-consuming to be done safely in interrupt context? This might
> be a naive question, but I?d really appreciate your clarification.
> Thanks in advance.

Because (as of right now, at least) the code doing the invalidation
needs process context. There are various reasons for this, which you'll
see if you follow the path off folio_end_writeback() ->
filemap_end_dropbehind_write() -> filemap_end_dropbehind() ->
folio_unmap_invalidate(). unmap_mapping_folio() is one case, and while
that may be doable, the inode i_lock is not IRQ safe.

Most file systems have a need to punt some writeback completions to
non-irq context, eg for file extending etc. Hence for most file systems,
the dontcache case just becomes another case that needs to go through
that path.

It'd certainly be possible to improve upon this, for example by having
an opportunistic dontcache unmap from IRQ/soft-irq context, and then
punting to a workqueue if that doesn't pan out. But this doesn't exist
as of yet, hence the need for the workqueue punt.

-- 
Jens Axboe