linux-ext4 - How much do we care about building e2fsprogs on Solaris?

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>] [day] [month] [year] [list]

Message-ID: <20191110045206.GG23325@mit.edu>
Date:   Sat, 9 Nov 2019 23:52:06 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     linux-ext4@...r.kernel.org, harshads@...gle.com
Subject: How much do we care about building e2fsprogs on Solaris?

Hey Darrick,

I'm thinking about reverting the following commit, which was
introduced over a decade ago for better Solaris portability.

commit 1911bf113ef0f9c71090f26279e4a4082fae0abc
Author: Theodore Ts'o <tytso@....edu>
Date:   Sun Jul 13 08:04:36 2008 -0400

    e2fsck: Change kmem_cache_t to lkmem_cache_t for Solaris

    Solaris polutes the C namespace with kmem_cache_t when
        you include in/netinet.h is included, so rename kmem_cache_t
	    to lkmem_cache_t.

    Signed-off-by: "Theodore Ts'o" <tytso@....edu>

I've been working on getting e2fsck/{recovery.c,revoke.c} better
sync'ed up with the kernel versions of these files.  See the next
branch on e2fsprogs.git for my work in this area, in particular
commits 71030cf8^..46e1286a

One of the last remaining deltas is a hack to rename kmem_cache_t to
lkmem_cache_t, to work around the above described a Solaris bug.
There is a shell script, contrib/jbd2-resync.sh which we use to try to
things in sync, but it is a bit of a pain.

So this brings up two questions, which I suspect you're uniquely
qualified to answer:

(a) Does Solaris still have this namespace leakage bug in
<in/netinet.h>, such that e2fsprogs would fail to compile on Solaris
if we were to revert this commit?

(b) If Solaris still has this bug, after a over decade, do we care?
These days, Solaris doesn't seem to have much salience other than
being a program loader for a certain enterprise database, and I'm very
interested in trying to reduce the maintenance burden of keeping these
two files from fs/jbd2 in sync with the kernel, without having to put
some awful hacks on the kernel side.

					- Ted

P.S.  There are some changes that were made on the e2fsprogs side,
mostly to clean up some UBSan issues, but there's a spelling fix in a
comment and a few other miscellaneous things where the right fix is to
migrate the patch from e2fsprogs to the kernel.  Harshad is going to
work on that, in preparation for his next version of the fast commit
patches, and then getting those changes supported in e2fsprogs.

I believe I've migrated all of the improvements from the kernel's
versions of fs/jbd2/{recovery,revoke}.c to e2fsprogs, to make
Harshad's job simpler.