On Fri, Jan 17, 2020 at 10:23 AM Deepa Dinamani deepa.kernel@gmail.com wrote:
On Fri, Jan 17, 2020 at 1:09 AM Amir Goldstein amir73il@gmail.com wrote:
I understand why you dislike the ext2+loop test, but please hear me out.
From all the fs types that are supported by the test, only btrfs and ext4 with large inode size are y2038 ready. For the rest of the cases, we actually have a way to detect kernel support from the dmesg warning, without the need for hacky ext2 loop mount.
So how about just:
- moving _scratch_mount before _require_timestamp_range
- in _require_timestamp_range (untested): if [ $tsmax -lt $((1<<32)) ] && ! _check_dmesg_for "supports
Yeah, this looks fine. I thought about searching for dmesg warning after _scratch_mount as well, but that would _notrun if the fs is 2038-safe. This $tsmax check fixes my concern. Thanks!
Deepa,
Do you intend to post the simplified version or would you like me to re-spin your patch?
I intend to do this. Sorry, was distracted by other things. FWIW, just (1<<32) is not enough. The kernel prints this warning based on (current time + max uptime) <= tsmax. Will post this.
Also we are testing for the following timestamps in the test:
declare -a TIMESTAMPS=( $tsmin 0 $tsmax $((tsmax/2)) $((tsmax+1)) )
So the test can still fail if the above tsmax test passes, but the limit patches are not in the kernel. https://lkml.org/lkml/2019/7/29/1850 has the limits for all the filesystems I filled in. fat, cifs, hpfs etc. all fall in this category.
I do not see a good way of doing this unless we test for a fs that always fails in a predictable way.
Checking for fsinfo maybe is ok. But, at that point we could just rely on any syscall that got merged after the limits series isn't it?
-Deepa