On 11/26/2013 11:43 PM, Greg KH wrote: > On Tue, Nov 26, 2013 at 06:35:05PM +0100, Holger Brunck wrote: >> Hi all, >> >> On 11/25/2013 10:18 PM, gregkh@xxxxxxxxxxxxxxxxxxx wrote: >>> >>> This is a note to let you know that I've just added the patch titled >>> >>> Fix a few incorrectly checked [io_]remap_pfn_range() calls >>> >>> to the 3.4-stable tree which can be found at: >>> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary >>> >>> The filename of the patch is: >>> fix-a-few-incorrectly-checked-remap_pfn_range-calls.patch >>> and it can be found in the queue-3.4 subdirectory. >>> >>> If you, or anyone else, feels it should not be added to the stable tree, >>> please let <stable@xxxxxxxxxxxxxxx> know about it. >>> >> >> this patch seems to break the support of a uio driver I have on 3.10-stable. I >> think I figured out whats the problem here. > > Which UIO driver are you referring to? Do you have a pointer to the > source for it anywhere? > honestly it is a out of tree driver I use. After doublechecking my driver and my mmap userspace code I still found no reason for this behaviour. Therefore I spend some time today to reproduce the behaviour with a mainline driver. So I switched on CONFIG_UIO_PDRV for 3.10.20. Then I wrote a small driver which make uses of this generic uio driver. I took the source code (slightly adapted) from: https://lkml.org/lkml/2012/8/29/258 And I wrote a simple main program which tries to mmap this uio device after loading the kernel module. #include <stdio.h> #include <fcntl.h> #include <sys/mman.h> #define MYFPGA_SIZE 0x80 int main() { void *addr; int uio_fd = 0; uio_fd = open("/dev/uio0", O_RDWR); if (uio_fd < 0) printf("Can't open file:/dev/uio0, fd: %d\n", uio_fd); else { addr = mmap(NULL, MYFPGA_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, uio_fd, 0); printf("Adress = %p\n", addr); close(uio_fd); } } And I still see the problems. So with the above example, a size value of 0x80 and some printouts in uio_mmap_physical I get: vma->vm_end = 48002000 vma->vm_start = 48001000 mem->size = 00000080 Therefore the function returns with an error (addr=0xffffffff). If I choose a size of 0x1300 for my kernel module and my mmap userspace program I get: vma->vm_end = 48003000 vma->vm_start = 48001000 mem->size = 00001300 And it fails again. I don't know how the vm_start and vm_end is generated but for me it looks like that they are somehow rounded up to 0x1000 boundaries. If I have a configuration which matches this boundaries, e.g. with a size of 0x2000: vma->vm_end = 48003000 vma->vm_start = 48001000 mem->size = 00002000 everything works fine (addr=0x48001000) Any thoughts? Regards Holger -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html