Subject: Re: raidctl panic
To: Greg Oster <email@example.com>
From: Antti Kantee <firstname.lastname@example.org>
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 <email@example.com> Of course he runs NetBSD
"la qualité la plus indispensable du cuisinier est l'exactitude"