[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKi4VAKF-Ywm=VK4wzDdr-O0Fi8Gv8X--CQcJ4FFia0Gu1Xaeg@mail.gmail.com>
Date: Thu, 28 Jan 2016 23:35:11 -0200
From: Lucas De Marchi <lucas.de.marchi@...il.com>
To: Samson Yeung <samson.yeung@...cle.com>
Cc: linux-modules <linux-modules@...r.kernel.org>,
Rusty Russell <rusty@...tcorp.com.au>,
lkml <linux-kernel@...r.kernel.org>, linux-crypto@...r.kernel.org
Subject: Re: modinfo crc32 broken after fd44a98ae2eb
Hi!
CC'ing Rusty and mailing lists
On Thu, Jan 28, 2016 at 8:40 PM, Samson Yeung <samson.yeung@...cle.com> wrote:
>
> On 01/28/2016 11:21 AM, Lucas De Marchi wrote:
>>
>> Hi Samson,
>>
>> On Wed, Jan 27, 2016 at 5:32 PM, Samson Yeung <samson.yeung@...cle.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> Please reply directly as I am not on this list.
>>>
>>> Commit "fd44a98ae2eb Fix race while loading modules" also broke 'modinfo
>>> crc32', specifically, for me.
>>>
>>> Is this a bug, is it something strange going on with crc32, or is it
>>> intended behavior?
>>
>>
>> breaking is never intended ;-). What do you mean by "break"? Does it
>> crash?
>
>
> 'modinfo crc32' prints
>
> modinfo: ERROR: Module crc32 not found.
>
> and a return value of 1 using fd44a98ae2eb.
>
> Without changing the contents of /lib/modules/`uname -r`/modules.* files,
> using fd44a98ae2eb^, 'modinfo crc32' gives me the expected info about crc32
> instead:
>
> filename: /lib/modules/4.2.0-25-generic/kernel/crypto/crc32.ko
> alias: crypto-crc32
> alias: crc32
> license: GPL
> description: CRC32 calculations wrapper for lib/crc32
> author: Alexander Boyko <alexander_boyko@...atex.com>
> srcversion: B0DE005719AC9ED9A3EEAD7
> depends:
> intree: Y
> vermagic: 4.2.0-25-generic SMP mod_unload modversions
> signer: Build time autogenerated kernel key
> sig_key: A4:10:30:FB:DF:1D:C9:62:B4:BB:7D:16:44:C3:33:7E:C4:16:DB:86
> sig_hashalgo: sha512
>
>> I can't see how this commit is related to modinfo. You will need to
>> give more details. Check if you can get the output by passing the
>> complete path to the module and make sure it's actually a module (and
>
>
> Giving the full path to the module still works as expected, so
> 'modinfo /lib/modules/4.2.0-25-generic/kernel/crypto/crc32.ko' displays
> module information and returns 0, using both fd44a98ae2eb^ and fd44a98ae2eb.
>
>> not builtin) in your kernel configuration
>
>
> I must admit that I'm slightly confused wrt crc32, since there is
> kernel/arch/x86/crypto/crc32-pclmul.ko as well as kernel/crypto/crc32.ko,
> and 'modinfo crc32-pclmul' claims that crc32 is an alias.
>
> I This happens with a stock Ubuntu kernel (4.2.0-25-generic for Wily),
> however I first observed this behavior on Redhat/Oracle Linux 7.
So... it looks like we have both kernel/lib/crc32.ko and
kernel/crypto/crc32.ko - module names should be global. It doesn't clash in
the kernel build because kernel/lib/crc32 is builtin most of the time.
With that commit in kmod there was a change on the builtin detection to fix
the race. I'll take a look to fix this, but it should probably be
fixed in the kernel
as well.
Rusty and ohers: it looks like both CONFIG_CRC32 and
CONFIG_CRYPTO_CRC32 can be compiled as module, and they generate
modules with the same name, crc32. Could that be fixed?
Lucas De Marchi
Powered by blists - more mailing lists