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: <20081220205808.GA4465@8bytes.org>
Date:	Sat, 20 Dec 2008 21:58:08 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] x86 fixes

On Sat, Dec 20, 2008 at 11:16:01AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 20 Dec 2008, Ingo Molnar wrote:
> > 
> > Joerg Roedel (3):
> >       AMD IOMMU: panic if completion wait loop fails
> 
> What's the advantage to this, especially this late in the game?
> 
> Now, I tried to google for the message (while ignoring the patches), and 
> as far as I can tell, it has never happened that google has noticed. But 
> still, why was this pushed as a "fix"?

Google won't tell because the hardware is not yet for sale. The story
behind this patch is, it happened that the completion wait loop failed in
my tests.

And when it fails then for sure because some error occured and the AMD
IOMMU stopped fetching commands from the command buffer (the reason why
it stopped fetching commands for me is also fixed with another patch in
this pull request, but there may be other reasons like internal errors).
But it is important that the IOMMU fetches commands because they are
needed to flush the IOTLB. If we can't flush the IOTLB we get data
corruption sooner or later. So I decided its better to panic in this
situation.

There is another way to handle this by resetting the command buffer. But
that is more code (basically code to flush the IOMMU cache for
everything we have under control with the IOMMU). Too much for inclusion
that late in the release cycle. I will prepare that for one of the
future merge windows.

For now, the best 'fix' in this situation is to panic before data
corruption can happen.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ