linux-kernel - Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071230153818.1a554a7e@the-village.bc.nu>
Date:	Sun, 30 Dec 2007 15:38:18 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rene Herman <rene.herman@...access.nl>, dpreed@...d.com,
	Islam Amer <pharon@...il.com>, hpa@...or.com,
	Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...hat.com>,
	Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override

> i dont get your last point. Firstly, we do an "outb $0x80" not an inb. 

outb not inb sorry yes

> Secondly, outb $0x80 has no PCI posting side-effects AFAICS. Thirdly, 

It does. The last mmio write cycle to the bridge gets pushed out before
the 0x80 cycle goes to the PCI bridge, times out and goes to the LPC bus.

I still don't believe any of our _p users in PCI space are actually real
- but someone needs to look at the scsi ones.

> even assuming that it has PCI posting side-effects, how can any locking 
> error be covered up by an outb 0x80 sticking together with the inb it 
> does before it? The sequence we emit is:
> 
>   inbb $some_port
>   outb $0x80
> 
> and i see that the likelyhood of getting such sequences from two CPUs 
> 'mixed up' are low, but how can this have any smp locking side-effects? 
> How can this provide any workaround/coverup?

We issue inb port
We issue outb 0x80

The CPU core stalls and the LPC bus stalls

On the other CPU we issue another access to the LPC bus because our
locking is wrong. With the 0x80 outb use this stalls so the delay is
applied unless the two inb's occur perfectly in time. With a udelay() the
udelay can be split and we get a second access which breaks the needed
device delay. We end up relying on the bus locking non splitting
properties of the 0x80 port access to paper over bugs - see the watchdog
fix example I sent you about a week ago.

That btw is another argument for removing 0x80 usage as much as possible
- its bad for real time.

> do you have any memories about the outb_p() use of misc_32.c:
> 
>         pos = (x + cols * y) * 2;       /* Update cursor position */
>         outb_p(14, vidport);
>         outb_p(0xff & (pos >> 9), vidport+1);
>         outb_p(15, vidport);
>         outb_p(0xff & (pos >> 1), vidport+1);
> 
> was this ever needed? This is so early in the bootup that can we cannot 

None - but we don't care. The problems with 0x80 and the wacko HP systems
occur once ACPI is enabled so we are fine using 0x80. I don't myself know
why the _p versions ended up being used. A rummage through archives found
me nothing useful on this but notes that outb not outw is required for
some devices.

For that matter does anyone actually have video cards old enough for us
to care actually still in use with Linux today ? 

Alan
--
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/