From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: "François Valenduc" <francoisvalenduc@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
James Blanford <jhblanford@gmail.com>,
stable@vger.kernel.org
Subject: Re: Linux 4.14.36
Date: Thu, 26 Apr 2018 13:05:19 -0400 [thread overview]
Message-ID: <20180426170519.GA5965@thunk.org> (raw)
In-Reply-To: <09f17e4a-b813-9dac-2c4a-44246d4e800c@gmail.com>
On Thu, Apr 26, 2018 at 01:36:57PM +0200, Fran�ois Valenduc wrote:
>
> xzcat /boot/initramfs-genkernel-x86_64-4.14.37-rc1 | cpio --list | grep
> crc32
> lib/modules/4.14.37-rc1/kernel/lib/libcrc32c.ko
> 69823 blocs
>
> So the libcrc32 module is included, but crc32c_generic�� is also needed.
So both libcrc32c and ext4 modules both have softdeps in crc32c, which
will drag in either crc32c_generic or crc32c_intel. What initramfs
utilities are you use to generate the initramfs, and what distribution
are you using?
I have seen one other user have a problem where their initramfs had
crc32c_intel, but not crc32c_generic, but their scripts weren't
regenerating the modueles.dep.bin file, so when the modprobe tries to
load crc32c, even though crc32c_intel is present (and preferred), the
modprobe bombs out because it was trying to load crc32c_generic first.
You seem to have a different failure mode, but it looks like there are
many ways in which in the initramfs tools will fail to include the
right crc32c module(s). I was able to find a Debian bug going back to
2011(!) which described problems with this, and Debian ultimately
dealt with this by just unconditionally force-including libcrc32c,
crc32c_generic, and crc32c_intel into the initramfs. :-(
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608538
I'll note that it's actually really silly for distros to be building
these as modules. crc32c_generic is 900 bytes, and crc32c_intel is
11k --- but the modules consume 16k (each) of memory when loaded, and
each module burns a TLB cache entry when the code is called. So it's
actually a much smarter idea to just build the crc32c code into the
kernel, instead of keeping them as modules. It's what I do just
because it's a Really Good Idea, and apparently Debian has hacked
around the problem years ago so it's not an issue I would have seen
either if I did build them as modules.
Still, if we have a lot of buggy distros out there, and 4.16.4 is
going to trigger it, we're going to have to figure out some kind of
workaround for everyone....
- Ted
next prev parent reply other threads:[~2018-04-26 17:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 9:20 Linux 4.14.36 Greg KH
2018-04-24 9:21 ` Greg KH
2018-04-24 11:52 ` François Valenduc
2018-04-24 12:31 ` Greg KH
2018-04-24 12:40 ` François Valenduc
2018-04-24 12:50 ` Greg KH
2018-04-24 14:19 ` François Valenduc
2018-04-24 15:09 ` Theodore Y. Ts'o
2018-04-24 18:17 ` François Valenduc
2018-04-24 20:25 ` Theodore Y. Ts'o
2018-04-25 20:05 ` François Valenduc
2018-04-26 5:44 ` Greg KH
2018-04-26 6:35 ` Greg KH
2018-04-26 6:22 ` Theodore Y. Ts'o
2018-04-26 11:36 ` François Valenduc
2018-04-26 17:05 ` Theodore Y. Ts'o [this message]
2018-04-26 17:22 ` Greg KH
2018-04-26 21:00 ` Theodore Y. Ts'o
2018-04-26 13:42 ` James Blanford
2018-04-26 14:50 ` James Blanford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180426170519.GA5965@thunk.org \
--to=tytso@mit.edu \
--cc=francoisvalenduc@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jhblanford@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.