7

I'm working on a Linux kernel module which shares a piece of memory with user applications through the syscall mmap. The module works alright with the help of the mmap callback defined in the struct file_operations, which informs the module when the syscall is invoked.

However, the problem comes out when user applications want to stop the sharing through syscall munmap. There is not an munmap callback or something that does similar work in the struct file_operations. Therefore, I have to do another ioctl to inform the kernel module that the sharing has been revoked, which is both inconvenient and insecure.

During my search for the solution, I found that there was once an munmap callback defined. But it was removed when the kernel version was about 2.4 or some times after.

Can someone tell me why the munmap callback is removed or is there any alternative approach to inform the kernel module when an munmap syscall is called?

liangpig1
  • 171
  • 1
  • 6
  • The vm struct that you usually insert in the user address space contains a few operations that will be invoked in the live time of this virtual region ( check vm_operations_struct, mainly the close function .. It will be called when the last reference to the vm region goes ) – KarimRaslan Aug 03 '14 at 19:10

2 Answers2

6

After some searching, I have finally come to the answers.

The function that I need lies in the vm_operations_struct. The close callback will be invoked if the munmap() syscall is executed successfully and I can use this function pointer to inform my kernel module a memory unmap has just happened.

The override of the default close action, that is the assignment of the close function pointer, is done in the mmap handler in my kernel module, where a vm_area struct is provided as a parameter and you can do all the things you want to it.

Actually, all the detail is described in the Book Linux Device Drivers 3, Chapter 15.

Thanks all your guys for providing really useful suggestions.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
liangpig1
  • 171
  • 1
  • 6
1

munmap() is not a file operation, it a system call that operates on the mapped memory itself.

It is perfectly valid to mmap() a file descriptor, and then close the file descriptor.

jxh
  • 69,070
  • 8
  • 110
  • 193
  • Thanks. I understand that munmap is not a file operation. But what I mean is that, in the implementation of syscall mmap, the given file's file_operations->f_op->mmap will be invoked. And where is the counterpart for munmap. – liangpig1 Aug 02 '14 at 19:41
  • I have not implemented such a device driver, so this is speculation. When you implemented `mmap()` for your device, you probably used an API to retrieve the pages that you needed to give to the linux VM system to manage. If you get to control the page pool that your pages come from, you can probably treat the call to release memory back to that pool as your `munmap()` callback. – jxh Aug 02 '14 at 19:56
  • Actually your speculation is correct. For my current implementation, my handler for mmap() does use the kmalloc() to get some physically contiguous page to send to the Linux VM system. So, the problem now is how to get to control the page pool, which according to my understanding, is tightly coupled with Linux's memory management mechanism. I was just investigating the vm_operations_struct to see if that can helps. – liangpig1 Aug 02 '14 at 20:01