From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
mingo@elte.hu, linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86: Fix bogus warning in apic_noop.apic_write()
Date: Mon, 7 Dec 2009 19:30:57 +0300 [thread overview]
Message-ID: <20091207163057.GB5489@lenovo> (raw)
In-Reply-To: <alpine.LFD.2.00.0912071629350.3089@localhost.localdomain>
On Mon, Dec 07, 2009 at 04:48:51PM +0100, Thomas Gleixner wrote:
> On Mon, 7 Dec 2009, Cyrill Gorcunov wrote:
> > On Mon, Dec 07, 2009 at 12:18:37PM +0000, tip-bot for Thomas Gleixner wrote:
> > > Commit-ID: a946d8f11f0da9cfc714248036fcfd3a794d1e27
> > > Gitweb: http://git.kernel.org/tip/a946d8f11f0da9cfc714248036fcfd3a794d1e27
> > > Author: Thomas Gleixner <tglx@linutronix.de>
> > > AuthorDate: Mon, 7 Dec 2009 12:59:46 +0100
> > > Committer: Ingo Molnar <mingo@elte.hu>
> > > CommitDate: Mon, 7 Dec 2009 13:16:37 +0100
> > >
> > > x86: Fix bogus warning in apic_noop.apic_write()
> > >
> > > apic_noop is used to provide dummy apic functions. It's installed
> > > when the CPU has no APIC or when the APIC is disabled on the kernel
> > > command line.
> > >
> > > The apic_noop implementation of apic_write() warns when the CPU has
> > > an APIC or when the APIC is not disabled.
> > >
> > > That's bogus. The warning should only happen when the CPU has an
> > > APIC _AND_ the APIC is not disabled. apic_noop.apic_read() has the
> > > correct check.
> > >
> > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> > > Cc: <stable@kernel.org> # in <= .32 this typo resides in native_apic_write_dummy()
> > > LKML-Reference: <alpine.LFD.2.00.0912071255420.3089@localhost.localdomain>
> > > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > > ---
> > > arch/x86/kernel/apic/apic_noop.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > ...
> >
> > Hi Thomas, Ingo,
> >
> > please do not change it. There are still machines without
> > cpu_has_apic bit support so with this patch any attempt
> > to write to 82489DX will success. So the former code has
> > been using "OR" by a purpose, there is no error.
>
> Err, your warning has the following false positive:
>
> cpu_has_apic == true and disable_apic == true
This combination impossible at moment (by "impossible" I mean
at moment of apic_write action). When apic disabled via boot
option cpu_has_apic cleared as well.
static int __init setup_disableapic(char *arg)
{
disable_apic = 1;
setup_clear_cpu_cap(X86_FEATURE_APIC);
return 0;
}
And, btw if some code is trying to write to apic when
it's disabled via boot option -- it means the code is
buggy and this is not a false positive but rather proper
warning.
Thomas, if you've changed this code I suppose you saw some
warning triggered, right? Could you pointed me on it?
The idea was exactly to use "OR" here, so any attempts to
make WRITE on dosabled apic were captured.
>
> Which is crap, as it warns just because someone disabled the APIC on
> the command line and the kernel did the right thing of installing
> apic_noop.
>
> And I have a hard time to see how this is related to 82489DX.
On 82489DX there is no X86_FEATURE_APIC at all, so cpu_has_apic
is never set and disable_apic is the only flag we inspect to find
out if we're allowed to operate over apic.
An example you may find in APIC_init_uniprocessor, the first check
is done for disable_apic, not cpu_has_apic.
>
> Thanks,
>
> tglx
>
-- Cyrill
next prev parent reply other threads:[~2009-12-07 16:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 11:59 [PATCH] " Thomas Gleixner
2009-12-07 12:18 ` [tip:x86/urgent] " tip-bot for Thomas Gleixner
2009-12-07 15:04 ` Cyrill Gorcunov
2009-12-07 15:48 ` Thomas Gleixner
2009-12-07 16:30 ` Cyrill Gorcunov [this message]
2009-12-07 16:55 ` Thomas Gleixner
2009-12-07 18:04 ` Cyrill Gorcunov
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=20091207163057.GB5489@lenovo \
--to=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/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®