On Sun, Dec 16, 2012 at 1:59 AM, Andriy Gapon <a...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
