Hello, I'm using kernel 2.6.12 on ARM Question 1: is it possible to allocate regular memory pages and request that they not be cached? Perhaps a special flag to __get_free_page()? Question 2: Supposing I can't have uncached pages, I need a way to invalidate the cache from a module [see * below]. After some digging, I found the platform-specific functions in arch/arm/mm/proc-arm926.S do exactly what I want. Specifically, I need the function arm926_coherent_kern_range. As it turns out, this symbol is exported in my kernel build: ~ # cat /proc/kallsyms | grep coherent_kern_range c0027c80 T arm926_coherent_kern_range c0264864 r __ksymtab_arm926_coherent_kern_range c02691e8 r __kstrtab_arm926_coherent_kern_range I successfully call it from my module and my problem is solved. However, I expect that there should be a more platform-independent way to call this function. Is there such a way? Question 3: From setup.c it seems that the function lookup_processor_type() defined in head.S can be called to get a struct proc_info_list that contains the struct cpu_cache_fns that contains the function coherent_kern_range. Also, /proc/kallsyms on my target says: ~ # cat /proc/kallsyms | grep lookup_processor_type c0008154 t __lookup_processor_type c0008190 T lookup_processor_type I tried to get my hands on the coherent_kern_range function using this technique, but when I load my module, I get: ~ # insmod mymod.ko mymod: Unknown symbol lookup_processor_type insmod: error inserting 'mymod.ko': -1 Unknown symbol in module Why did my module fail to load when lookup_processor_type is in the symbol table? Thanks, Brian * I have to invalidate the cache because I have pages that are allocated within my module and mapped to user space via mmap. I used the technique described in Linux Device Drivers by Corbet, Rubini, and Kroah-Hartman, pg 431 "Remapping RAM with the nopage method." Here is the problem: suppose the userspace address of one of these pages is 0xaf000000 and the kernel space address of the same page is 0xbf000000. Now suppose that the kernel module reads the data at 0xbf000000. The cache will contain an up-to-date entry of the data with the tag 0xbf000000. Next, a userspace process reads and writes to its 0xaf000000 address then does an msync. The contents of main memory are now up-to-date and the 0xbf000000 entry in the cache is wrong. However, the cache thinks the entry is correct and if the kernel now reads the data at 0xbf000000 it will be incorrect. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
