On 06/27/2014 10:50 AM, AKASHI Takahiro wrote: > On 06/27/2014 01:17 AM, Daniel Mack wrote:
>> Your Pandaboard features an OMAP4430 MCU with VIPT/PIPT data cache that >> doesn't suffer from aliasing, and both cache_is_vivt() and >> cache_is_vipt_aliasing() will validate to false on your platform. Hence, >> you effectively made the entire function a no-op. That is correct for an >> OMAP4430, but it will break for anything that has VIVT caches, like the >> PXA3xx SoC I'm testing on. > > I think that shmem is primarily used to share data between applications > (user processes), and that no explicit cache operations by users are required > even on VIVT architectures, right? > So it sounds somewhat strange to me that the kernel has to take care of > aliasing > on behalf of Apps. (I do understand that flushing is necessary in this > specific > use-case of kdbus.) > A matter of design? The problem is that memory in the shmem has different caches from userspace and kernel space. If you only modify a piece of memory from kernel space, you might just get it from the dcache, which is perfectly fine and doesn't matter. Same for userspace. But once memory is modified from kernel space that is also mapped to userspace, the kernel has to take care to flush the dcache aliases before handing control back to userspace. Otherwise, the userspace gets to see wrong data in its mmaped buffer. There's some information here: https://en.wikipedia.org/wiki/Cpu_cache#Address_translation That's not a theoretical thing at all, btw. My PXA3xx machine usually crashed or hangs after the thrid iteration or so of this shell command: # while [ true ]; do busctl --no-pager; echo "----------"; done Daniel _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
