[systemd-devel] [RFC 7/8] HACK3: minimize the range of D-Cache flush in ioctl(CMD_MSG_RECV)

[Daniel Mack]

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