Hello all, I hope this is a reasonable place to post a bug. If I fix
it I can post a fix too.
I believe there might be a bug in deferred io. In my fb driver I have
a block of memory, allocated with kmalloc, that I can mmap, write to,
and munmap perfectly fine using my own mmap routine. As soon as I
switch to deferred io, there's a problem:
From userspace, I can mmap the framebuffer memory fine and write to
it. The deferred io driver routine is called and updates the display
perfectly correctly. As soon as I call munmap() I get a repeated
kernel messages. This happens on ARM but not under an Ubuntu
Virtualbox VM (x86):
BUG: Bad page state in process fbtest1 pfn:ad11d
page:c0dc03a0 count:0 mapcount:0 mapping:edbf7144 index:0x1d
page flags: 0x94(referenced|dirty|slab)
Modules linked in: hhlcd28a(O) sysimgblt sysfillrect syscopyarea
fb_sys_fops bnep ipv6 mwifiex_sdio mwifiex btmrvl_sdio firmware_class
btmrvl cfg80211 bluetooth rfkill
[<c0014bc8>] (unwind_backtrace+0x0/0x11c) from [<c00c44d4>] (bad_page+0xd0/0xfc)
[<c00c44d4>] (bad_page+0xd0/0xfc) from [<c00c45c0>]
(free_pages_prepare+0xc0/0x150)
[<c00c45c0>] (free_pages_prepare+0xc0/0x150) from [<c00c5a34>]
(free_hot_cold_page+0x20/0x188)
[<c00c5a34>] (free_hot_cold_page+0x20/0x188) from [<c00c5dc4>]
(free_hot_cold_page_list+0x7c/0x9c)
[<c00c5dc4>] (free_hot_cold_page_list+0x7c/0x9c) from [<c00c90c0>]
(release_pages+0x1b4/0x1c8)
[<c00c90c0>] (release_pages+0x1b4/0x1c8) from [<c00ea854>]
(free_pages_and_swap_cache+0x8c/0x9c)
[<c00ea854>] (free_pages_and_swap_cache+0x8c/0x9c) from [<c00dfff4>]
(unmap_region+0x100/0x154)
[<c00dfff4>] (unmap_region+0x100/0x154) from [<c00e116c>]
(do_munmap+0x218/0x2a4)
[<c00e116c>] (do_munmap+0x218/0x2a4) from [<c00e1234>] (vm_munmap+0x3c/0x50)
[<c00e1234>] (vm_munmap+0x3c/0x50) from [<c000dc20>] (ret_fast_syscall+0x0/0x30)
[repeated for N pages]
root@duovero:~/testdrv#
I will now convert to using vmalloc and check to see if this happens too.
Thanks,
Conor.
Confirmed. This does not happen with vmalloc. The pointers are in
quite different places in case that's relevant:
kptr = ed460000
vptr = f23d1000
Aside: the reason I'm using kmalloc (or __get_free_pages()) is to have
a physically contiguous buffer for DMA. I currently copy the
framebuffer into a DMA buffer which is less efficient but works (thank
goodness!). I will trace the bug myself when I get time.
Conor.
On Sat, Mar 15, 2014 at 11:29 AM, Conor O [off-list ref] wrote:
Hello all, I hope this is a reasonable place to post a bug. If I fix
it I can post a fix too.
I believe there might be a bug in deferred io. In my fb driver I have
a block of memory, allocated with kmalloc, that I can mmap, write to,
and munmap perfectly fine using my own mmap routine. As soon as I
switch to deferred io, there's a problem:
From userspace, I can mmap the framebuffer memory fine and write to
it. The deferred io driver routine is called and updates the display
perfectly correctly. As soon as I call munmap() I get a repeated
kernel messages. This happens on ARM but not under an Ubuntu
Virtualbox VM (x86):
BUG: Bad page state in process fbtest1 pfn:ad11d
page:c0dc03a0 count:0 mapcount:0 mapping:edbf7144 index:0x1d
page flags: 0x94(referenced|dirty|slab)
Modules linked in: hhlcd28a(O) sysimgblt sysfillrect syscopyarea
fb_sys_fops bnep ipv6 mwifiex_sdio mwifiex btmrvl_sdio firmware_class
btmrvl cfg80211 bluetooth rfkill
[<c0014bc8>] (unwind_backtrace+0x0/0x11c) from [<c00c44d4>] (bad_page+0xd0/0xfc)
[<c00c44d4>] (bad_page+0xd0/0xfc) from [<c00c45c0>]
(free_pages_prepare+0xc0/0x150)
[<c00c45c0>] (free_pages_prepare+0xc0/0x150) from [<c00c5a34>]
(free_hot_cold_page+0x20/0x188)
[<c00c5a34>] (free_hot_cold_page+0x20/0x188) from [<c00c5dc4>]
(free_hot_cold_page_list+0x7c/0x9c)
[<c00c5dc4>] (free_hot_cold_page_list+0x7c/0x9c) from [<c00c90c0>]
(release_pages+0x1b4/0x1c8)
[<c00c90c0>] (release_pages+0x1b4/0x1c8) from [<c00ea854>]
(free_pages_and_swap_cache+0x8c/0x9c)
[<c00ea854>] (free_pages_and_swap_cache+0x8c/0x9c) from [<c00dfff4>]
(unmap_region+0x100/0x154)
[<c00dfff4>] (unmap_region+0x100/0x154) from [<c00e116c>]
(do_munmap+0x218/0x2a4)
[<c00e116c>] (do_munmap+0x218/0x2a4) from [<c00e1234>] (vm_munmap+0x3c/0x50)
[<c00e1234>] (vm_munmap+0x3c/0x50) from [<c000dc20>] (ret_fast_syscall+0x0/0x30)
[repeated for N pages]
root@duovero:~/testdrv#
I will now convert to using vmalloc and check to see if this happens too.
Thanks,
Conor.
From: David Herrmann <hidden> Date: 2014-03-16 16:25:11
Hi
On Sat, Mar 15, 2014 at 12:29 PM, Conor O [off-list ref] wrote:
Hello all, I hope this is a reasonable place to post a bug. If I fix
it I can post a fix too.
I believe there might be a bug in deferred io. In my fb driver I have
a block of memory, allocated with kmalloc, that I can mmap, write to,
and munmap perfectly fine using my own mmap routine. As soon as I
switch to deferred io, there's a problem:
From userspace, I can mmap the framebuffer memory fine and write to
it. The deferred io driver routine is called and updates the display
perfectly correctly. As soon as I call munmap() I get a repeated
kernel messages. This happens on ARM but not under an Ubuntu
Virtualbox VM (x86):
You map kmalloc()ed memory to user-space? How do you guarantee that
it's page-aligned? How do you protect kernel-internal state? This
sounds really odd.
Anyhow, you really need to post a link to the code in question if you
want people to help you.
Thanks
David
On Sun, Mar 16, 2014 at 4:25 PM, David Herrmann [off-list ref] wrote:
Hi
On Sat, Mar 15, 2014 at 12:29 PM, Conor O [off-list ref] wrote:
quoted
Hello all, I hope this is a reasonable place to post a bug. If I fix
it I can post a fix too.
I believe there might be a bug in deferred io. In my fb driver I have
a block of memory, allocated with kmalloc, that I can mmap, write to,
and munmap perfectly fine using my own mmap routine. As soon as I
switch to deferred io, there's a problem:
From userspace, I can mmap the framebuffer memory fine and write to
it. The deferred io driver routine is called and updates the display
perfectly correctly. As soon as I call munmap() I get a repeated
kernel messages. This happens on ARM but not under an Ubuntu
Virtualbox VM (x86):
You map kmalloc()ed memory to user-space? How do you guarantee that
it's page-aligned? How do you protect kernel-internal state? This
sounds really odd.
Anyhow, you really need to post a link to the code in question if you
want people to help you.
I was generalising a bit. I could have used __get_free_pages instead
and have the same issue going. In this case, I manually page aligned
the pointer. Yes, that might be considered a touch weird. I thought it
might use less memory than get_free_pages would. I mmap the pointer to
userspace in a similar way to
http://lxr.free-electrons.com/source/drivers/video/vfb.c. I get the
pfn for a particular position in the buffer and remap the range:
bufpfn = virt_to_phys(vpos) >> PAGE_SHIFT;
if (remap_pfn_range(vma, vma->vm_start, bufpfn, vsize, vma->vm_page_prot))
return -EAGAIN;
However, that's really besides the point. Deferred io changes the
.fb_mmap function pointer in the fb_ops structure to point to its own
anyway. My framebuffer driver works fine with vmalloc as it stands so
I'm not in need of assistance. I'm just saying that it all collapses
if I use kmalloc on Arm. I haven't had time to trace the reason but
maybe its unmarking each page instead of a range. I don't know enough
about the virtual memory system to even guess.