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

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: <1b420389-d46b-48ef-aa49-585d84e2710f@kernel.dk>
Date: Wed, 30 Jul 2025 09:20:56 -0600
From: Jens Axboe <axboe@...nel.dk>
To: hanqi <hanqi@...o.com>, Chao Yu <chao@...nel.org>, jaegeuk@...nel.org
Cc: linux-f2fs-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] f2fs: f2fs supports uncached buffered I/O read

On 7/28/25 2:28 AM, hanqi wrote:
> ? 2025/7/28 16:07, Chao Yu ??:
>> On 7/28/25 16:03, hanqi wrote:
>>> ? 2025/7/28 15:38, Chao Yu ??:
>>>
>>>> On 7/25/25 15:53, Qi Han wrote:
>>>>> Jens has already completed the development of uncached buffered I/O
>>>>> in git [1], and in f2fs, uncached buffered I/O read can be enabled
>>>>> simply by setting the FOP_DONTCACHE flag in f2fs_file_operations.
>>>> IIUC, we may suffer lock issue when we call pwritev(.. ,RWF_DONTCACHE)?
>>>> as Jen mentioned in below path, right?
>>>>
>>>> soft-irq
>>>> - folio_end_writeback()
>>>>    - filemap_end_dropbehind_write()
>>>>     - filemap_end_dropbehind()
>>>>      - folio_unmap_invalidate()
>>>>       - lock i_lock
>>>>
>>>> Thanks,
>>> That's how I understand it.
>> So I guess we need to wait for the support RWF_DONTCACHE on write path, unless
>> you can walk around for write path in this patch.
>>
>> Thanks,
> 
> I think the read and write paths can be submitted separately.
> Currently, uncached buffered I/O write requires setting the
> FGP_DONTCACHE flag when the filesystem allocates a folio. In
> f2fs, this is done in the following path:
> 
> - write_begin
>  - f2fs_write_begin
>   - __filemap_get_folio
>   As I understand it, if we don't set the FGP_DONTCACHE flag here, this
> issue shouldn't occur.

It won't cause an issue, but it also won't work in the sense that the
intent is that if the file system doesn't support DONTCACHE, it would
get errored at submission time. Your approach would just ignore the flag
for writes, rather than return -EOPNOTSUPP as would be expected.

You could potentially make it work just on the read side by having the
f2fs write submit side check DONTCACHE on the write side and error them
out.

-- 
Jens Axboe