linux-kernel - Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression

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]

Date:	Wed, 27 Aug 2008 16:23:18 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"David Witbrodt" <dawitbro@...global.net>,
	"Linux-kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- found another user with the same regression

On Wed, Aug 27, 2008 at 3:41 PM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Monday, August 25, 2008 1:00 am Yinghai Lu wrote:
>> On Mon, Aug 25, 2008 at 12:31 AM, Ingo Molnar <mingo@...e.hu> wrote:
>> > * Yinghai Lu <yhlu.kernel@...il.com> wrote:
>> >> this one should work. please apply this one only.
>> >>
>> >> YH
>> >>
>> >> [PATCH] x86: check hpet with BAR v2
>> > - plus a more highlevel approach would be nice as well i think - making
>> >  sure that the hpet driver runs before any of the PCI code, and
>> >  inserting a special "sticky" resource there which would keep any
>> >  potential followup generic PCI resource that overlaps this resource
>> >  untouched. (with a proper kernel warning emitted as well - such
>> >  situations are likely BIOS bugs.)
>>
>> yes, can remove that late_initcall tricky code to insert resource for
>> lapic and ioapic, and mmconfig etc.
>
> I agree, a higher level way of dealing with resource reservation might be
> nice.

1. insert the lapic, ioapic, mmconf mmio address into resource tree at first...
2. later when we fail to request_resource for one BAR res of pci dev,
call check_resource(.., res) to see if could find some res with the
same range and the sticky flag.
if so will insert BAR resource for the device forcibly.

that should be for 2.6.28.

> I'm hoping to polish up TJ's PCI allocation code
> (http://tjworld.net/wiki/Linux/PCIDynamicResourceAllocationManagement) for
> 2.6.28; it may have some stuff that can help.

not sure. actually we should rely on BIOS to allocate ioport/mmio for
us. and only do some minor adjust to BAR
that is obvious wrong. so have list for gap seems overkilling.
for Hotplug, the acpi code in dst should (pre)allocate the resource
for new insert devices.

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