Messages in this thread | | | Date | Mon, 18 May 2015 11:45:31 -0400 | From | Don Zickus <> | Subject | Re: suspend regression in 4.1-rc1 |
| |
On Mon, May 18, 2015 at 04:41:37PM +0200, Michal Hocko wrote: > On Mon 18-05-15 10:26:07, Don Zickus wrote: > > On Mon, May 18, 2015 at 06:56:46AM -0400, Ulrich Obergfell wrote: > > > > > > > There further appears to be a distinct lack of serialization between > > > > setting and using watchdog_enabled, so perhaps we should wrap the > > > > {en,dis}able_all() things in watchdog_proc_mutex. > > > > > > As I understand it, the {en,dis}able_all() functions are only called early > > > at kernel startup, so I do not see how they could be racing with watchdog > > > code that is executed in the context of write() system calls to parameters > > > in /proc/sys/kernel. Please see also my earlier reply to Michal for further > > > details: http://marc.info/?l=linux-pm&m=143194387208250&w=2 > > > > > > Do we really need synchronization here? > > > > As Peter said we have to focus on doing things correctly and not based on > > what is currently. > > > > During s2ram, I believe all the threads get parked and then unparked during > > resume. I am wondering if the race happens there, threads get unparked and > > stomp on each other when watchdog_nmi_enable_all() is called. > > Wouldn't that cause an issue during freezer mode of pm_test? I can see > it much later in the processors mode.
I am not familiar with the freeze mode of pm_test. But I believe the race only happens with cpu0. I would have thought cpu0 is slower to stop in freezer mode than in s2ram. Again, this was just my initial guess at the race problem. :-(
Peter seems to have a patch (and Uli too) that addresses this problem, so not sure how much time to focus on figuring this out.
Cheers, Don
| |