Re: [Y2038] [PATCH v2] generic/402: Make timestamp range check conditional

On Wed, Jan 08, 2020 at 10:45:29AM +0200, Amir Goldstein wrote:

On Wed, Jan 8, 2020 at 10:09 AM Eryu Guan guaneryu@gmail.com wrote:

...

On Mon, Dec 30, 2019 at 09:34:47AM +0200, Amir Goldstein wrote:

...

On Sun, Dec 29, 2019 at 12:13 AM Deepa Dinamani deepa.kernel@gmail.com wrote:

...

Addition of fs-specific timestamp range checking was added in 188d20bcd1eb ("vfs: Add file timestamp range support").

Add a check for whether the kernel supports the limits check before running the associated test.

ext4 has been chosen to test for the presence of kernel support for this feature. If there is a concern that ext4 could be built out of the kernel, I can include a _require_ext4() along the lines of _require_ext2().

Suggested-by: Amir Goldstein amir73il@gmail.com Signed-off-by: Deepa Dinamani deepa.kernel@gmail.com

Sorry for chiming in so late..

...

...

---

• Changes since v1: used loopback device instead of mkfs scratch dev

common/rc | 26 ++++++++++++++++++++++++++ tests/generic/402 | 3 +++ 2 files changed, 29 insertions(+)

diff --git a/common/rc b/common/rc index 816588d6..6248adf7 100644 --- a/common/rc +++ b/common/rc @@ -1981,6 +1981,32 @@ _run_aiodio() return $status }

+_require_kernel_timestamp_range() +{

•   LOOP_FILE=$SCRATCH_MNT/loop_file
  

•   LOOP_MNT=$SCRATCH_MNT/loop_mnt
  

•   dd if=/dev/zero of=$LOOP_FILE bs=1M count=2 2>&1 | _filter_dd || _fail "loopback prep failed"
  

•   # Use ext4 with 128-byte inodes, which do not have room for extended timestamp
  

•   FSTYP=ext4 MKFS_OPTIONS=-I128 \
  

•   _mkfs_dev $LOOP_FILE >> $seqres.full 2>&1 || _fail "ext4 mkfs failed"
  

•   LOOP_DEV=$(_create_loop_device $LOOP_FILE)
  

•   mkdir -p $LOOP_MNT >> $seqres.full 2>&1 || _fail "failed to create $LOOP_MNT"
  

•   mount -t ext4 ${LOOP_DEV} ${LOOP_MNT} >> $seqres.full 2>&1 || _fail "ext4 mount failed"
  

•   notrun=false
  

•   _check_dmesg_for "ext4 filesystem being mounted at ${LOOP_MNT} supports timestamps until 2038" || \
  

•           notrun=true
  

•   umount ${LOOP_MNT} >> $seqres.full 2>&1 ||_fail "failed to umount $LOOP_MNT"
  

•   _destroy_loop_device ${LOOP_DEV} >> $seqres.full 2>&1
  

•   if $notrun; then
  

•           _notrun "Kernel does not support timestamp limits"
  

•   fi
  

+}

As a generic helper, this function has a few problems:

1. It assumes scratch dev is mounted (and you're not even calling it

after _scratch_mount) 2. The cleanup() hook won't clean loop mnt/dev if interrupted 3. test doesn't have _require_loop (nor require ext4 as you mentioned)

All this leads me to think that perhaps it would be better off, at least until kernel has fsinfo, to keep this entire helper inside generic/402, while addressing the issues above in the test itself.

A more generic solution would be harder and IMO and overkill at this point.

What do you think?

After reading through this thread, I prefer waiting for the comming fsinfo interface, detecting the timestamp limit support using ext2 & loop device doesn't look "pretty" and is just a temporary solution.

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:

1. moving _scratch_mount before _require_timestamp_range
2. 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!

Eryu

timestamps until 2038" ; then _notrun "Kernel does not support timestamp limits" fi

It's better than nothing and it does not add much complications, nor is this "hacky" IMO.

Thoughts?

Amir.