linux-kernel - Re: [PATCH] firewire: fw-ohci: sync AT dma buffer before use

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: <200803141426.26098.jwilson@redhat.com>
Date:	Fri, 14 Mar 2008 14:26:26 -0400
From:	Jarod Wilson <jwilson@...hat.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firewire: fw-ohci: sync AT dma buffer before use

On Thursday 13 March 2008 04:49:03 am Stefan Richter wrote:
> >> So this patch shouldn't do
> >> anything, except that it inserts a call which happens to have barrier
> >> characteristics on some platforms.
>
> ...and potentially delays execution.
>
> > ...but got lucky in that it actually helps this particular setup (x86_64
> > kernel, dual quad-core opteron, 8G RAM, 3 FireWire controllers). Hrm.
>
> Unless you or I spot the real solution earlier, you could also try
> replacing your dma_sync_ with mb() and with mdelay() respectively to see
> what aspect of the dma_sync_ is fixing your setup.  Also move the mb()
> to other interesting places of the involved code.

So it would seem I screwed up something in my testing, and failed to reproduce 
the panic after adding '[PATCH] firewire: fw-ohci: use dma_alloc_coherent for 
ar_buffer' to the mix. Best as I can tell now, the panic was actually 
resolved by that patch, as backing out the sync altogether now works just as 
well as with the sync, with an mb and with an mdelay.

This sort of makes some degree of sense, since this is another x86_64 system 
w/>= 4GB of RAM. It would appear possible that at some higher layer, where AT 
and AR transactions are coordinated with one another, we were getting an AT 
packet into a bad state due to its corresponding AR traffic being stuck in a 
non-coherent buffer we couldn't read. But this is only semi-informed 
speculation...

-- 
Jarod Wilson
jwilson@...hat.com
--
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/