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
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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