lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 30 Apr 2012 09:05:25 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	Sameer Nanda <snanda@...omium.org>, mingo@...hat.com,
	peterz@...radead.org, len.brown@...el.com, pavel@....cz,
	rjw@...k.pl, akpm@...ux-foundation.org, msb@...omium.org,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	olofj@...omium.org
Subject: Re: [PATCH] watchdog: fix for lockup detector breakage on resume

On Mon, Apr 30, 2012 at 11:42:13AM +0530, Srivatsa S. Bhat wrote:
> > +void lockup_detector_bootcpu_resume(void)
> > +{
> > +	void *cpu = (void *)(long)smp_processor_id();
> > +
> > +	/*
> > +	 * On the suspend/resume path the boot CPU does not go though the
> > +	 * offline->online transition. This breaks the NMI detector post
> > +	 * resume. Force an offline->online transition for the boot CPU on
> > +	 * resume.
> > +	 */
> > +	cpu_callback(&cpu_nfb, CPU_DEAD, cpu);
> > +	cpu_callback(&cpu_nfb, CPU_ONLINE, cpu);
> > +
> 
> 
> I have a couple of comments about this:
> 
> 1. Strictly speaking, we should be using the _FROZEN variants here (since the
> tasks are still frozen).
> 
> Like, cpu_callback(&cpu_nfb, CPU_DEAD_FROZEN, cpu);
> and   cpu_callback(&cpu_nfb, CPU_ONLINE_FROZEN, cpu);
> 
> Right now, since the same action is taken for either variant (ie., with or without
> _FROZEN), it really doesn't matter. But still, good to be on the safer side no?
> 
> 2. Why are we skipping the CPU_UP_PREPARE_FROZEN callback?
> 
> 3. How about hibernation? We don't hit this problem there?

Hi,

I have similar concerns as this patch seems kinda like a hack.  OTOH I
don't know all the available hooks for the suspend/resume paths.  I would
have assumed there was a special case call for the boot cpu to shutdown or
at least disable its services.  Wouldn't a lot of other tasks run into
similar problems as the watchdog?  I don't think the watchdog does
anything special that requires a special hook into the suspend path.

What do other hardware timers do on the suspend path?

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists