[9fans] cpuid

[9fans] cpuid

[erik quanstrom]

i updated aux/cpuid to allow one to specify a mach on
which to run cpuid.  unfortunately, /proc/%d/ctl doesn't
really guarentee when target will be running on the
requested mach.  as a defense, sleep(1) is called
after wiring, but i'm not convinced that sleep must always
sched and thus potentially could return still on the wrong
mach.  and there is no way for a proc to request its current
mach number to verifiy that it has been wired.  (unless you
count picking through the binary /proc/%d/proc structure,
which seems too messy to count.)

perhaps this is all just paranoia, but in order to get /dev/reboot
working reliably (ie. in a loop for more than 10 minutes),
loops like this were required:

	for(;;){
		procwired(up, n);
		sched();
		if(m->machno == n)
			break;
	}

perhaps a call from user space solves all these problems, but
/dev/reboot is esentially a call from user space, so if it does,
why that could be is not currently clear to me.

perhaps it would make sense to add /proc/%d/mach or even
/dev/machno or even /dev/wire which would be in a position
to guarentee wiring.

- erik

Re: [9fans] cpuid

[Russ Cox]

instead of adding all sorts of goo to the interface,
why not just make the ctl write guarantee
that from the time it returns, the relevant proc
will only run on the wired mach?

russ

Re: [9fans] cpuid

[erik quanstrom]

On Mon Apr  5 02:32:10 EDT 2010, rsc@swtch.com wrote:
> instead of adding all sorts of goo to the interface,
> why not just make the ctl write guarantee
> that from the time it returns, the relevant proc
> will only run on the wired mach?

good point.  two reasons
1.  if up != p, what do you sleep on?  or do you mess
with the innards of sched?  seems dangerous

in looking at this again, runproc doesn't test
for p->wired when "cooperativly scheduling".

	/* cooperative scheduling until the clock ticks */
	if((p=m->readied) && p->mach==0 && p->state==Ready
	&& runq[Nrq-1].head == nil && runq[Nrq-2].head == nil){

ready() also appears not to check wired.

2.  already rejected:  /n/sources/patch/sorry/wiredswtch
though that approach now looks a little hokey.

- erik

Re: [9fans] cpuid

[Russ Cox]

> good point.  two reasons
> 1.  if up != p, what do you sleep on?  or do you mess
> with the innards of sched?  seems dangerous

given that you can echo stop >ctl and then echo start >ctl
from outside the kernel, i don't see why you can't do
something similar from inside the kernel.

> in looking at this again, runproc doesn't test
> for p->wired when "cooperativly scheduling".
>
>        /* cooperative scheduling until the clock ticks */
>        if((p=m->readied) && p->mach==0 && p->state==Ready
>        && runq[Nrq-1].head == nil && runq[Nrq-2].head == nil){
>
> ready() also appears not to check wired.

sure but those are bugs anyway and easy to fix.

russ