user space mmap overlapping with kernel ioremap range
Sorry for yet another mmap-related question.
Bottom line question - is there any problem with mmap'ing (with /dev/mem) over a range that includes memory requested (and granted to) a kernel module?
details follow ...
Embedded ARM based system kernel is 2.6.29 basically.
I have a simple driver that needs to check a GPIO status line, read from phys address (easy enough) and toggle another GPIO line. (Using iowrite32 call - slower than I would like, but that is another issue.) Data arrives very regularly and predictably and there is plenty of buffering at various points - kernel timer is used rather than interrupt at this stage.
The driver claims address range:
0xFFFFF000 for 0x0A00 bytes long.
(check_mem_region followed by request_mem_region and ioremap).
I want access in user space to these GPIO controllers (and some other hardware registers) as well. So I mmap (on /dev/mem) an overlapping region:
0xFFFFE0000 for length 0x2000.
This all seems to go OK - the return values from the kernel module calls and the user space call to mmap all pass OK. All return values are checked carefully and defensively.
However, I am getting occasional seg faults on some fairly simple user space processing and I am wondering if there is a problem with these overlapping memory regions.
This is not a mutual exclusion issue.
I have searched pretty hard and been through ldd3. I did try to mmap through my driver but this caused more problems - probably as the address range in the driver is less than a page (other drivers in the system claim some of the surrounding memory.
Obviously it is necessary to *not* disturb the memory locations used by the being managed by the driver - the nature of the Atmel 9260 GPIO ports make this easy though.
So...is there any problem with mmap'ing (with /dev/mem) over a range that includes memory requested (and granted to) a kernel module?
For those of you still here, ...thanks for any help you can provide.