There aren't many users of that define, could you just turn it back to the proper 16, and then try changing it to 80 in each place that uses it?
That way we'd see exactly *which* use is the buggy one..
Linus
Joachim Eastwood <manabian@xxxxxxxxx> wrote:
>On Sun, Aug 7, 2011 at 7:44 PM, Linus Torvalds
><torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> On Sun, Aug 7, 2011 at 10:36 AM, Joachim Eastwood
><manabian@xxxxxxxxx> wrote:
>>>
>>> These printk's come from drivers/char/random.c
>>> So it doesn't seem like it hangs in any of the sha_* funtions.
>>
>> The only other change is to SHA_WORKSPACE_WORDS - I wonder if some
>> code depends on the old (much bigger) workspace for some reason?
>>
>> The git SHA1 routines are way smarter than the old SHA1, and will
>> re-use the workspace area, so they need only a fraction of the old
>> area.
>>
>> Try changing SHA_WORKSPACE_WORDS back to 80 (in
>> include/linux/cryptohash.h). The git sha1 only needs 16 words, but ..
>
>yup, setting it to 80 makes my kernel boot again :-)
>
>> If that fixes it for you, then it's almost certainly some buggy user
>> that uses the SHA1 workspace array for its own odd case, and
>> incorrectly "knows" that it's that old wasteful 320 bytes. There's a
>> few places in networking that uses SHA_WORKSPACE_WORDS.
>
>Guess more architectures than ARM are affected by this then.
>
>regards
>Joachim Eastwood
>
>> Linus
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
