David Miller wrote:

Instead of answering your questions, I'm going to show you
how to avoid having to do any of this cache flushing crap :-)

You can avoid having to flush anything as long as the virtual
addresses on the kernel side are modulo SHMLBA the virtual addresses
on the userland side.

We have some (decidedly awkward) mechanisms to try and achieve
this in the kernel, but they are cumbersome and not air tight.

Instead, I would recommend simply that you access the ring
buffer directly in userspace.  This avoids all of the cache
aliasing issues.

Yes, this means you have to do the ring buffer accesses in
the context of the user, but it simplifies so much that I think
it'd be worth it.

I'm probably misunderstanding your suggestion because of my
limited mm knowledge, are you suggesting to do something like
this:

setsockopt(RX_RING, ...):

Allocate ring using get_user_pages, return address to user

tpacket_rcv/netlink_unicast/netlink_broadcast:

for each receiver:
	switch_mm(...)
	copy data to ring

switch_mm(original mm)

Would this work in softirq context?

Another option is to use the "copy_to_user_page()" and
"copy_from_user_page()" interfaces which will do all of
the necessary cache flushing for you.

Actually it might be nice to convert AF_PACKET's mmap() code
over to using those things.

That would also require to do the copy in the context of
the user, right?