[#3974] opening/reading/mmaping BF54x framebuffer simultaneously triggers a BUG()
Submitted By: Mike Frysinger
Open Date
2008-03-17 18:46:03 Close Date
2008-03-18 06:51:47
Priority:
Medium Assignee:
Michael Hennerich
Status:
Closed Fixed In Release:
N/A
Found In Release:
N/A Release:
2.6.22.18-ADI-2008R1-svn4447
Category:
N/A Board:
EZKIT Lite
Processor:
BF548 Silicon Revision:
Is this bug repeatable?:
Yes Resolution:
Fixed
Uboot version or rev.:
Toolchain version or rev.:
App binary format:
N/A
Summary: opening/reading/mmaping BF54x framebuffer simultaneously triggers a BUG()
Details:
the attached test code, when run three times like so:
/a.out &
/a.out &
/a.out &
will trigger:
BUG: failure at mm/nommu.c:470/add_nommu_vma()!
:/Kernel panic - not syncing: BUG!
seems to be bad interaction with doing the framebuffer ioctls and the mmap
Follow-ups
--- Michael Hennerich 2008-03-18 04:53:47
>seems to be bad interaction with doing the framebuffer ioctls and the mmap
No it's quite simple. It can be fixed by adding VM_SHARED to the fb mmap helper
function's vm_flags.
All our fb driver share the same problem.
- vma->vm_flags |= VM_MAYSHARE;
+ vma->vm_flags |= VM_MAYSHARE | VM_SHARED;
The questions is do we really want this?
Are there any real world use cases?
Allowing two processes to write into the fb doesn't work well?
-Michael
--- Michael Hennerich 2008-03-18 05:29:45
I assume you have a real world use case for this...
I checked a fix into the 2008R1 branch.
-Michael
--- Mike Frysinger 2008-03-18 06:51:46
without the ioctls though, i could never get it to crash
all of our framebuffers should allow sharing of the memory ... this is expected
behavior in general, and there's no technical reason to disallow it that i know
of
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
test.c text/x-csrc 945 Mike Frysinger