public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Yinghai Lu <yinghai@kernel.org>
Cc: Dave Airlie <airlied@gmail.com>,
	Iranna D Ankad <iranna.ankad@in.ibm.com>,
	Gary Hade <garyhade@us.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Thomas Renninger <trenn@suse.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: oops in ioapic_write_entry
Date: Wed, 04 Aug 2010 05:12:49 -0700	[thread overview]
Message-ID: <m1mxt28tku.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4C592BF5.3070008@kernel.org> (Yinghai Lu's message of "Wed\, 04 Aug 2010 01\:59\:33 -0700")

Yinghai Lu <yinghai@kernel.org> writes:

> On 08/03/2010 02:38 PM, Eric W. Biederman wrote:
>> 
>> A clean solution would be to scrub the input from the MP table before
>> we attempt to use of it, instead of scrubbing the data as we use in
>> code paths like pin_2_irq.  Just touching pin_2_irq is certainly an
>> incomplete solution because you have not resolved if the pins should
>> be edge or level triggered, and what polarity we should be sampling
>> them at.
>> 
>> Until I see a plausible scenario where not handling buggy MP tables
>> exactly as we have done in the past I don't see hacks like you
>> are proposing making much sense at all.
>
> ok, how about this one?
>
> it will try to add entries to mp_irqs[] with some checking.

This looks roughly like the right approach.
However I don't see what would force the ioapic entries before
the intsrc entries in the table.  Especially when the assumption
is we are dealing with a buggy bios.

> ---
>  arch/x86/kernel/mpparse.c |   44 +++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 37 insertions(+), 7 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/mpparse.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/mpparse.c
> +++ linux-2.6/arch/x86/kernel/mpparse.c
> @@ -173,17 +173,17 @@ static int __init mp_irq_mpc_intsrc_cmp(
>  {
>  	if (mp_irq->dstapic != m->dstapic)
>  		return 1;
> -	if (mp_irq->type != m->type)
> +	if (mp_irq->dstirq != m->dstirq)
>  		return 2;
> -	if (mp_irq->irqtype != m->irqtype)
> +	if (mp_irq->srcbus != m->srcbus)
>  		return 3;
> -	if (mp_irq->irqflag != m->irqflag)
> +	if (mp_irq->type != m->type)
>  		return 4;
> -	if (mp_irq->srcbus != m->srcbus)
> +	if (mp_irq->irqtype != m->irqtype)
>  		return 5;
> -	if (mp_irq->srcbusirq != m->srcbusirq)
> +	if (mp_irq->irqflag != m->irqflag)
>  		return 6;
> -	if (mp_irq->dstirq != m->dstirq)
> +	if (mp_irq->srcbusirq != m->srcbusirq)
>  		return 7;
>  
>  	return 0;
> @@ -195,9 +195,39 @@ static void __init MP_intsrc_info(struct
>  
>  	print_MP_intsrc_info(m);
>  
> +	/*
> +	 *  Assume BUS, and IOAPIC entries come first all before
> +	 *    INTSRC entries
> +	 */
> +
> +	/* check if dstapic is right */
> +	for (i = 0; i < nr_ioapics; i++) {
> +		if (mp_ioapics[idx].apicid == m->dstapic)
> +			break;
> +	}
> +	if (i == nr_ioapics)
> +		return;

If we can make the algorithm two pass picking up the ioapic
entries first this should be fine.

>  	for (i = 0; i < mp_irq_entries; i++) {
> -		if (!mp_irq_mpc_intsrc_cmp(&mp_irqs[i], m))
> +		int ret = mp_irq_mpc_intsrc_cmp(&mp_irqs[i], m);
> +
> +		/* duplicated entries ? */
> +		if (!ret)
>  			return;
> +
> +		/* same apic/pin, but different bus */
> +		if (ret == 3) {
> +			/* overwrite wrong legacy one */

In practice your test of looking at mp_bus_not_pci is essentially what
we do.  I wonder if it could be made to be a test of polarity and edge
mismatch instead.

Also if we are ditching a non-duplicate intsrc we want to print a message
so there is a chance of debugging things if our heuristic for fixing
up broken BIOS's goes wrong, on some common configuration.

> +			if (test_bit(mp_irqs[i].srcbus, mp_bus_not_pci) &&
> +			    !test_bit(m->srcbus, mp_bus_not_pci)) {
> +				assign_to_mp_irq(m, &mp_irqs[mp_irq_entries]);

That should be.
> +				assign_to_mp_irq(m, &mp_irqs[i]);

> +				return;
> +			}
> +			/* dump this legacy one */
> +			if (!test_bit(mp_irqs[i].srcbus, mp_bus_not_pci) &&
> +			    test_bit(m->srcbus, mp_bus_not_pci))
> +				return;
> +		}
>  	}
>  
>  	assign_to_mp_irq(m, &mp_irqs[mp_irq_entries]);

Eric

  parent reply	other threads:[~2010-08-04 12:13 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-02  5:28 oops in ioapic_write_entry Dave Airlie
2010-08-02  6:49 ` Yinghai Lu
2010-08-02 23:17   ` Dave Airlie
2010-08-03  1:32     ` Yinghai Lu
2010-08-03  1:34       ` Yinghai Lu
2010-08-03  3:13         ` Eric W. Biederman
2010-08-03  7:19           ` Yinghai Lu
2010-08-03  8:00             ` Eric W. Biederman
2010-08-03  8:04               ` Yinghai Lu
2010-08-03  8:56                 ` Eric W. Biederman
2010-08-03  9:01                   ` Yinghai Lu
2010-08-03  9:15                     ` Eric W. Biederman
2010-08-03  9:36                       ` Yinghai Lu
2010-08-03 11:08                         ` Eric W. Biederman
2010-08-03 19:45                           ` Yinghai Lu
2010-08-03 20:02                             ` Yinghai Lu
2010-08-03 21:38                             ` Eric W. Biederman
2010-08-03 23:12                               ` Dave Airlie
2010-08-04  0:00                               ` Yinghai Lu
2010-08-04  1:19                                 ` Eric W. Biederman
2010-08-04  7:33                               ` Ingo Molnar
2010-08-04  8:59                               ` Yinghai Lu
2010-08-04  9:26                                 ` Ingo Molnar
2010-08-04 12:12                                 ` Eric W. Biederman [this message]
2010-08-04 19:22                                   ` Yinghai Lu
2010-08-04 20:34                                     ` Eric W. Biederman
2010-08-04 22:06                                       ` Yinghai Lu
2010-08-03  8:00             ` Yinghai Lu
2010-08-03  8:27               ` Eric W. Biederman
2010-08-03  3:26     ` Eric W. Biederman
     [not found]       ` <AANLkTi=qtLkY0=h77=EVL+y1q41b_cMBODvL4Hu6A6wL@mail.gmail.com>
2010-08-03  6:00         ` Eric W. Biederman

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=m1mxt28tku.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=airlied@gmail.com \
    --cc=garyhade@us.ibm.com \
    --cc=hpa@zytor.com \
    --cc=iranna.ankad@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=trenn@suse.de \
    --cc=yinghai@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