Re: Bug#485070: cryptsetup: "FATAL" padlock_{aes,sha} error during boot
Version: 3.7-pre2-1 On Sat, 2011-07-30 at 14:13 +0800, Herbert Xu wrote: > Ralf Jung wrote: > > Hi, > > > > as per request of Jonathan at http://bugs.debian.org/cgi- > > bin/bugreport.cgi?bug=485070, I am reporting the mentioned bug to this list > > as > > well: > > > > With current Debian testing (Kernel 2.6.39), I am getting this error on > > each > > boot: > > FATAL: Error inserting padlock_sha (/lib/modules/2.6.39-2- > > amd64/kernel/drivers/crypto/padlock-sha.ko): No such device > > I understand it is harmless, but it should still be fixed since it > > irritates > > users suggesting something is seriously going wrong. > > That message comes from user-space and needs to be fixed there. Right, it comes from modprobe. Fixed in module-init-tools version 3.5, commit cdafffbadc5831ad56fe00ecd420ca9c36e9474f ("don't warn noisely if loading multiple module aliases"). Ben. signature.asc Description: This is a digitally signed message part
[PATCH] crypto: padlock-aes - Make module loading even quieter when hardware is missing
When loading aes via the module alias, a padlock module failing to load due to missing hardware is not particularly notable. With v2.6.27-rc1~1107^2~14 (crypto: padlock - Make module loading quieter when hardware isn't available, 2008-07-03), the padlock-aes module suppresses the relevant messages when the "quiet" flag is in use; but better to suppress this particular message completely, since the administrator can already distinguish such errors by the absence of a message indicating initialization failing or succeeding. This avoids occasional messages in syslog of the form padlock_aes: VIA PadLock not detected. Signed-off-by: Jonathan Nieder --- Herbert Xu wrote: > Ralf Jung wrote: >> With current Debian testing (Kernel 2.6.39), I am getting this error on each >> boot: >> FATAL: Error inserting padlock_sha (/lib/modules/2.6.39-2- >> amd64/kernel/drivers/crypto/padlock-sha.ko): No such device [...] > That message comes from user-space and needs to be fixed there. Thanks. Indeed, I was sloppy when reading the original report and thought he was talking about a different message. Sorry for the noise. drivers/crypto/padlock-aes.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c index db33d300..29b9469f 100644 --- a/drivers/crypto/padlock-aes.c +++ b/drivers/crypto/padlock-aes.c @@ -508,10 +508,8 @@ static int __init padlock_init(void) int ret; struct cpuinfo_x86 *c = &cpu_data(0); - if (!cpu_has_xcrypt) { - printk(KERN_NOTICE PFX "VIA PadLock not detected.\n"); + if (!cpu_has_xcrypt) return -ENODEV; - } if (!cpu_has_xcrypt_enabled) { printk(KERN_NOTICE PFX "VIA PadLock detected, but not enabled. Hmm, strange...\n"); -- 1.7.6 -- 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 v2 1/2] crypto, sha1: export sha1_update for reuse
On Thu, Jul 28, 2011 at 05:29:35PM +0200, Mathias Krause wrote: > On Thu, Jul 28, 2011 at 4:58 PM, Herbert Xu > wrote: > > On Sun, Jul 24, 2011 at 07:53:13PM +0200, Mathias Krause wrote: > >> > >> diff --git a/include/crypto/sha.h b/include/crypto/sha.h > >> index 069e85b..7c46d0c 100644 > >> --- a/include/crypto/sha.h > >> +++ b/include/crypto/sha.h > >> @@ -82,4 +82,9 @@ struct sha512_state { > >> u8 buf[SHA512_BLOCK_SIZE]; > >> }; > >> > >> +#if defined(CONFIG_CRYPTO_SHA1) || defined (CONFIG_CRYPTO_SHA1_MODULE) > >> +extern int crypto_sha1_update(struct shash_desc *desc, const u8 *data, > >> + unsigned int len); > >> +#endif > > > > Please remove the unnecessary #if. > > The function will only be available when crypto/sha1_generic.o will > either be build into the kernel or build as a module. Without the #if > a potential wrong user of this function might not be detected as early > as at compilation time but as late as at link time, or even worse, as > late as on module load time -- which is pretty bad. IMHO it's better > to detect errors early, as in reading "error: implicit declaration of > function ‘crypto_sha1_update’" when trying to compile the code in > question instead of "Unknown symbol crypto_sha1_update" in dmesg when > trying to load the module. That for I would like to keep the #if. In order to be consistent please remove the ifdef. In most similar cases in the crypto subsystem we don't do this. As adding such ifdefs all over the place would gain very little, I'd much rather you left it out. The one case where this would make sense is if it were a trivial inline in the !defined case. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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