Re: [9fans] bug in procwired() for x86 scheduler?

Re: [9fans] bug in procwired() for x86 scheduler?

[Yoann Padioleau]

The code should be

if(up != p && (p->wired == nil || p->wired == MACHP(m->machno))
   m->readied = p;

no?

> 
> if(up != p && (p->wired == nil || p->wired == m))
> 		m->readied = p;	/* group scheduling */

On Jun 22, 2014, at 10:20 AM, yoann padioleau <pad@fb.com> wrote:

> Hi,
> 
> Looking at the scheduler code I think I've found a bug related to the
> customized affinity one can set for a process.
> 
> In ready() there is:
> 
> 	if(up != p && (p->wired == nil || p->wired == m))
> 		m->readied = p;	/* group scheduling */
> 
> but on x86 'm' is actually set to a fixed address, MACHADDR. Each cpu actually
> have a different mapping in its pagetable to then translate MACHADDR virtual address to a different
> physical address.
> 
> in procwired() there is:
> 	p->wired = MACHP(bm);
> 
> MACHP is an array of addresses of all Mach in memory but not using this
> MACHADDR fixed virtual address. Each entry corresponds to a different Mach virtual
> address. 
> 
> So there is no way the test in ready() p->wired == m can even return true. 
> 

Re: [9fans] bug in procwired() for x86 scheduler?

[cinap_lenrek]

correct. :-)

--
cinap

Re: [9fans] bug in procwired() for x86 scheduler?

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

On 22 June 2014 23:25, Yoann Padioleau <pad@fb.com> wrote:

> if(up != p && (p->wired == nil || p->wired == MACHP(m->machno))
>    m->readied = p;
>

yes, because on 386 m is effectively a constant. the code was written with
extern register Mach *m in mind.

[-- Attachment #2: Type: text/html, Size: 626 bytes --]

Re: [9fans] bug in procwired() for x86 scheduler?

[erik quanstrom]

> On 22 June 2014 23:25, Yoann Padioleau <pad@fb.com> wrote:
>
> > if(up != p && (p->wired == nil || p->wired == MACHP(m->machno))
> >    m->readied = p;
> >
>
> yes, because on 386 m is effectively a constant. the code was written with
> extern register Mach *m in mind.
>


9atom has had it as

	if(up != p && (p->wired == nil || p->wired->machno == m->machno))

which i believe is equivalent, and less obnoxious.  the pc kernel should be rewritten
with the GS extern register bit, and then we could get rid of MACHP.

- erik

Re: [9fans] bug in procwired() for x86 scheduler?

[cinap_lenrek]

	if(up != p && (p->wired == nil || p->wired->machno == m->machno))

dereferencing p->wired can fault when another processor rewires the
proc temporarily setting p->wired to nil.

--
cinap

Re: [9fans] bug in procwired() for x86 scheduler?

[Yoann Padioleau]

Yes I agree, it's better that way. Is there a list somewhere on the web with all
those 9atom patches?

On Jun 22, 2014, at 5:57 PM, erik quanstrom <quanstro@quanstro.net>
 wrote:

>> On 22 June 2014 23:25, Yoann Padioleau <pad@fb.com> wrote:
>> 
>>> if(up != p && (p->wired == nil || p->wired == MACHP(m->machno))
>>>   m->readied = p;
>>> 
>> 
>> yes, because on 386 m is effectively a constant. the code was written with
>> extern register Mach *m in mind.
>> 
> 
> 
> 9atom has had it as
> 
> 	if(up != p && (p->wired == nil || p->wired->machno == m->machno))
> 
> which i believe is equivalent, and less obnoxious.  the pc kernel should be rewritten
> with the GS extern register bit, and then we could get rid of MACHP.
> 
> - erik
> 

Re: [9fans] bug in procwired() for x86 scheduler?

[erik quanstrom]

On Mon Jun 23 12:22:23 EDT 2014, pad@fb.com wrote:
> Yes I agree, it's better that way. Is there a list somewhere on the web with all
> those 9atom patches?
>

9fs atom

then look in /n/atom/patch, or /n/atom/patch/applied, or /n/atom/patch/applied$year.

- erik

ps.

for 9fs ....

case atom
	srv -n -q tcp!atom.9atom.org atom &&
		mount $nflag /srv/atom /n/atom atom