i386 pmap_zero_page() late sched_pin()?

[Alan Cox]

On Sun, Dec 12, 2010 at 10:40 AM, Venkatesh Srinivas <
vsrinivas at dragonflybsd.org> wrote:

> Hi,
>
> In the i386 pmap's pmap_zero_page(), there is a fragment...
>
>        sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)];
>        mtx_lock(&sysmaps->lock);
> *       sched_pin();
>        /*map the page we mean to zero at sysmaps->CADDR2*/
>        pagezero(sysmaps->CADDR2);
>        sched_unpin();
>
> I don't know this bit of code too well, so I don't know if the sched_pin()
> being where it is is okay or not. My first reading says its not okay; if a
> thread is moved to another CPU before it is able to pin, it will use the
> wrong sysmaps structure. Is this the case? Is it alright that the wrong
> sysmap structure is used?
>
> Oh, Nathaniel Filardo (nwf at cs.jhu.edu) first spotted this, not I.
>
>
This isn't a bug.  There is nothing about the code that mandates that
processor i must always use sysmap entry i.   In the unlikely event that the
thread migrates from processor X to processor Y before the sched_pin(), the
mutex on sysmap entry X will prevent it from being used by processor X until
processor Y is done with it.  So, it doesn't matter to correctness that the
"wrong" sysmap entry is used, and it is extremely unlikely to matter to
performance.

Alan