Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]
On Thu, May 20, 2021 at 05:55:34PM +0200, Cyril Brulebois wrote:
> Paul Gevers <elbrus@debian.org> (2021-05-20):
> > On 20-05-2021 00:11, Theodore Y. Ts'o wrote:
> >
> > Unfortunately, there was no release.debian.org bug to track this. Due
> > to the current high volume to our list, this fell from the radar. To
> > avoid this I now generate a pre-approval unblock request to discuss
> > this, because than it shows up in our tools. Please follow up there.
>
> Yes, and I see a question was raised for the Installer team but
> debian-boot@ wasn't cc'd, and we aren't psychic. :)
My apologies for not getting the process right by opening a
pre-approval bug earlier!
> > Can you elaborate where you see the *risks* of the patch? Is this
> > patch backwards compatible? I.e. does it work correctly on data
> > generated with the old e2fsprogs? If not, what must the user do to
> > avoid issues? Should it be mentioned in the release notes?
That patch is rather long, but it's all mostly of the form:
- tail = (struct ext4_fc_tail *)ext4_fc_tag_val(tl);
+ memcpy(&tail, ext4_fc_tag_val(tl), sizeof(tail));
So the risks are very low.
> > Apart from the failing test cases, I see in the patch description that
> > there's also real use cases impacted (corner cases if I interpret them
> > right). IIUC these are no regressions but I'd like to be sure. And
> > what's the impact for users of those corner cases (especially the new
> > Linux feature, I would expect that some users would be going to use
> > those).
Ext4 fast commits is a relatively new feature which is not enabled by
mke2fs by default. It's a pretty cool feature in that in can result
in some very impressive performance increases (75-130% improvements on
some benchmarks), but there are still some rough edges. So in general
it's not something that an "enterprise distro" would be supporting,
although I imagine there will be some intrepid Debian Stable users who
might want to try using it.
The real world corner cases are if you are using a 32-bit arm binary
on a 64-bit binary, and if you are using a sparc64 system (not an
officially supported Debian arch). I'm not sure if misaligned pointer
accesses are allowed in arm-32 kernel code, but it's definitely not
supported on sparc64, so there is also a kernel-side patch which
needed for those platforms that will be in 5.13 (landing upstream in
2-3 weeks).
There are number of other minor bug fixes that I might want to include
at the same time, but none of them are ones that I can honestly call
"release-critical". Perhaps the one that I would want to pull in, and
which is very low risk is:
libext2fs: fix missing mutex unlock in an error path of the Unix I/O manager
Originally from https://github.com/tytso/e2fsprogs/pull/68
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cheers,
- Ted
Reply to: