Re: 2.6.17-rc4-mm3

[Valdis . Kletnieks]

On Mon, 22 May 2006 02:27:09 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/

Mostly works, am chasing down 3 small things (all 3 were new as of -mm2 - I was
busy chasing them when -mm3 showed up).

1) Something has gone astray in the hardware RNG rework.  /sbin/rngd was
quite happy dealing with the i810 RNG in my laptop under -rc4-mm1, but under
-mm2 and -mm3, I get this (from strace /bin/rngd):

open("/dev/hw_random", O_RDONLY)        = 3
read(3, "q\252cg", 4)                   = 4
read(3, 0xbfaf56ac, 4)                  = -1 EAGAIN (Resource temporarily unavai lable)

It works for some number of reads, but eventually pulls an EAGAIN.  When
stracing on a console that was slow-to-scroll, it did several dozen before
failing - so it's apparently a timing thing.  I stuck a debugging printk
in just before the test that returns EAGAIN, and got this:

[   68.361000] rng_read data_present=1 i=0 bytes_read=1
[   68.361000] rng_read data_present=1 i=0 bytes_read=1
[   68.361000] rng_read data_present=1 i=0 bytes_read=1
[   68.361000] rng_read data_present=1 i=0 bytes_read=1
[   68.361000] rng_read data_present=0 i=20 bytes_read=0

It looks to me line the old code stayed in a while() loop in rng_dev_read
until it had fulfilled the read request (including possibly multiple
calls to need_resched() and friends).  The new code will bail on an -EAGAIN
as soon as the *first* poll fails, rather than waiting until something
is available - even if it is NOT flagged O_NONBLOCK.

2)   Building modules, stage 2.
  MODPOST 
WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf5e) and 'acpi_safe_halt' 

3) Something in git-cryptodev.patch doesn't play nice with RedHat Fedora's
'modsign' patches.  I'm suspecting this is the cause:

commit f1c737f209e39095016e5be3904b2ce84027890f
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date:   Tue May 16 22:09:29 2006 +1000

    [CRYPTO] all: Pass tfm instead of ctx to algorithms

I just haven't stared at it enough to make the fixes needed.

Attachment: pgp00000.pgp
Description: PGP signature