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] [day] [month] [year] [list]

Message-Id: <200808271642.26486.jbarnes@virtuousgeek.org>
Date:	Wed, 27 Aug 2008 16:42:25 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
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 Wednesday, August 27, 2008 4:23 pm Yinghai Lu wrote:
> 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.

For just reservations that may be true, but we definitely want more space 
available for PCI device allocations.  As for ACPI allocations, maybe, but we 
have to make sure not to stomp on that space in the first place...
-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/