Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to moduledependency.

2013-07-19 Thread Tetsuo Handa 
Tim Chen wrote:
 On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
  Herbert,
  
  I've tried the module alias approach (see my earlier mail with patch) 
  but it didn't seem to load things properly.  Can you check to see if 
  there's anything I did incorrectly.
  
  Tim
 
 I fixed a missing request_module statement in crct10dif library.  
 So now things work if I have the following config:
 
 CONFIG_CRYPTO_CRCT10DIF=m
 CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
 CONFIG_CRC_T10DIF=m
 
 However, when I have the library and generic algorithm compiled in,
 I do not see the PCLMULQDQ version loaded.
 
 CONFIG_CRYPTO_CRCT10DIF=y
 CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
 CONFIG_CRC_T10DIF=y
 
 Perhaps I am initiating the crct10dif library at a really early
 stage when things are compiled in, where the module is not in 
 initramfs?  In that case, perhaps we should only allow 
 PCLMUL version to be compiled in
 and not exist as a module?

I think that use of request_module(crct10dif) does not help loading
crct10dif-pclmul.ko when CONFIG_CRC_T10DIF=y CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m ,
for there is no / directory (note that the initramfs is not yet mounted as /
for loading modules which are not in vmlinux) when any module_init() functions
which are in vmlinux are called.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to moduledependency.

2013-07-19 Thread Tetsuo Handa 
Herbert Xu wrote:
 On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
 
  However, when I have the library and generic algorithm compiled in,
  I do not see the PCLMULQDQ version loaded.
  
  CONFIG_CRYPTO_CRCT10DIF=y
  CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
  CONFIG_CRC_T10DIF=y
 
 That is completely expected.  I don't really think we need to
 do anything about this case.  After all, if the admin wants to
 use the optimised version for CRC_T10DIF then they could simply
 compile that in as well.
 

Wow! ;-)

But I'd expect something like

 static int __init crc_t10dif_mod_init(void)
 {
+#if !defined(CONFIG_CRC_T10DIF_MODULE)  
defined(CONFIG_CRYPTO_CRCT10DIF_PCLMUL_MODULE)
+   printk(KERN_WARNING Consider CONFIG_CRYPTO_CRCT10DIF_PCLMUL=y for 
better performance\n);
+#endif
crct10dif_tfm = crypto_alloc_shash(crct10dif, 0, 0);
return PTR_RET(crct10dif_tfm);
 }

because the admin might not be aware of this implication.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.11-rc1] crypto: Fix boot failure due to moduledependency.

2013-07-16 Thread Tim Chen 
On Tue, 2013-07-16 at 22:49 +0900, Tetsuo Handa wrote:
 Herbert Xu wrote:
  Looks like a bug in whatever is creating the initrd as it isn't
  including modules necessary for the boot.
 
 It turned out that it is already wrong as of creating modules.dep.
 
   # grep crc /lib/modules/3.11.0-rc1/modules.dep
   kernel/crypto/crct10dif.ko:
   kernel/drivers/scsi/sd_mod.ko: kernel/lib/crc-t10dif.ko
   kernel/lib/crc-t10dif.ko:
 
 modules.dep says
 
   (1) sd_mod.ko depends on crc-t10dif.ko
   (2) crc-t10dif.ko does not depend on crct10dif.ko

Yes, the generator of modules.dep does not seem to pick up the right
dependency.  

 
 but commit 2d31e518 made crc-t10dif.ko depend on crct10dif.ko , didn't it?
 
 crct10dif.ko need to be loaded before crc-t10dif.ko is loaded, but doing
 
 diff --git a/lib/Kconfig b/lib/Kconfig
 index 35da513..53ee0fd 100644
 --- a/lib/Kconfig
 +++ b/lib/Kconfig
 @@ -68,6 +68,7 @@ config CRC_T10DIF
   tristate CRC calculation for the T10 Data Integrity Field
   select CRYPTO
   select CRYPTO_CRCT10DIF
 + depends on CRYPTO_CRCT10DIF

Herbert, seems like modules.dep generator wants explicit

-   select CRYPTO_CRCT10DIF
+   depends on CRYPTO_CRCT10DIF

But it seems to me like it should have known CRC_T10DIF needs
CRYPTO_CRCT10DIF when we do 
select CRYPTO_CRCT10DIF

Your thoughts?

Thanks.

Tim

   help
 This option is only needed if a module that's not in the
 kernel tree needs to calculate CRC checks for use with the
 
 causes below warning.
 
   crypto/Kconfig:379: symbol CRYPTO_CRCT10DIF is selected by CRC_T10DIF
   warning: (BLK_DEV_SD  SCSI_LPFC  SCSI_DEBUG) selects CRC_T10DIF which 
 has unmet direct dependencies (CRYPTO_CRCT10DIF)


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html