Re: [Drbd-dev] drbd-svn can't handle modular hmac, and crashes if hash can't be found

[Mark Glines <mark@glines.org>]

Lars Ellenberg wrote:
>> 2.  If the hash algorithm itself isn't available (like sha1.ko wasn't loaded yet), crypto_alloc_hash() returns 
>> -ENOENT.  It does not return NULL, which is what the drbd code currently checks for.  This leads to crashes later.
> 
> right... we know 't was unfinished code,
> but checked in anyways, to get it going.

FYI, it's working here on 2.6.20-rc4 (PPC) with CONFIG_CRYPTO_HMAC and 
CONFIG_CRYPTO_SHA1 both configured as modules.  So now I'm watching my 
new cluster sync up for the first time:

drbd0: Writing meta data super block now.
drbd0: conn( WFConnection -> WFReportParams )
drbd0: Handshake successful: DRBD Network Protocol version 85
drbd0: Peer authenticated usind 20 bytes of 'sha1' HMAC
drbd0: peer( Unknown -> Secondary ) conn( WFReportParams -> WFBitMapS ) 
pdsk( DUnknown -> Inconsistent )
drbd0: Writing meta data super block now.
drbd0: conn( WFBitMapS -> SyncSource )
drbd0: Began resync as SyncSource (will sync 9775216 KB [2443804 bits set]).


>> P.S.  Since drbd no longer requires any exported symbols from the hmac/hash module, is there any reason to check 
>> CONFIG_CRYPTO_HMAC at all?  A simpler check on CONFIG_CRYPTO to make sure the basic API exists should be all you 
>> need...
> 
> we build against older kernels as well,
> and as long as debian, suse, redhat & co have their
> vendor kernels the way they are, this probably needs to stay this way.
> we should be able to relax it for builds against newer kernels, though.

Makes sense.  Thanks again!

Mark