Re: Re: fr1-2.16 patch for 2.6.10 kernel

"Also sprach denis bonnenfant:"
> > There' a call to import_device about 20 lines higher up that might do
> > instead. It has a -1 in the args that means "don't retest the
> > superblock". If it is changed to 0, it might also work the trick.
> 
> Ok, it does the job too.

Well, I _believe_ I know .hat was happening now. 

I think export_rdev() in md.c kfree'ed the rdev in the
conf->mirrors[mirror].rdev position, but did not null the pointer to it.
When we later come to scan the mirrors array, we simply get led into
la-la land if the space has been reallocated.

The simplest "cure" is to erase the kfree in export_rdev. That leaves
enough in place for us to check through later in add_disk in raid1.c.
If we see it and replace it, we do the kfree then.

At worst there may be a small leak, but I don't see that it can be more
than a few structs worth and bunded by the number in the array.

I was able to trace and reproduce the conditions averred in the theory
above, and my proposed cure corrected it. I'll suggest code tomorrow,
but meanwhile, just comment the kfree in export_rdev().

Peter