Re: drm/sysfs lifetime interaction fixes

[Vlastimil Babka <vbabka@suse.cz>]

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@suse.cz>
> 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