svn commit: r243515 - head/sys/kern

[Attilio Rao]

On Sun, Dec 16, 2012 at 1:59 AM, Andriy Gapon <avg at freebsd.org> wrote:
> on 13/12/2012 22:17 Attilio Rao said the following:
>> Right, but as I said, for the time being we can at least have a
>> correct panic() semantic and take the right time to fix the
>> generic_stop_cpus() and then absorb also the panic() fix into it.
>> Right now the mechanism is still broken in panic and it can be fixed
>> with a very easy fix, so we should just do it.
>> This will also help vendors like Sandvine which may have hit just this bug too.
>
>
> Perhaps I got confused...
> Could you please re-explain to me your suggestion to fix panic(9)?
> Because I thought that it would require exactly the same steps as fixing
> generic_stop_cpus().  Sorry about this.

- about generic_stop_cpus() we need to implement all the things we
discussed which are quite a few and for some things, like avoiding
races between stop map, wakeup and set of cupid I admit I'm still not
sure how easilly can be done without locking
- about panic(), the check is much more easy, just see my first
response to Ryan, because we don't have the wakeup/restart race as
generic_stop_cpu() does.

I propose to at least fix panic for the time being. Once
generic_stop_cpus() is fully functional we can get rid of panic()
chunk altogether.

Attilio


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