From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.thunk.org ([74.207.234.97]:34832 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753282AbeDZRMS (ORCPT ); Thu, 26 Apr 2018 13:12:18 -0400 Date: Thu, 26 Apr 2018 13:05:19 -0400 From: "Theodore Y. Ts'o" To: =?iso-8859-1?Q?Fran=E7ois?= Valenduc Cc: Greg KH , James Blanford , stable@vger.kernel.org Subject: Re: Linux 4.14.36 Message-ID: <20180426170519.GA5965@thunk.org> References: <20180424092056.GA24237@kroah.com> <71965e45-04de-8772-87ee-3497bff8b89a@gmail.com> <20180424123148.GA20848@kroah.com> <20180424150921.GA30619@thunk.org> <20180424202534.GA7925@thunk.org> <50bfaae2-60db-ddac-46bf-aedbec1f1951@gmail.com> <20180426062250.GG18803@thunk.org> <09f17e4a-b813-9dac-2c4a-44246d4e800c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09f17e4a-b813-9dac-2c4a-44246d4e800c@gmail.com> Sender: stable-owner@vger.kernel.org List-ID: 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