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: <f7408161-eaef-47ed-8810-8c4e8f27bfc6@vivo.com>
Date: Wed, 16 Jul 2025 11:34:55 +0800
From: hanqi <hanqi@...o.com>
To: Jens Axboe <axboe@...nel.dk>, 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



在 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.

[1] https://lore.kernel.org/all/137c0a07-ea0a-48fa-acc4-3e0ec63681f4@vivo.com/

>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ