Question

I have this in a kernel module:

/*global scope declared*/ 
static int array[10]={1,2,3,4,5,6,7,8,9,10};

and I have functions for open close read and write works perfectly, i want to share the array[8] with the user space application in the bottom of this page.

in the kernel module:

static int *my_mmap (struct file *filep, struct vm_area_struct *vma ) {

    if (remap_pfn_range(vma,
                vma->vm_start,
                virt_to_phys(array)>> PAGE_SHIFT,
                10,
                vma->vm_page_prot) < 0) {
        printk("remap_pfn_range failed\n");
        return -EIO;
    }


    return 0;

the application in user-space’s source code:

#define LEN (64*1024)
/* prototype for thread routine */

#define FILE_PATH "/dev/my_module"


int main() 
{
    int i=0;
    int fd = open(FILE_PATH,O_RDWR);    
    int* vadr = mmap(0, LEN, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

    for (i=0;i<10;++i){

        printf("%d",*(vadr+i));
    }

    return 0;
}

Answer 1

This is wrong on so many levels I don’t know where to even start 🙂

1. virt_to_phys may doesn’t actually work on vmalloc allocated memory, which is what Linux uses on most platform for dynamic module data section.
2. Even if it did, the data might not be contiguous in physical memory at all.
3. The array may not be aligned on page boundary.
4. Your data structure is 40 bytes, you are mapping 10 pages of random kernel memory.
5. If the processor has a virtually indexed, physically tagged (VIPT) cache, you might run into cache congruency issues when there are multiple virtual mappings to the same physical address.

There are probably more problems, but this is what pops to mind.

The right thing to do is not share data between kernel and user space, but copy it over using copy_to_user and friends, unless you really know what you are doing and why.

If you really must share the memory, then allocate a free page, map it from kernel space (e.g. kmap) and from user space (like you did) and hope that your platform doesn’t have a VIPT cache.