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, 2 Mar 2012 08:44:00 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Dan Williams <dan.j.williams@...el.com>,
	Jonathan Nieder <jrnieder@...il.com>,
	xen-devel@...ts.xensource.com,
	pkg-xen-devel@...ts.alioth.debian.org,
	Maciej Sosnowski <maciej.sosnowski@...el.com>,
	linux-kernel@...r.kernel.org, William Dauchy <wdauchy@...il.com>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>,
	Dave Jiang <dave.jiang@...el.com>
Subject: Re: [Pkg-xen-devel] ioatdma: Boot process hangs then reboots when
 using Xen + Linux 3.2

On Fri, Mar 2, 2012 at 8:21 AM, Bastian Blank <waldi@...ian.org> wrote:
> On Thu, Mar 01, 2012 at 10:42:44PM -0800, Dan Williams wrote:
>> WARN_ON may work, but then kernel may be subject random hangs from missed
>> i/o completions.

...actually descriptors completing too early.

>
> Why is that? Currently it just dies if was triggered via interrupt and
> for some reason no active descriptor was found.

No, it's not the case that "no active descriptor was found".

The channel is walking through the submitted descriptor chain to catch
up with what was last posted to '
phys_complete'.  It expects to stop when seeing phys_complete, but if
it never finds it the driver ends up completing the entire pending
ring.  The BUG_ON is there because the driver has just completed every
descriptor in the chain, and if the kernel was depending on proper
descriptor ordering it may have just violated it.

So I take it back, we can't go to WARN_ON, because the state of the
system is compromised and we need to bring it to a halt.

That said the code is likely failing in the self test, so the system
is probably fine, but if this happened in the network or raid layer it
is potentially fatal.

>>                   Is xen32 using vt-d?
>
> Yes. Xen can use VT-D.
>
>>                                         Just wondering if writes from ioat
>> device are getting misdirected.
>
> How do VT-D and ioat interact?
>

Same as any other pci bus mastering device, via dma_map to get a
io-virtual  address.
--
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