linux-kernel - Re: [PATCH + an old question] firewire: ohci: use memory barriers to order descriptor updates

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C4FDC06.3050703@ladisch.de>
Date:	Wed, 28 Jul 2010 09:28:06 +0200
From:	Clemens Ladisch <clemens@...isch.de>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	linux-kernel@...r.kernel.org, linux1394-devel@...ts.sourceforge.net
Subject: Re: [PATCH + an old question] firewire: ohci: use memory barriers
 to order descriptor updates

Stefan Richter wrote:
> We need:
> 2. a write memory barrier between branch_address update and wake-up of
>    the DMA unit by MMIO register write.
> 
> Barrier 2 is implicit in writel() on most machines --- or at least I
> think it is.  See this from arch/x86/include/asm/io.h:
> 
>     #define build_mmio_write(name, size, type, reg, barrier) \
>     static inline void name(type val, volatile void __iomem *addr) \
>     { asm volatile("mov" size " %0,%1": :reg (val), \
>     "m" (*(volatile type __force *)addr) barrier); }
> 
>     build_mmio_write(writel, "l", unsigned int, "r", :"memory")
> 
> Does this order the mmio write relative to previous memory writes?

This asm barrier prevents the compiler from reordering.

The main purpose of writel() and friends is to access the address space
where memory-mapped I/O ranges reside; there are architectures where the
normal memory access commands cannot be used.  This does not necessarily
imply anything about reordering semantics.

However, PCI address ranges are marked by the device's config registers
as either cacheable or not, and the kernel heeds this when mapping these
ranges.  Registers are, of course, marked as uncacheable.


Regards,
Clemens
--
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/