Date: Fri, 3 Feb 2012 17:43:11 +0000 From: Attilio Rao <attilio@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 205637 for review Message-ID: <CAJ-FndBPO0Jp=wgXpFr9xvFaXUCLriVexu0mL5AsDKaxET9FQw@mail.gmail.com> In-Reply-To: <201202031550.q13FouDw006719@skunkworks.freebsd.org> References: <201202031550.q13FouDw006719@skunkworks.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org>: > http://p4web.freebsd.org/@@205637?ac=10 > > Change 205637 by jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBPO0Jp=wgXpFr9xvFaXUCLriVexu0mL5AsDKaxET9FQw>