Messages in this thread | | | Date | Mon, 16 Aug 2010 22:06:49 +0800 | From | Yong Zhang <> | Subject | Re: fix BUG: using smp_processor_id() in touch_nmi_watchdog and touch_softlockup_watchdog |
| |
On Mon, Aug 16, 2010 at 09:34:52AM -0400, Don Zickus wrote: > I don't recall any requirement to have preemption disabled when using > those functions.
Isn't that implicit? I mean the caller of touch_{softlockup|nmi}_watchdog will sticky to that cpu before it finish running.
> It seems sensible to put it in the > touch_{softlockup|nmi}_watchdog code.
I don't think so. Such as:
... preempt_disable() <===A touch_{softlockup|nmi}_watchdog <===B preempt_enable() <===C ...
You just scroll A and C into B, but what will happen before preempt occur before A?
> > I assume the reason for having preemption disabled when using > smp_processor_id() is that the code could migrate to another cpu when > rescheduled?
If the migration could happen, then we could touch the wrong cpu-data, and the detection on the original cpu will trigger anyway.
> > I don't see a problem with the patch, but my low level understanding of > the __get_cpu_var vs. per_cpu isn't very strong.
Maybe we should use __raw_get_cpu_var() instead.
Thanks, Yong
| |