linux-kernel - Re: [RFC NO MERGE] f2fs: extent cache: support unaligned extent

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: <a8291159-f625-c2a0-da73-7c30172f3d9a@kernel.org>
Date:   Tue, 3 Aug 2021 09:29:34 +0800
From:   Chao Yu <chao@...nel.org>
To:     Jaegeuk Kim <jaegeuk@...nel.org>
Cc:     linux-f2fs-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org, Chao Yu <chao.yu@...ux.dev>
Subject: Re: [RFC NO MERGE] f2fs: extent cache: support unaligned extent

On 2021/8/3 9:25, Jaegeuk Kim wrote:
> On 08/03, Chao Yu wrote:
>> On 2021/8/3 2:03, Jaegeuk Kim wrote:
>>> On 08/01, Chao Yu wrote:
>>>> On 2021/7/31 3:20, Jaegeuk Kim wrote:
>>>>> On 07/07, Chao Yu wrote:
>>>>>> Currently, it only works in readonly format f2fs image.
>>>>
>>>> There wouldn't be any race condition because unaligned extent only works
>>>> for ro feature now?
>>>
>>> Isn't your patch proposing on writable partition?
>>
>> Please check description in patch message, now it was designed only for
>                                                   --
>                                                   what do you refer "it"?
> 
>> compression case w/ ro feature, let's check and support rw partition later.
> 
> Quite confused the patch description and code changes as well. You added some
> change with this as well which is for RW.
> 
> +       if (is_inode_flag_set(dn->inode, FI_COMPRESSED_FILE) &&
> +                       !f2fs_sb_has_readonly(sbi)) {

My bad, I've updated in my dev branch, but forgot to resend it...:

https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git/commit/?h=dev&id=c3a40f6a186ba064f95432b308173d0a8fe375dc

Thanks,

> 
>>
>> Thanks,
>>
>>>
>>>>
>>>>> Is there any race condition between the address in extent_cache and the one in
>>>>> dnode? I feel that we could synchronize it by locking its dnode block.
>>>>
>>>> Thanks,