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] [day] [month] [year] [list]

Message-ID: <e163bbcd-b4d7-4a76-a42f-950f3cb5a644@kernel.dk>
Date: Sat, 2 Aug 2025 09:35:13 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Chao Yu <chao@...nel.org>, hanqi <hanqi@...o.com>, 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/30/25 8:35 PM, Chao Yu wrote:
> On 7/30/25 23:20, Jens Axboe wrote:
>> 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.
> 
> Jens,
> 
> Do you mean like what we have done in kiocb_set_rw_flags()?
> 
> 	if (flags & RWF_DONTCACHE) {
> 		/* file system must support it */
> 		if (!(ki->ki_filp->f_op->fop_flags & FOP_DONTCACHE))
> 			return -EOPNOTSUPP;
> ...
> 	}
> 
> IIUC, it's better to have this in original patch, let me know if I'm
> missing something.

Right, that would certainly be required to have it functional on the
read side but not yet on the write side. Still leaves a weirder gap
where other file systems (like XFS and ext4) you can rely on if read or
write support is there, then the other direction is supported too. f2fs
would be the only one where the read side works, but you get -EOPNOTSUPP
on the write side.

Unless there's a rush on the read side for some reason, I think it'd be
better to have with setting FOP_DONTCACHE until the write side has been
completed too.

-- 
Jens Axboe