linux-ext4 - Re: [PATCH] ext4: kill i_version support for Hurd-castrated file systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Mar 2014 10:44:56 -0400
From:	tytso@....edu
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"1o5g4r8o@...il.com" <1o5g4r8o@...il.com>,
	"738758@...s.debian.org" <738758@...s.debian.org>
Subject: Re: [PATCH] ext4: kill i_version support for Hurd-castrated file
 systems

On Thu, Mar 20, 2014 at 01:10:48AM -0700, Christoph Hellwig wrote:
> On Wed, Mar 19, 2014 at 11:27:57PM -0600, Andreas Dilger wrote:
> > Probably worthwhile to make those !EXT4_OS_HURD checks likely()?

Yes, and I was planning on optimizing the checks a bit more, but it
makes sense to do that in a separate patch, since this is not the only
place where we are making EXT4_OS_HURD checks.

> 
> Does it make sense to support the format at all given that it's unlikely
> to get any testing?

There are some crazy people still trying to make the Hurd a viable
file system.  There's even a Debian port for it.  :-) The problem is
that some of the folks who are still trying to make the Hurd real want
to use ext2 as an interchange format between Linux and Hurd, and
presumably that's how they ran across this particular bug.

While I think Hurd is a joke, and it's laughable that the primary file
system for the Hurd doesn't support journalling, or extents, delayed
allocation, or extended attributes[1], and it's hard for them get feature
parity because of the GPL v3 vs v2 compatibility problem, I don't mind
making minimal efforts to provide legacy support to the GNU Hurd.

[1] http://savannah.gnu.org/patch/?5126 (Patches available for the last
      seven years, not yet integrated)

In the long run, the right answer is that the Hurd should use an
extended attribute to store the translator information.  Indeed, this
has been discussed seven years ago[2].  But unfortunately, the
development temp for Hurd is a wee bit slower than for the Linux
kernel.  :-)

[2] http://savannah.gnu.org/task/?5503

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html