From: Andreas Dilger Subject: Re: [PATCH v4 2/2] e2fsck: Correct ext4 dates generated by old kernels. Date: Wed, 13 Nov 2013 00:56:25 -0700 Message-ID: <276FA06E-1EE0-4FB4-94E1-B6D9F05F0B5B@dilger.ca> References: <1383808590.23882.13.camel@chiang> <20131107160341.GA3850@quack.suse.cz> <1383864864.23882.33.camel@chiang> <20131107231445.GG2054@quack.suse.cz> <1383866807.23882.41.camel@chiang> <1383981551.8994.27.camel@chiang> <1384070214.8994.47.camel@chiang> <20131112003018.GA30281@thunk.org> <6DE0AF86-98E6-4DE9-BB7F-40FB32E1BC26@dilger.ca> <1384326020.8994.186.camel@chiang> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_18ECBB39-8567-442B-8E5A-7C599162FACF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Cc: Theodore Ts'o , Mark Harris , Jan Kara , Ext4 Developers List , Linux Kernel Mailing List To: David Turner Return-path: Received: from mail-pa0-f44.google.com ([209.85.220.44]:37246 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756253Ab3KMH4a (ORCPT ); Wed, 13 Nov 2013 02:56:30 -0500 Received: by mail-pa0-f44.google.com with SMTP id hz1so54421pad.3 for ; Tue, 12 Nov 2013 23:56:29 -0800 (PST) In-Reply-To: <1384326020.8994.186.camel@chiang> Sender: linux-ext4-owner@vger.kernel.org List-ID: --Apple-Mail=_18ECBB39-8567-442B-8E5A-7C599162FACF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 13, 2013, at 12:00 AM, David Turner wrote: > This patch is against e2fsprogs. >=20 > --- > Older kernels on 64-bit machines would incorrectly encode pre-1970 > ext4 dates as post-2311 dates. Detect and correct this (assuming the > current date is before 2311). >=20 > Signed-off-by: David Turner > --- > e2fsck/pass1.c | 37 +++++++++++++++++++++++++++++++++++++ > e2fsck/problem.c | 7 +++++++ > e2fsck/problem.h | 6 ++++++ > 3 files changed, 50 insertions(+) >=20 > diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c > index ab23e42..cb72964 100644 > --- a/e2fsck/pass1.c > +++ b/e2fsck/pass1.c > @@ -348,6 +348,23 @@ fix: > EXT2_INODE_SIZE(sb), "pass1"); > } >=20 > +#define EXT4_EPOCH_BITS 2 > +#define EXT4_EPOCH_MASK ((1 << EXT4_EPOCH_BITS) - 1) > + > +static int large_inode_extra(__u32 xtime, __u32 extra) { =93large_inode_extra()=94 doesn=92t really describe the purpose of this = function very well, which is checking the timestamps to have large future (or past) = dates. How about a more descriptive name =93check_old_ext4_negative_epoch()=94 = or maybe =93check_inode_extra_negative_epoch()=94 or something like that? > + return (xtime & (1 << 31)) !=3D 0 && > + (extra & EXT4_EPOCH_MASK) =3D=3D EXT4_EPOCH_MASK; > +} > + > +#define LARGE_INODE_EXTRA(inode, xtime) \ Ditto. > + large_inode_extra(inode->i_##xtime, \ > + inode->i_##xtime##_extra) > + > +/* When the date is earlier than 2311, we assume that atimes, ctimes, > + * and mtimes greater than 2311 are actually pre-1970 dates = mis-encoded. I like the idea of checking the current date, so that there isn=92t a = need to revert this code at some point in the future. I=92m wondering if there = should be a margin, like =93When the current date is earlier than 2240 we = assume ... times greater than 2311 are actually ...=94? I=92d hope that old = versions of pre-3.14 kernels are not still running by then. > +#define EXT4_EXTRA_NEGATIVE_DATE_CUTOFF 6 * (1UL << 32) That would make this (5 * (1ULL << 32)). I think this should be ULL so = that if there are 64-bit timestamps on 32-bit systems it will still work = correctly. > static void check_inode_extra_space(e2fsck_t ctx, struct = problem_context *pctx) > { > struct ext2_super_block *sb =3D ctx->fs->super; > @@ -388,6 +405,26 @@ static void check_inode_extra_space(e2fsck_t ctx, = struct problem_context *pctx) > /* it seems inode has an extended attribute(s) in body = */ > check_ea_in_inode(ctx, pctx); > } > + > + /* > + * If the inode's extended atime (ctime, mtime) is stored in > + * the old, invalid format, the inode is corrupt. > + */ > + if (sizeof(time_t) > 4 && ctx->now < = EXT4_EXTRA_NEGATIVE_DATE_CUTOFF && > + LARGE_INODE_EXTRA(inode, atime) || > + LARGE_INODE_EXTRA(inode, ctime) || > + LARGE_INODE_EXTRA(inode, mtime)) { (style) please align continued line after =91(=91 of previous line, = otherwise it isn=92t easy to see if these are continuations of the condition or if they are = part of the body of the condition like the lines below. > + if (!fix_problem(ctx, PR_1_EA_TIME_OUT_OF_RANGE, pctx)) > + return; > + > + inode->i_atime_extra &=3D ~EXT4_EPOCH_MASK; > + inode->i_ctime_extra &=3D ~EXT4_EPOCH_MASK; > + inode->i_mtime_extra &=3D ~EXT4_EPOCH_MASK; > + e2fsck_write_inode_full(ctx, pctx->ino, pctx->inode, > + EXT2_INODE_SIZE(sb), "pass1"); > + } > + > } >=20 > /* > diff --git a/e2fsck/problem.c b/e2fsck/problem.c > index 897693a..51fa7c3 100644 > --- a/e2fsck/problem.c > +++ b/e2fsck/problem.c > @@ -1018,6 +1018,13 @@ static struct e2fsck_problem problem_table[] =3D = { > N_("@i %i, end of extent exceeds allowed value\n\t(logical @b = %c, physical @b %b, len %N)\n"), > PROMPT_CLEAR, 0 }, >=20 > +/* The extended a, c, or mtime on this inode is in the far future, > + indicating that it was written with an older, buggy version of the > + kernel on a 64-bit machine */ Please make the comment match the expanded text as closely as possible. Otherwise, it is hard to track down some problem that prints one = message, but uses the crazy @foo encodings and it isn=92t clear what part of = e2fsck generated it. It is fine if it contains more text. > + { PR_1_EA_TIME_OUT_OF_RANGE, > + N_("Extended time on @i %i is in the far future.\n" > + "Assume that it is in fact a pre-1970 date written by an = older, buggy version of Linux?\n"),=20 (style) please align after =91(=91 from previous line and under 80 = columns. That said, I think this message is a bit harsh, since those older, buggy = versions of Linux include all versions running today. I=92d probably make a more = succinct message like: N_(=93Timestamp(s) on @i %i beyond 2033 are likely pre-1970 = dates.\n=94) > + PROMPT_FIX, 0 }, I=92d probably also make this error code =93PROMPT_FIX | PREEN_OK | = PR_NO_OK=94. > diff --git a/e2fsck/problem.h b/e2fsck/problem.h > index ae1ed26..a44f6dd 100644 > --- a/e2fsck/problem.h > +++ b/e2fsck/problem.h > @@ -593,6 +593,12 @@ struct problem_context { > #define PR_1_EXTENT_INDEX_START_INVALID 0x01006D >=20 > #define PR_1_EXTENT_END_OUT_OF_BOUNDS 0x01006E > + > +/* The extended a, c, or mtime on this inode is in the far future, > + indicating that it was written with an older, buggy version of > + the kernel on a 64-bit machine */ > +#define PR_1_EA_TIME_OUT_OF_RANGE 0x01006F Same goes for the comment here - it should contain the exact text of the = printed error message. Cheers, Andreas --Apple-Mail=_18ECBB39-8567-442B-8E5A-7C599162FACF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBUoMwqes+FW+tNA/TAQKDBAf/R8lLCyxqGaPz5iNA8tTuhHe4365tgX9d H9AR5S75OmbkyVRmda9he63ESHYfCJCJsAZWlzKIgUD0Ty/mrVIZh+Q2PtKipkEi OKnH04ktfMrkA45USY0guh8syIQCVzy5q/oQazbGRMYgwIo25LjQ6wkNeUMiI6H9 e6zqtR/oRPyGw98ennTPfipcm3+5OFItKMD6h0c0PlRCOnDMp2p2SXWG2ekSOgit H0mevqWhRiGtJgfqLV91vj0qO3Uqa2BUU8fmRtd3E7L/4bCMlcVj9OONJYsd9Wpn E4nkXffPOCKY5WAHW6IuJr900LN/EYqSNq5DGXJBeN1+L1ExSXlYHQ== =Bpid -----END PGP SIGNATURE----- --Apple-Mail=_18ECBB39-8567-442B-8E5A-7C599162FACF--