linux-kernel - Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

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:	Fri, 29 Aug 2008 18:30:35 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Jeff Garzik" <jeff@...zik.org>, "Tejun Heo" <htejun@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"David Witbrodt" <dawitbro@...global.net>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Kernel Testers" <kernel-testers@...r.kernel.org>
Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

On Fri, Aug 29, 2008 at 6:11 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> Btw, what was the original regression that commit was
> a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix?
>
> It's not listed in that commit, even though the commit has a "Bisected-by:
> David Witbrodt <dawitbro@...global.net>".
>
> In fact, I can find it with google by searching for
>
>        David Witbrodt bisect
>
> and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f.
>
> I'm wondering why that commit wasn't just reverted? Because now that I see
> it, I notice that _that_ is the real bug to begin with.
>
> That commit really was buggy. NO WAY can you insert the code/bss/data
> resources before you've done e820 handling, because it may well be that
> some strange e820 table contains things that cross the resources.

we reverted the commit , David's problem still happen.

the root cause is:
before 2.6.26, call init_apic_mapping and will insert_resource for
lapic address.
and then call e820_resource_resouce (with request_resource) to
register e820 entries.
so the lapic entry in the resource tree will prevent some entry in
e820 to be registered.
later request_resource for BAR res (==hpet) will succeed.

from 2.6.26. we move lapic address registering to late_initcall, so
the entry is reserved in e820 getting into resource tree at first.
and later pci_resource_survey::request_resource for BAR res (==hpet,
0xfed00000) will fail. so pci_assign_unsigned... will get new
res for the BAR, so it messed up hpet setting.

solutions will be
1. use quirk to protect hpet in BAR, Ingo said it is not generic.
2. or the one you are reverted... check_bar_with_valid. (hpet, ioapic,
mmconfig) --> happenly reveal another problem with Rafael's
system/chipset.
3. or sticky resource... , but could have particallly overlapping
4. or don't register reserved entries in e820.. Eric, Nacked.
5. or you sugges, regiser some reserved entries later...., and have
insert_resource_expand_to_fit...

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/