PERFORCE change 205637 for review

Attilio Rao attilio at freebsd.org
Fri Feb 3 18:09:15 UTC 2012


Please note that in case the option is disabled you will get no
protection on this paths.
Said that, I agree with the mutex change, but I would live the
interrupts disabling in the proxy paths, in order to force them also
when the option is out.

Attilio


2012/2/3 John Baldwin <jhb at freebsd.org>:
> http://p4web.freebsd.org/@@205637?ac=10
>
> Change 205637 by jhb at jhb_jhbbsd on 2012/02/03 15:50:53
>
>        Revert these hacks as they are superseded by the SCHEDULER_STOPPED
>        stuff in HEAD.
>
> Affected files ...
>
> .. //depot/projects/smpng/sys/amd64/amd64/vm_machdep.c#55 edit
> .. //depot/projects/smpng/sys/i386/i386/vm_machdep.c#103 edit
> .. //depot/projects/smpng/sys/kern/kern_mutex.c#162 edit
>
> Differences ...
>
> ==== //depot/projects/smpng/sys/amd64/amd64/vm_machdep.c#55 (text+ko) ====
>
> @@ -515,7 +515,6 @@
>  {
>        cpuset_t tcrp;
>
> -       disable_intr();
>        cpu_reset_proxy_active = 1;
>        while (cpu_reset_proxy_active == 1)
>                ;       /* Wait for other cpu to see that we've started */
> @@ -534,7 +533,6 @@
>        cpuset_t map;
>        u_int cnt;
>
> -       disable_intr();
>        if (smp_active) {
>                map = all_cpus;
>                CPU_CLR(PCPU_GET(cpuid), &map);
>
> ==== //depot/projects/smpng/sys/i386/i386/vm_machdep.c#103 (text+ko) ====
>
> @@ -575,7 +575,6 @@
>  {
>        cpuset_t tcrp;
>
> -       disable_intr();
>        cpu_reset_proxy_active = 1;
>        while (cpu_reset_proxy_active == 1)
>                ;       /* Wait for other cpu to see that we've started */
> @@ -602,7 +601,6 @@
>        cpuset_t map;
>        u_int cnt;
>
> -       disable_intr();
>        if (smp_active) {
>                map = all_cpus;
>                CPU_CLR(PCPU_GET(cpuid), &map);
>
> ==== //depot/projects/smpng/sys/kern/kern_mutex.c#162 (text+ko) ====
>
> @@ -349,15 +349,6 @@
>                return;
>        }
>
> -       /*
> -        * If we have already panic'd and this is the thread that called
> -        * panic(), then don't block on any mutexes but silently succeed.
> -        * Otherwise, the kernel will deadlock since the scheduler isn't
> -        * going to run the thread that holds the lock we need.
> -        */
> -       if (panicstr != NULL && curthread->td_flags & TDF_INPANIC)
> -               return;
> -
>        lock_profile_obtain_lock_failed(&m->lock_object,
>                    &contested, &waittime);
>        if (LOCK_LOG_TEST(&m->lock_object, opts))
> @@ -674,15 +665,6 @@
>        }
>
>        /*
> -        * If we failed to unlock this lock and we are a thread that has
> -        * called panic(), it may be due to the bypass in _mtx_lock_sleep()
> -        * above.  In that case, just return and leave the lock alone to
> -        * avoid changing the state.
> -        */
> -       if (panicstr != NULL && curthread->td_flags & TDF_INPANIC)
> -               return;
> -
> -       /*
>         * We have to lock the chain before the turnstile so this turnstile
>         * can be removed from the hash list if it is empty.
>         */



-- 
Peace can only be achieved by understanding - A. Einstein


More information about the p4-projects mailing list