mapping user space buffer to kernel address space

Hi,

I've just been talking about this with Ben LaHaise and Rik van Riel, and Ben brought up a nasty problem --- NFS, which because of its credentials requirements needs to have the struct file available in its writepage function. Of course, if we defer the write then we don't necessarily have the file available when we come to flush the page from cache.

One answer is to say "well then NFS is broken, fix it". It's not too hard --- NFS mmaps need a wp_page function which registers the caller's credentials against the page when we dirty it so that we can use those credentials on flush. That means that writes to a multiply-mapped file essentially get random credentials, but I don't think we care --- the credentials eventually used will be enough to avoid the root_squash problems and the permissions at open make sure we're not doing anything illegal.

(Changing permissions on an already-mmaped file and causing the NFS server to refuse the write raises problems which are ... interesting, but I'm not convinced that that is a new problem; I suspect we can fabricate such a failure today.)

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Yes. But that doesn't mean that swapping couldn't do it (swapping fundamentally doesn't have credentials).

And note that this is not about "NFS is broken" - any remote filesystem will have some issues like this, and shared mappings will always have to handle this case.

So basically I agree that shared mappings cannot be converted to this setup, I was only talking about the specific case of the swapping (and anonymous shared memory, which along with SysV IPC shm is basically the same thing and already uses the swap cache).

So what I was thinking of was the very end of try_to_swap_out(), where we have noticed that we do not have a "swapout()" function, and we need to add the page to the swap cache. I would suggest moving _that_ code to the LRU queue, and handling it conceptually together with the stuff that handles the buffer cache writeout.

--

And no, I haven't forgotten about the case of direct IO into a shared mapping. That _is_ going to be different in many ways, and I suspect that a solution to that particular issue may be to move the "vm_file" information from when we do the virtual kiobuf lookup into the kiobuf's, because otherwise we'd basically lose that information.

(We _already_ lose that information, in fact. Keeping the page in the virtual mapping doesn't really even fix it - because the page can be in multiple virtual mappings with different vm_file's and thus different credentials. And the kiobuf's do not really contain any information of _which_ of the credentials we looked up. It happens to work, but it's conceptually not very correct).

Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/