linux-kernel - Re: [patch] x86_64: fix boot hang caused by CALGARY_IOMMU_ENABLED_BY

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: <20061220162338.GC11804@elte.hu>
Date:	Wed, 20 Dec 2006 17:23:38 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Muli Ben-Yehuda <muli@...ibm.com>
Cc:	Linus Torvalds <torvalds@...l.org>, linux-kernel@...r.kernel.org,
	Dave Jones <davej@...hat.com>, Andrew Morton <akpm@...l.org>
Subject: Re: [patch] x86_64: fix boot hang caused by CALGARY_IOMMU_ENABLED_BY_DEFAULT


* Muli Ben-Yehuda <muli@...ibm.com> wrote:

> On Wed, Dec 20, 2006 at 11:28:46AM +0100, Ingo Molnar wrote:
> 
> >  config CALGARY_IOMMU_ENABLED_BY_DEFAULT
> >         bool "Should Calgary be enabled by default?"
> >         default y
> >         depends on CALGARY_IOMMU
> >         help
> >           Should Calgary be enabled by default? if you choose 'y', Calgary
> >           will be used (if it exists). If you choose 'n', Calgary will not be
> >           used even if it exists. If you choose 'n' and would like to use
> >           Calgary anyway, pass 'iommu=calgary' on the kernel command line.
> >           If unsure, say Y.
> > 
> > it's both 'default y', and says "If unsure, say Y". Clearly not a
> > typo.
> 
> I think that it makes sense to have it default y for the mainline 
> kernel and default n for the distro kernels, which is why I added the 
> option to make it possible to compile Calgary in but only enable it if 
> you want to use it. Previously if you compiled it in it would be used, 
> period. You may disagree, but fundamentally I think the mainline 
> kernel should be fairly experimental, which means enabling new code by 
> default.

that's a totally wrong attitude - the mainline kernel is /not/ 
experimental. A distro might or might not enable the new option, but we 
just dont enable experimental platform support code via "default y"...

The other problem is that the changelog entry says that it's off by 
default, while in reality the new option switched this code on for my 
box, and broke it.

> As to what actually happened, I'm betting your machine has both 
> Calgary and CalIOC2, the PCI-e version of Calgary, which is not yet 
> supported by pci-calgary.c. [...]

no, what happened is what i described in my second patch. That 'new 
code' which was default-enabled had a bug which locked up my box.

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