Re: call suspend_cpus() under smp_ipi_mtx

2013-04-06 Thread Andriy Gapon
on 04/04/2013 20:34 Andriy Gapon said the following: > This seems to work without problems or any warnings with WITNESS && > !WITNESS_SKIPSPIN, but it is very possible that I am not exercising all the > relevant code paths. > > P.S. Looking through history it seems that in r169391 intr_table_lock

Re: call suspend_cpus() under smp_ipi_mtx

2013-04-04 Thread Andriy Gapon
on 01/04/2013 17:52 John Baldwin said the following: > Hmm, I think intr_table_lock used to be a spin lock at some point. I don't > remember > why we changed it to a regular mutex. It may be that there was a lock order > reason > for that. :( I came up with the following patch: http://people.f

Re: call suspend_cpus() under smp_ipi_mtx

2013-04-01 Thread John Baldwin
On Saturday, March 23, 2013 5:48:50 am Andriy Gapon wrote: > > Looks like this issue needs more thinking and discussing. > > The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on > SMP systems). > This is for exactly the same reasons as to why we first take smp_ipi_mtx >

Re: call suspend_cpus() under smp_ipi_mtx

2013-03-23 Thread Andriy Gapon
Looks like this issue needs more thinking and discussing. The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on SMP systems). This is for exactly the same reasons as to why we first take smp_ipi_mtx before calling stop_cpus() in the shutdown path. Essentially one CPU cou

call suspend_cpus() under smp_ipi_mtx

2013-02-07 Thread Andriy Gapon
Could you please review and/or test the following patch? The idea is exactly the same as for cpu_stop() invocation in the shutdown path. Please note that I've kept intr_disable() just because potentially mtx_lock_spin could be implemented in such a way that it wouldn't block all interrupts via CP