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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 26 Oct 2020 15:57:10 +0100 From: Jan Kara <jack@...e.cz> To: linux-fsdevel@...r.kernel.org Cc: linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, Matthew Wilcox <willy@...radead.org> Subject: Strange SEEK_HOLE / SEEK_DATA behavior Hello! When reviewing Matthew's THP patches I've noticed one odd behavior which got copied from current iomap seek hole/data helpers. Currently we have: # fallocate -l 4096 testfile # xfs_io -x -c "seek -h 0" testfile Whence Result HOLE 0 # dd if=testfile bs=4096 count=1 of=/dev/null # xfs_io -x -c "seek -h 0" testfile Whence Result HOLE 4096 So once we read from an unwritten extent, the areas with cached pages suddently become treated as data. Later when pages get evicted, they become treated as holes again. Strictly speaking I wouldn't say this is a bug since nobody promises we won't treat holes as data but it looks weird. Shouldn't we treat clean pages over unwritten extents still as holes and only once the page becomes dirty treat is as data? What do other people think? Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists