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 for Android: free password hash cracker in your pocket

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

Message-ID: <f8ab5bbf-79b0-42ac-9c61-d906593b5d8f@kernel.org>
Date: Tue, 5 Aug 2025 09:32:05 +0800
From: Chao Yu <chao@...nel.org>
To: Jens Axboe <axboe@...nel.dk>, hanqi <hanqi@...o.com>, jaegeuk@...nel.org
Cc: chao@...nel.org, linux-f2fs-devel@...ts.sourceforge.net,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] f2fs: f2fs supports uncached buffered I/O read

On 8/2/25 23:35, Jens Axboe wrote:
> 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.

Sure, let's wait for dontcache support in both read&write side, unless something
is blocked in write side, let's see. :)

Thanks,

>