From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, fastboot@osdl.org, Andi Kleen <ak@suse.de>
Subject: Re: i386 nmi_watchdog: Merge check_nmi_watchdog fixes from x86_64
Date: Thu, 13 Oct 2005 22:13:12 -0600 [thread overview]
Message-ID: <m1r7aoohwn.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20051011182600.4a5ce224.akpm@osdl.org> (Andrew Morton's message of "Tue, 11 Oct 2005 18:26:00 -0700")
Andrew Morton <akpm@osdl.org> writes:
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>>
>>
>> The per cpu nmi watchdog timer is based on an event counter.
>> idle cpus don't generate events so the NMI watchdog doesn't fire
>> and the test to see if the watchdog is working fails.
>>
>> - Add nmi_cpu_busy so idle cpus don't mess up the test.
>> - kmalloc prev_nmi_count to keep kernel stack usage bounded.
>> - Improve the error message on failure so there is enough
>> information to debug problems.
>>
>> ...
>>
>> static int __init check_nmi_watchdog(void)
>> {
>> - unsigned int prev_nmi_count[NR_CPUS];
>> + volatile int endflag = 0;
>
> I don't think this needs to be declared volatile?
Sorry for not replying sooner I just got back from a trip.
I haven't though it through extremely closely but I believe
the stores into that variable in check_nmi_watchdog could
legitimately be optimized away by the compiler if it doesn't
have a hint. As the variable is auto and is never used
after the store without volatile it seems a reasonable
assumption that no one else will see the value.
If the variable was static the volatile would clearly be unnecessary
as we have taken the address earlier so at some point the compiler
would be obligated to but with the variable being auto the rules are a
little murky.
Eric
next prev parent reply other threads:[~2005-10-14 4:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-04 15:02 Eric W. Biederman
2005-10-05 19:50 ` Bill Davidsen
2005-10-05 20:00 ` Eric W. Biederman
2005-10-12 1:26 ` Andrew Morton
2005-10-14 4:13 ` Eric W. Biederman [this message]
2005-10-14 18:53 ` Andy Isaacson
2005-10-15 12:49 ` Eric W. Biederman
2005-10-18 7:05 ` Andy Isaacson
2005-10-18 12:44 ` Eric W. Biederman
2005-10-19 7:10 ` Zwane Mwaikambo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1r7aoohwn.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=fastboot@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®