linux-kernel - Re: Linux 2.6.30-rc8 [also: VIA Support]

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: <4A2867C1.90408@gmail.com>
Date:	Thu, 04 Jun 2009 18:33:05 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	lkml@...eThan.org
CC:	Andi Kleen <andi@...stfloor.org>,
	Harald Welte <HaraldWelte@...tech.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Duane Griffin <duaneg@...da.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.30-rc8 [also: VIA Support]

Michael S. Zick wrote:
> On Thu June 4 2009, Andi Kleen wrote:
>> Harald Welte <HaraldWelte@...tech.com> writes:
>>> why would it matter on UP? as indicated, I'm not the expert here, but I thought
>>> memory ordering issues only arise in SMP systems [or possibly with regard to
>>> DMA, but as we already explored much earlier in this thread, drivers that access
>>> DMA buffers whil the hardware owns them are buggy and need to be fixed]
>> Sorry we didn't establish that. Accessing data structures that are
>> also accessed by DMA hardware is pretty common in fact and memory
>> ordering issues also come up regularly (e.g. all the infamous PCI
>> posting bugs)
>>
>> What we established is that the drivers don't use LOCK for it
>> (or at least we think that's very unlikely)
>>
> 
> It was a real headache in the pa-risc port - -
> Even went so far as to build some experimental kernels where all
> the spin-lock structures where in a separate loader section.
> 
> That was to avoid in-direct interference - I.E: Both DMA and
> the processor handling the locking **both** invalidating the
> same cache line at the same time (only one can win).
> 
> Things might get that deep with this processor/chip-set combination;
> but pa-risc has some very unusual hardware in some older models.

That sort of thing should be architecturally impossible on x86. In order 
for something to invalidate the cache line, it first has to own it 
(except maybe for some unusual cases like Memory Write and Invalidate 
where the writer promises to overwrite the entire cache line).
--
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/