Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
Quoting Theodore Ts'o (2015-01-23 16:25:11) On Thu, Jan 22, 2015 at 07:41:10PM +0100, Justus Winter wrote: I can accept that you do not care about the Hurd, but I feel deeply saddened by the fact that you appreciate my effort to improve the software you maintain so little. Sorry, this e-mail thread got lost in my inbox. Thanks for the ping. I've applied your patch to the e2fsprogs git tree; it will be in the next release of e2fsprogs. Cool, many thanks :) Justus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
On Thu, Jan 22, 2015 at 07:41:10PM +0100, Justus Winter wrote: I can accept that you do not care about the Hurd, but I feel deeply saddened by the fact that you appreciate my effort to improve the software you maintain so little. Sorry, this e-mail thread got lost in my inbox. Thanks for the ping. I've applied your patch to the e2fsprogs git tree; it will be in the next release of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
Hello, Quoting Justus Winter (2014-09-02 19:22:57) Quoting Theodore Ts'o (2014-09-02 18:56:58) Probably not. We can switch to the Linux on-disk format once we can store all Hurdish stuff in extended attributes though. Hm. When you do this, it would be good to simply stop using EXT4_OS_HURD in the superblock, Sure, that's the idea. But... since we have a bunch of workarounds keyed off of that, and your patch will add another --- and I'm planning on adding still more to make sure a user doesn't accidentally turn on some ext4 features via mke2fs or tune2fs that use fields that the Hurd is using for its own nefarious purposes. Otherwise, the usage clash would lead to no good If an e2fsprog or Linux uses the Linux specific stuff of the OS dependent fields without verifying the creator OS, then this is a bug. Fixing such a bug is no workaround. I can accept that you do not care about the Hurd, but I feel deeply saddened by the fact that you appreciate my effort to improve the software you maintain so little. Justus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
Package: e2fsprogs
Version: 1.42.12-1
Severity: normal
Tags: patch
Dear Maintainer,
e2fsck accesses the field osd2.linux2.l_i_file_acl_high field without
checking that the filesystem is indeed created for Linux. This leads
to e2fsck constantly complaining about certain nodes:
i_file_acl_hi for inode XXX (/dev/console) is 32, should be zero.
By correcting this problem, e2fsck clobbers the field
osd2.hurd2.h_i_mode_high.
A patch is attached that properly guards access to the OS dependent
fields.
Thanks,
Justus
-- System Information:
Debian Release: jessie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hurd-i386 (i686-AT386)
Kernel: GNU-Mach 1.4-486-dbg/Hurd-0.5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages e2fsprogs depends on:
ii e2fslibs1.42.11-1
ii libblkid1 2.20.1-5.8
ii libc0.3 2.19-10
ii libcomerr2 1.42.11-1
ii libss2 1.42.11-1
ii libuuid12.20.1-5.8
ii util-linux 2.20.1-5.8
e2fsprogs recommends no packages.
Versions of packages e2fsprogs suggests:
pn e2fsck-static none
pn gpart none
pn parted none
-- no debconf information
From be14c28db9db5c528ebb746259ebe6957761f559 Mon Sep 17 00:00:00 2001
From: Justus Winter 4win...@informatik.uni-hamburg.de
Date: Tue, 2 Sep 2014 12:55:53 +0200
Subject: [PATCH] e2fsck: fix corruption of Hurd filesystems
Previously, e2fsck accessed the field osd2.linux2.l_i_file_acl_high
field without checking that the filesystem is indeed created for
Linux. This lead to e2fsck constantly complaining about certain
nodes:
i_file_acl_hi for inode XXX (/dev/console) is 32, should be zero.
By correcting this problem, e2fsck would clobber the field
osd2.hurd2.h_i_mode_high.
Properly guard access to the OS dependent fields.
---
e2fsck/pass1.c | 14 --
e2fsck/pass2.c | 3 ++-
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 50a8b99..3bf481f 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1082,7 +1082,8 @@ void e2fsck_pass1(e2fsck_t ctx)
if (inode-i_faddr || frag || fsize ||
(LINUX_S_ISDIR(inode-i_mode) inode-i_dir_acl))
mark_inode_bad(ctx, ino);
- if (!(fs-super-s_feature_incompat
+ if ((fs-super-s_creator_os == EXT2_OS_LINUX)
+ !(fs-super-s_feature_incompat
EXT4_FEATURE_INCOMPAT_64BIT)
inode-osd2.linux2.l_i_file_acl_high != 0)
mark_inode_bad(ctx, ino);
@@ -2354,11 +2355,12 @@ static void check_blocks(e2fsck_t ctx, struct problem_context *pctx,
if (LINUX_S_ISREG(inode-i_mode)
ext2fs_needs_large_file_feature(EXT2_I_SIZE(inode)))
ctx-large_files++;
- if ((pb.num_blocks != ext2fs_inode_i_blocks(fs, inode)) ||
- ((fs-super-s_feature_ro_compat
- EXT4_FEATURE_RO_COMPAT_HUGE_FILE)
- (inode-i_flags EXT4_HUGE_FILE_FL)
- (inode-osd2.linux2.l_i_blocks_hi != 0))) {
+ if ((fs-super-s_creator_os == EXT2_OS_LINUX)
+ ((pb.num_blocks != ext2fs_inode_i_blocks(fs, inode)) ||
+ ((fs-super-s_feature_ro_compat
+ EXT4_FEATURE_RO_COMPAT_HUGE_FILE)
+ (inode-i_flags EXT4_HUGE_FILE_FL)
+ (inode-osd2.linux2.l_i_blocks_hi != 0 {
pctx-num = pb.num_blocks;
if (fix_problem(ctx, PR_1_BAD_I_BLOCKS, pctx)) {
inode-i_blocks = pb.num_blocks;
diff --git a/e2fsck/pass2.c b/e2fsck/pass2.c
index 2b7bff4..143cf38 100644
--- a/e2fsck/pass2.c
+++ b/e2fsck/pass2.c
@@ -1364,7 +1364,8 @@ int e2fsck_process_bad_inode(e2fsck_t ctx, ext2_ino_t dir,
}
}
- if (!(fs-super-s_feature_incompat
+ if ((fs-super-s_creator_os == EXT2_OS_LINUX)
+ !(fs-super-s_feature_incompat
EXT4_FEATURE_INCOMPAT_64BIT)
inode.osd2.linux2.l_i_file_acl_high != 0) {
pctx.num = inode.osd2.linux2.l_i_file_acl_high;
--
2.1.0
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
On Tue, Sep 02, 2014 at 01:59:34PM +0200, 4win...@informatik.uni-hamburg.de wrote: Package: e2fsprogs Version: 1.42.12-1 Severity: normal Tags: patch Dear Maintainer, e2fsck accesses the field osd2.linux2.l_i_file_acl_high field without checking that the filesystem is indeed created for Linux. This leads to e2fsck constantly complaining about certain nodes: i_file_acl_hi for inode XXX (/dev/console) is 32, should be zero. By correcting this problem, e2fsck clobbers the field osd2.hurd2.h_i_mode_high. Interesting; is this a field that hurd has recently started using? (We've had this check in e2fsck for 4 years, when we added support for 64-bit file systems.) If so, for what? And did the hurd developer who started using this field realize he has foreclosed the use of file systems larger than 16TB on the hurd? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
Quoting Theodore Ts'o (2014-09-02 15:50:14) On Tue, Sep 02, 2014 at 01:59:34PM +0200, 4win...@informatik.uni-hamburg.de wrote: Package: e2fsprogs Version: 1.42.12-1 Severity: normal Tags: patch Dear Maintainer, e2fsck accesses the field osd2.linux2.l_i_file_acl_high field without checking that the filesystem is indeed created for Linux. This leads to e2fsck constantly complaining about certain nodes: i_file_acl_hi for inode XXX (/dev/console) is 32, should be zero. By correcting this problem, e2fsck clobbers the field osd2.hurd2.h_i_mode_high. Interesting; is this a field that hurd has recently started using? (We've had this check in e2fsck for 4 years, when we added support for 64-bit file systems.) No. It has been used at least since 1996. Amazingly this seems to have no ill effect other than to make e2fsck complain constantly. If so, for what? It seems to store more mode bits. And did the hurd developer who started using this field realize he has foreclosed the use of file systems larger than 16TB on the hurd? Probably not. We can switch to the Linux on-disk format once we can store all Hurdish stuff in extended attributes though. Thanks, Justus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
On Tue, Sep 02, 2014 at 06:25:19PM +0200, Justus Winter wrote: No. It has been used at least since 1996. Amazingly this seems to have no ill effect other than to make e2fsck complain constantly. Interesting; I was wondering why no one had complained until now. Probably not. We can switch to the Linux on-disk format once we can store all Hurdish stuff in extended attributes though. Hm. When you do this, it would be good to simply stop using EXT4_OS_HURD in the superblock, since we have a bunch of workarounds keyed off of that, and your patch will add another --- and I'm planning on adding still more to make sure a user doesn't accidentally turn on some ext4 features via mke2fs or tune2fs that use fields that the Hurd is using for its own nefarious purposes. Otherwise, the usage clash would lead to no good - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760275: e2fsprogs: e2fsck corrupts Hurd filesystems
Quoting Theodore Ts'o (2014-09-02 18:56:58) Probably not. We can switch to the Linux on-disk format once we can store all Hurdish stuff in extended attributes though. Hm. When you do this, it would be good to simply stop using EXT4_OS_HURD in the superblock, Sure, that's the idea. But... since we have a bunch of workarounds keyed off of that, and your patch will add another --- and I'm planning on adding still more to make sure a user doesn't accidentally turn on some ext4 features via mke2fs or tune2fs that use fields that the Hurd is using for its own nefarious purposes. Otherwise, the usage clash would lead to no good If an e2fsprog or Linux uses the Linux specific stuff of the OS dependent fields without verifying the creator OS, then this is a bug. Fixing such a bug is no workaround. Cheers, Justus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
