linux-kernel - Re: [PATCH 2.6.19 2/3] sata

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 06 Dec 2006 18:38:12 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Jeff Garzik <jeff@...zik.org>, Mikael Pettersson <mikpe@...uu.se>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19 2/3] sata_promise: new EH conversion

Arjan van de Ven wrote:
>> But, having those flushes won't hurt either.  What was the conclusion of
>> mmio <-> spinlock sync discussion?  I always feel kind of uncomfortable
>> about readl() flushes.  I think they're too subtle.
> 
> those are orthogonal!
> The posting flushes have nothing to do with spinlock-vs-mmio; that
> discussion was about the CPU, while posting flushes are about the
> chipset / bridges / etc....

The problem is that it's not clear what those posting flushes actually
achieve.  Do they achieve IRQ disabling on completion?  Hardly, IRQ can
use whole different channel anyway.

And, as for spinlock/IO ordering, libata currently depends on IO
instructions not leaking outside of spinlock (ordering-wise).  We have
posting flushes at several places and some of them clearly make sense
(e.g. timed wait) but some others aren't that clear while majority of
places just don't do anything about ordering other than wrapping them
inside spinlock.

So, I don't really know.  Do we have to add mmiowb() before every
spin_unlock after IO?  Or, do we have to do explicit flushes everytime?
 Or, is it something to be taken care of in the upper layer?

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