On 12.10.2013 14:54, Fengguang Wu wrote:
On Sat, Oct 12, 2013 at 07:47:05AM +1000, Dave Airlie wrote:
This is my preferred method of fixing it as I don't think the lifetimes need
to be tied so closely, though this requires review my someone to make sure
my unregistering etc is correct and in the right place.
Apparently this fixes the problem for Fengguang, and the code looks
cleaner too. Thanks,
Leaves the fixes or next question, since I suppose its not technically
a regression, -next is probably fine, let me know if you'd l like them
earlier.
Dave, I tested the two patches on top of drm-next and find that it
does help eliminate the lots of oops messages in the below kernels.
However in the 2nd config, the patched kernel has one new oops type
than its base kernels (6aba5b6 and v3.12-rc3). v3.12-rc4 is also
tested for your reference. In the 3nd config, both patched and base
kernels have that oops:
[ 96.969429] init: plymouth-upstart-bridge main process (309) terminated with status 1
* Asking all remaining processes to terminate...
[ 97.260371] BUG: Bad page map in process killall5 pte:4f426de0 pmd:0f4f4067
[ 97.261114] addr:3fc00000 vm_flags:00100173 anon_vma:4f4066c0 mapping: (null) index:3ffe6
[ 97.261912] CPU: 0 PID: 334 Comm: killall5 Not tainted 3.12.0-rc3-00156-gdaeb5e3 #1
[ 97.262633] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 97.263192] 3fc00000 4f4c1e14 4212e45c 4fbff9a0 4f4c1e4c 411a9c4b 4262ade0 3fc00000
[ 97.264051] 00100173 4f4066c0 00000000 0003ffe6 4f426de0 0003ffe6 00000000 4fbff9a0
[ 97.264906] 3fc00000 3fc00000 4f4c1e60 411ab50e 00000000 4f464000 00000000 4f4c1ed0
[ 97.265751] Call Trace:
[ 97.266022] [<4212e45c>] dump_stack+0xbb/0x14b
[ 97.266456] [<411a9c4b>] print_bad_pte+0x28b/0x2c0
[ 97.266931] [<411ab50e>] vm_normal_page+0xae/0xe0
[ 97.267388] [<411b37f3>] munlock_vma_pages_range+0x143/0x320
[ 97.267950] [<410d30fd>] ? sched_clock_cpu+0x20d/0x250
[ 97.268451] [<411bacee>] exit_mmap+0x7e/0x200
[ 97.268893] [<4131de9c>] ? __const_udelay+0x2c/0x40
[ 97.269369] [<410adf28>] ? __rcu_read_unlock+0x68/0x150
[ 97.269888] [<4123227b>] ? exit_aio+0x11b/0x280
[ 97.270412] [<4123217c>] ? exit_aio+0x1c/0x280
[ 97.270892] [<410829c7>] ? do_exit+0x697/0x1280
[ 97.271332] [<4107a1a1>] mmput+0x81/0x170
[ 97.271726] [<410829dc>] do_exit+0x6ac/0x1280
[ 97.272166] [<410bad75>] ? hrtimer_nanosleep+0x1f5/0x210
[ 97.272679] [<4215328a>] ? sysenter_exit+0xf/0x45
[ 97.273151] [<41083751>] do_group_exit+0x131/0x160
[ 97.273617] [<410837ad>] SyS_exit_group+0x2d/0x30
[ 97.274088] [<42153251>] sysenter_do_call+0x12/0x3c
[ 97.274560] Disabling lock debugging due to kernel taint
* All processes ended within 1 seconds....
That oops message looks very like the one I reported for this commit.
commit 7a8010cd36273ff5f6fea5201ef9232f30cebbd9
Author: Vlastimil Babka<vbabka@xxxxxxx>
Date: Wed Sep 11 14:22:35 2013 -0700
mm: munlock: manual pte walk in fast path instead of follow_page_mask()
Vlastimil Babka, has this bug been fixed in -rc4?
Yes, this should have been fixed by commit eadb41ae82f80210 "mm/mlock.c:
prevent walking off the end of a pagetable in no-pmd configuration",
merged between rc3 and rc4.
Vlastimil Babka
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
