From: Eryu Guan <guaneryu@gmail.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
fstests <fstests@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Greg KH <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>
Subject: Re: [PATCH v2] generic/402: Make timestamp range check conditional
Date: Wed, 8 Jan 2020 17:50:21 +0800 [thread overview]
Message-ID: <20200108095021.GH893866@desktop> (raw)
In-Reply-To: <CAOQ4uxhOGZfLch1HDFACD9fLczpLHxVMoY50ZyJDOyAJBp-WyQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2020-01-08 9:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 4:12 [PATCH] generic/402: fix for updated behavior of timestamp limits Deepa Dinamani
2019-07-21 16:47 ` Eryu Guan
2019-10-02 22:06 ` Deepa Dinamani
2019-10-05 18:35 ` Eryu Guan
2019-10-23 22:17 ` Deepa Dinamani
2019-12-12 13:11 ` Amir Goldstein
2019-12-12 21:55 ` Deepa Dinamani
2019-12-18 20:21 ` Deepa Dinamani
2019-12-18 20:46 ` Amir Goldstein
2019-12-19 8:28 ` [Y2038] " Arnd Bergmann
2019-12-19 8:40 ` Greg KH
2019-12-19 11:29 ` Arnd Bergmann
2019-12-19 11:35 ` Greg KH
2019-12-19 15:48 ` Ben Hutchings
2019-12-19 20:35 ` Arnd Bergmann
2019-12-19 12:09 ` Amir Goldstein
2019-12-20 22:45 ` Deepa Dinamani
2019-12-23 5:16 ` [PATCH] generic/402: Make timestamp range check conditional Deepa Dinamani
2019-12-23 6:36 ` Amir Goldstein
2019-12-24 1:15 ` Deepa Dinamani
2019-12-28 22:13 ` [PATCH v2] " Deepa Dinamani
2019-12-30 7:34 ` Amir Goldstein
2020-01-03 6:46 ` Deepa Dinamani
2020-01-03 9:58 ` Amir Goldstein
2020-01-08 8:09 ` Eryu Guan
2020-01-08 8:45 ` Amir Goldstein
2020-01-08 9:50 ` Eryu Guan [this message]
2020-01-17 9:09 ` Amir Goldstein
2020-01-17 18:23 ` Deepa Dinamani
2020-01-17 19:01 ` Deepa Dinamani
2020-01-19 0:57 ` [PATCH v3 1/1] " Deepa Dinamani
2020-01-19 9:19 ` Amir Goldstein
2020-02-01 9:14 ` Eryu Guan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200108095021.GH893866@desktop \
--to=guaneryu@gmail.com \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=sashal@kernel.org \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).