On Tue Dec 11 2007 at 09:33:30 -0600, Greg Oster wrote:
> So way "back in the day" before dk_lookup() was used, RAIDframe had 
> its own lookup routine.  And the issue way back then was consistency 
> of credentials in the following situations:
> 
>  1) Attempting to close a component (e.g. for a reconstruct initiated 
> via raidctl) that had been opened by the kernel (e.g. in autoconfig).
> 
>  2) Attempting to close a component (e.g. on raid shutdown at system 
> shutdown time) that had been opened via running raicctl (e.g. after a 
> hot-add and reconstruct).
> 
>  3) Attempting to close a component by raidctl (e.g. on a raid 
> unconfigure) where some components were opened by the kernel,
> and others by raidctl.
> 
>  4) There are other combinations/flavours of this sort of thing.
> 
> The curproc->cred (or whatever it was called then) didn't match up 
> properly in all these cases, leading to panics due to mis-matching 
> credentials (e.g. 'root's credentials when running raidctl wern't 
> matching whatever kernel credentials were used to open the component 
> device, and the system would panic).  One solution was to basically 
> use the credentials of the engine_thread in all cases. 
> 
> I'm happy to pass curlwp instead of engine_thread, but the real 
> requirement is to be able to do the opens/closes of the various 
> component devices at all stages without the kernel panicing due to
> 'invalid credentials'...  And I havn't verified that any of those 
> will be happy yet... 

Ok, thanks for the explanation.

Curious.  If you can still repeat the mismatch panic, I'm interested
in where it happens.  I don't have a raidframized test setup at hand.
Open/close is so random and wobbly that I'm surprised anything has the
audacity to panic due to them ;)

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"