Hi, We have observed an issue where kmalloc of a small sized memory causes an occasional trace when unmapping the mmaped memory via UIO framework This trace is coming when kernel sees a negative value in page->_mapcount. Trace is pasted at the end of the mail.
After debugging this issue further, we realized following sequence occurs when kmalloc is used to allocate small memory using slub allocator: 1. Frozen bit (msb) of the page from which memory has been allocated is set (which is an union with _mapcount). 2. If there are free objects in the the same page then this frozen bit remains set even after kernel boots completely. 3. When user space calls unmap of this memory, vma_unmap_single() treats the _mapcount as a negative (as frozen bit is set), causing a trace. We are not sure whether exposing kernel memory of size less than PAGE_SIZE via UIO is a valid use case ? In case this is an invalid use case then shouldn't the UIO framework restrict mapping of non PAGE_SIZE aligned memory and size not in order of PAGE_SIZE. Trace: BUG: Bad page map in process test-mumap pte:2a00040ef92af53 pmd:43ad50a003 page:ffffffbec3be4a80 count:2 mapcount:0x82000201 mapping: (null) index:0x0 flags: 0x94(referenced|dirty|slab) page dumped because: bad pte addr:0000007fad20a000 vm_flags:040400ff anon_vma: (null) mapping:ffffffc3ad9c6630 index:3 file:uio0 fault:uio_vma_fault mmap:uio_mmap readpage: (null) CPU: 0 PID: 2179 Comm: test-xgene-qmtm Not tainted 4.1.0 #102 Hardware name: APM board (DT) Call trace: [<ffffffc000088b40>] dump_backtrace+0x0/0x124 [<ffffffc000088c74>] show_stack+0x10/0x1c [<ffffffc000908328>] dump_stack+0x84/0xc8 [<ffffffc000150404>] print_bad_pte+0x15c/0x1f8 [<ffffffc000151e90>] unmap_single_vma+0x478/0x678 [<ffffffc000152934>] unmap_vmas+0x64/0xd4 [<ffffffc000157a7c>] unmap_region+0x8c/0x140 [<ffffffc000159b1c>] do_munmap+0x174/0x3c4 [<ffffffc000159dac>] vm_munmap+0x40/0x64 [<ffffffc00015ac20>] SyS_munmap+0x20/0x34 Thanks, Ankit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
