Subject: Re: raidctl panic
To: Greg Oster <>
From: Antti Kantee <>
List: tech-kern
Date: 12/11/2007 19:45:14
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 <>                     Of course he runs NetBSD                
    "la qualité la plus indispensable du cuisinier est l'exactitude"