Re: Linux 4.14.36

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Apr 26, 2018 at 01:05:19PM -0400, Theodore Y. Ts'o wrote:
> 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....

Given that this has not really been reported much, I'm tending to think
that either the distros all have it correct, or that people have it
correct in their configurations.

I don't even use an initrd, and this all worked "just fine" for me,
perhaps that is because I do not build ext4 as a module?

Anyway, let's see if we get any more reports before worrying too much.
Thanks for the deep dive into Debian bug history :)

greg k-h