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
| ||
|
Message-ID: <01e6abf4-3ae5-ecab-3b7f-876c8a3fcbb4@sjtu.edu.cn> Date: Fri, 5 Nov 2021 13:28:10 +0800 From: Zhongwei Cai <sunrise_l@...u.edu.cn> To: Dave Chinner <david@...morbit.com> Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, mingkaidong@...il.com Subject: Re: [PATCH] ext4: remove unnecessary ext4_inode_datasync_dirty in read path On 11/5/21 7:22 AM, Dave Chinner wrote: > > No. Some filesystems don't track inode metadata dirty status using > the VFS inode; instead they track it more efficiently in internal > inode and/or journal based structures. Hence the only way to get > "inode needs journal flush for data stability" information to > generic IO code is to have a specific per-IO mapping flag for it. > Could we add IOMAP_REPORT_DIRTY flag in the flags field of struct iomap_iter to indicate whether the IOMAP_F_DIRTY flag needs to be set or not? Currently the IOMAP_F_DIRTY flag is only checked in iomap_swapfile_activate(), dax_iomap_fault() and iomap_dio_rw() (To be more specific, only the write path in dax_iomap_fault() and iomap_dio_rw()). So it would be unnecessary to set the IOMAP_F_DIRTY flag in dax_iomap_rw() called in the previous tests. Other file systems that set the IOMAP_F_DIRTY flag efficiently could ignore the IOMAP_REPORT_DIRTY flag. Best, Zhongwei.
Powered by blists - more mailing lists