When building in the eg vga16 and intelfb framebuffers and page
debugging, we can get hit by a use-after-free oops [1]; with page
debugging disabled, this slips by unnoticed.
When intelfb registers, the vga16 framebuffer is detected covering
it's I/O regions, so it is removed (in
remove_conflicting_framebuffers->unregister_framebuffer). The problem
is the fb_info structure is freed (in
unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree)
before all open files to it are closed, so we get a use-after-free
scenario.
Freeing should be deferred until the last user has gone away. What
approach would make sense here?
Daniel
--- [1]
checking generic (a0000 10000) vs hw (d0000000 10000000)
fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver
Console: switching to colour VGA+ 80x25
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390
PGD 2203ab067 PUD 2203ac067 PMD 0
Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent
CPU 3
Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32
i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci
sdhci mmc_core
Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1
Dell Inc. Latitude E5420/0H5TG2
RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>]
mutex_lock_nested+0x94/0x390
RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046
RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b
RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020
R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478
FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020)
Stack:
ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478
ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2
ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000
Call Trace:
[<ffffffff81375552>] ? lock_fb_info+0x22/0x60
[<ffffffff81375552>] lock_fb_info+0x22/0x60
[<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0
[<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0
[<ffffffff81105dae>] ? might_fault+0x4e/0xa0
[<ffffffff81058e61>] ? get_parent_ip+0x11/0x50
[<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0
[<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
[<ffffffff8104840e>] ? __wake_up+0x4e/0x70
[<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0
[<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10
[<ffffffff813def59>] ? tty_ioctl+0x299/0xa00
[<ffffffff81377214>] fb_ioctl+0x24/0x30
[<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330
[<ffffffff81140e85>] ? fget+0x95/0x240
[<ffffffff81140df0>] ? fget_raw+0x240/0x240
[<ffffffff811531ba>] sys_ioctl+0x4a/0x80
[<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b
Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85
d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0>
0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08
RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390
RSP <ffff88021ee77c08>
CR2: 0000000000000010
---[ end trace cdacd65f5f1b187d ]---
note: plymouthd[271] exited with preempt_count 1
--
Daniel J Blueman
Any ideas on how best to address this issue [0], since it causes
silent corruption, or at best crashes?
Thanks,
Daniel
--- [0]
When building in the eg vga16 and intelfb framebuffers and page
debugging, we can get hit by a use-after-free oops [1]; with page
debugging disabled, this slips by unnoticed.
When intelfb registers, the vga16 framebuffer is detected covering
it's I/O regions, so it is removed (in
remove_conflicting_framebuffers->unregister_framebuffer). The problem
is the fb_info structure is freed (in
unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree)
before all open files to it are closed, so we get a use-after-free
scenario.
Freeing should be deferred until the last user has gone away. What
approach would make sense here?
Daniel
--- [1]
checking generic (a0000 10000) vs hw (d0000000 10000000)
fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver
Console: switching to colour VGA+ 80x25
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390
PGD 2203ab067 PUD 2203ac067 PMD 0
Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent
CPU 3
Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32
i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci
sdhci mmc_core
Pid: 271, comm: plymouthd Tainted: G ? ? ?D ? ? 2.6.39-rc2-350cd+ #1
Dell Inc. Latitude E5420/0H5TG2
RIP: 0010:[<ffffffff81708394>] ?[<ffffffff81708394>]
mutex_lock_nested+0x94/0x390
RSP: 0018:ffff88021ee77c08 ?EFLAGS: 00010046
RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b
RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020
R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478
FS: ?00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000
CS: ?0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020)
Stack:
?ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478
?ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2
?ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000
Call Trace:
?[<ffffffff81375552>] ? lock_fb_info+0x22/0x60
?[<ffffffff81375552>] lock_fb_info+0x22/0x60
?[<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0
?[<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0
?[<ffffffff81105dae>] ? might_fault+0x4e/0xa0
?[<ffffffff81058e61>] ? get_parent_ip+0x11/0x50
?[<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0
?[<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
?[<ffffffff8104840e>] ? __wake_up+0x4e/0x70
?[<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0
?[<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10
?[<ffffffff813def59>] ? tty_ioctl+0x299/0xa00
?[<ffffffff81377214>] fb_ioctl+0x24/0x30
?[<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330
?[<ffffffff81140e85>] ? fget+0x95/0x240
?[<ffffffff81140df0>] ? fget_raw+0x240/0x240
?[<ffffffff811531ba>] sys_ioctl+0x4a/0x80
?[<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b
Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85
d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0>
0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08
RIP ?[<ffffffff81708394>] mutex_lock_nested+0x94/0x390
?RSP <ffff88021ee77c08>
CR2: 0000000000000010
---[ end trace cdacd65f5f1b187d ]---
note: plymouthd[271] exited with preempt_count 1
--
Daniel J Blueman
--
Daniel J Blueman
On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <[email protected]> wrote:
> Any ideas on how best to address this issue [0], since it causes
> silent corruption, or at best crashes?
There is probably no easy short-term fix to this... The complex fix
would be to implement some deferred free with driver-local ref-counting
though to be complete it would have to be done for pretty much every FB
driver!
The mid-term fix would be to have fb_info ref-counted by FB
subsystem (I'm working on it, slowly). This way freeing would be
deferred to when last references is being dropped.
The driver then just has to know when it can't touch underlying
hardware anymore (and do the right thing with framebuffer memory in
case it is still mmapped somewhere).
Bruno
> Thanks,
> Daniel
>
> --- [0]
>
> When building in the eg vga16 and intelfb framebuffers and page
> debugging, we can get hit by a use-after-free oops [1]; with page
> debugging disabled, this slips by unnoticed.
>
> When intelfb registers, the vga16 framebuffer is detected covering
> it's I/O regions, so it is removed (in
> remove_conflicting_framebuffers->unregister_framebuffer). The problem
> is the fb_info structure is freed (in
> unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree)
> before all open files to it are closed, so we get a use-after-free
> scenario.
>
> Freeing should be deferred until the last user has gone away. What
> approach would make sense here?
>
> Daniel
>
> --- [1]
>
> checking generic (a0000 10000) vs hw (d0000000 10000000)
> fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver
> Console: switching to colour VGA+ 80x25
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390
> PGD 2203ab067 PUD 2203ac067 PMD 0
> Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent
> CPU 3
> Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32
> i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci
> sdhci mmc_core
>
> Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1
> Dell Inc. Latitude E5420/0H5TG2
> RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>]
> mutex_lock_nested+0x94/0x390
> RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046
> RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b
> RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020
> R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478
> FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020)
> Stack:
> ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478
> ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2
> ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000
> Call Trace:
> [<ffffffff81375552>] ? lock_fb_info+0x22/0x60
> [<ffffffff81375552>] lock_fb_info+0x22/0x60
> [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0
> [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0
> [<ffffffff81105dae>] ? might_fault+0x4e/0xa0
> [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50
> [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0
> [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
> [<ffffffff8104840e>] ? __wake_up+0x4e/0x70
> [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0
> [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10
> [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00
> [<ffffffff81377214>] fb_ioctl+0x24/0x30
> [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330
> [<ffffffff81140e85>] ? fget+0x95/0x240
> [<ffffffff81140df0>] ? fget_raw+0x240/0x240
> [<ffffffff811531ba>] sys_ioctl+0x4a/0x80
> [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b
> Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85
> d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0>
> 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08
> RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390
> RSP <ffff88021ee77c08>
> CR2: 0000000000000010
> ---[ end trace cdacd65f5f1b187d ]---
> note: plymouthd[271] exited with preempt_count 1
> --
> Daniel J Blueman
>
>
>
On Wed, 20 Apr 2011 08:05:35 +0200
Bruno Pr?mont <[email protected]> wrote:
> On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <[email protected]> wrote:
> > Any ideas on how best to address this issue [0], since it causes
> > silent corruption, or at best crashes?
>
> There is probably no easy short-term fix to this...
The short term fix would be to deliberately leak the buffer. That should
go into 2.6.39-rc right now with a comment explaining the situation.
Otherwise who knows what corruption may occur to user data if unlucky.
The other 'cheat' might be to tweak the API so the removal API isn't a
'destroy' interface but a 'shut down' and has a matching 'restart' one
for when the intelfb unloads at which point vga16fb can carry on with the
original fb_info 8)
Alan
On 20 April 2011 17:56, Alan Cox <[email protected]> wrote:
> On Wed, 20 Apr 2011 08:05:35 +0200
> Bruno Pr?mont <[email protected]> wrote:
>
>> On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <[email protected]> wrote:
>> > Any ideas on how best to address this issue [0], since it causes
>> > silent corruption, or at best crashes?
>>
>> There is probably no easy short-term fix to this...
>
> The short term fix would be to deliberately leak the buffer. That should
> go into 2.6.39-rc right now with a comment explaining the situation.
> Otherwise who knows what corruption may occur to user data if unlucky.
>
> The other 'cheat' might be to tweak the API so the removal API isn't a
> 'destroy' interface but a 'shut down' and has a matching 'restart' one
> for when the intelfb unloads at which point vga16fb can carry on with the
> original fb_info 8)
It looks like Andy Whitcroft addressed this issue some time ago, but
forgot to send the fix upstream:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=patch;h=c5a742b5f78e161d6a13853a7e3e6e1dfa429e69;hp=26a1443f67eea17d4b78ef75df701782cc8bf35b
Let's hope it can hit -rc7 since it's been in Ubuntu's kernel tree for
considerable time, and fixes a silent corrupter:
http://groups.google.com/group/linux.kernel/browse_thread/thread/fc9083f6f380ed5b/f801112b840785cb?show_docid=f801112b840785cb
Thanks,
Daniel
--
Daniel J Blueman
Hi, Daniel J Blueman.
Did you test https://lkml.org/lkml/2011/5/5/208 ? And it works for you ?
Then please reply with your error and an Tested-by.
And CC: "Dave Airlie" <[email protected]>
On 7 May 2011 23:24, Anca Emanuel <[email protected]> wrote:
> Hi, Daniel J Blueman.
>
> Did you test https://lkml.org/lkml/2011/5/5/208 ? And it works for you ?
> Then please reply with your error and an Tested-by.
>
> And CC: "Dave Airlie" <[email protected]>
Tested against 2.6.39-rc6. Instrumentation and debug catches the
(silent without debug) use-after-free case, which now doesn't show up
with this patch, so looks good. Probably good sense to get into
-stable too.
Tested-by: Daniel J Blueman <[email protected]>
Thanks,
Daniel
--
Daniel J Blueman
On Wed, May 11, 2011 at 7:17 PM, Linus Torvalds
<[email protected]> wrote:
> On Wed, May 11, 2011 at 6:02 AM, Alan Cox <[email protected]> wrote:
>>
>> We need some kind of patch for this release, even one where we leak the
>> memory to avoid the scribbles. Random scribbling into freed memory could
>> hit anything including user data or file system meta data - not good.
>
> Yeah.
>
> I looked at just not freeing things, but that ends up being ugly,
> because the actual low-level allocation is being done by the
> framebuffer driver itself (and it gets freed in fb_destroy). Now, it's
> all supposed to use "framebuffer_release()", and maybe they all even
> do, but it just made me worry.
>
> So I ended up looking at just the refcount thing.
>
> This is my trial. It should get the /proc locking right too. But it is
> *ENTIRELY* untested. I looked at the Ubuntu patch, but that one mixed
> up the refcounting with some other issues. I'm sure they are perfectly
> valid fixes too, and should probably be done, but they are also an
> unrelated thing. And the patch from Ubuntu seems to leave the /proc
> accesses unprotected.
>
> The one registered_fb[] access (well, at least in fbmem.c) I didn't
> fix is FBIOPUT_CON2FBMAP, which the Ubuntu patch didn't fix either. It
> would be easy to lock the accesses there, but I don't know what the
> f*ck the code wants to do (it only looks at the entry, but it actually
> *uses* the 'info' that was passed in), so I just passed on that as
> "insane code that makes no sense".
>
> The "remove_conflicting_framebuffers()" function should be locked too,
> but I didn't bother, because it would mean splitting
> unregister_framebuffer() into some helper functions. So that's a
> "fixme later".
>
> Whatever. The patch looks sane.
>
> So *if* this works, I think it's better. I did actually go through the
> patches side-by-side, and they end up very similar (apart from where
> they aren't - the unrelated fb locking changes, and the fact that my
> registration lock is much bigger and covers more). Which is
> understandable, the way I did it was look for accesses to
> "registered_fb[]", and I assume that is what Andy did too.
>
> Testing? I obviously don't see the problem in the first place, so..
>
> ? ? ? ? ? ? ? ? ? ? ? ?Linus
>
With 2.6.39-rc7 I get
[ 19.420036] BUG: unable to handle kernel NULL pointer dereference
at (null)
[ 19.420063] IP: [<ffffffff815a9d3a>] __mutex_lock_slowpath+0xca/0x180
[ 19.420077] PGD 7bbfc067 PUD 7bbfd067 PMD 0
[ 19.420089] Oops: 0002 [#1] SMP
[ 19.420097] last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/uevent
[ 19.420107] CPU 1
[ 19.420111] Modules linked in: parport_pc ppdev
snd_hda_codec_realtek snd_hda_intel snd_hda_codec adt7475 hwmon_vid
snd_hwdep snd_pcm snd_seq_midi snd_rawmidi nouveau ttm drm_kms_helper
snd_seq_midi_event drm i2c_algo_bit snd_seq snd_timer snd_seq_device
psmouse snd serio_raw soundcore video snd_page_alloc intel_agp
intel_gtt lp parport r8169 pata_marvell ahci mii libahci btrfs
zlib_deflate crc32c libcrc32c
[ 19.420211]
[ 19.420216] Pid: 268, comm: plymouthd Not tainted 2.6.39-rc7 #1
MICRO-STAR INTERNATIONAL CO.,LTD MS-7360/MS-7360
[ 19.420231] RIP: 0010:[<ffffffff815a9d3a>] [<ffffffff815a9d3a>]
__mutex_lock_slowpath+0xca/0x180
[ 19.420244] RSP: 0018:ffff880036ef1e28 EFLAGS: 00010246
[ 19.420251] RAX: 0000000000000000 RBX: ffff88007f817008 RCX: 0000000000000001
[ 19.420260] RDX: ffff880036ef1e38 RSI: ffff88006dd87600 RDI: ffff88007f81700c
[ 19.420269] RBP: ffff880036ef1e88 R08: 00000000ffffffff R09: 0000000000000000
[ 19.420279] R10: ffff88006dd87610 R11: 0000000000000246 R12: ffff8800369dc440
[ 19.420404] R13: ffff88007f81700c R14: 00000000ffffffff R15: ffff88007f817010
[ 19.420414] FS: 00007f9f557b6720(0000) GS:ffff88007fc80000(0000)
knlGS:0000000000000000
[ 19.420424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 19.420432] CR2: 0000000000000000 CR3: 000000007bbfb000 CR4: 00000000000006e0
[ 19.420441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 19.420450] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 19.420460] Process plymouthd (pid: 268, threadinfo
ffff880036ef0000, task ffff8800369dc440)
[ 19.420469] Stack:
[ 19.420473] ffff880036ef1e78 ffff880036ef0000 ffff88007f817010
0000000000000000
[ 19.420487] ffff880036ef1e58 0000000000000000 ffff88006dd87610
ffff88007f817008
[ 19.420503] ffff88007f817008 ffff88007d3d9480 ffff88007be34d90
ffff88007be34d90
[ 19.420518] Call Trace:
[ 19.420525] [<ffffffff815a97bb>] mutex_lock+0x2b/0x50
[ 19.420535] [<ffffffff8130acc9>] fb_release+0x29/0x70
[ 19.420545] [<ffffffff8115d04a>] fput+0xea/0x220
[ 19.420553] [<ffffffff81159296>] filp_close+0x66/0x90
[ 19.420561] [<ffffffff81159867>] sys_close+0xb7/0x120
[ 19.420569] [<ffffffff815b30c2>] system_call_fastpath+0x16/0x1b
[ 19.420576] Code: 90 4c 8d 6b 04 4c 8d 7b 08 41 be ff ff ff ff 4c
89 ef e8 5a 13 00 00 48 8b 43 10 48 8d 55 b0 4c 89 7d b0 48 89 53 10
48 89 45 b8
[ 19.420658] 89 10 44 89 f0 4c 89 65 c0 87 03 83 f8 01 75 24 eb 2c 0f 1f
[ 19.420698] RIP [<ffffffff815a9d3a>] __mutex_lock_slowpath+0xca/0x180
[ 19.420709] RSP <ffff880036ef1e28>
[ 19.420714] CR2: 0000000000000000
[ 19.501432] r8169 0000:04:00.0: eth0: link up
[ 19.501773] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 21.049817] [drm] nouveau 0000:01:00.0: EvoCh 2 Mthd 0x0080 Data
0x00000000 (0x000b 0x05)
[ 21.053688] ---[ end trace 15bf5450f28092e3 ]---
Full dmesg at: http://pastebin.com/BTzX30be
After your patch:
I get an hard freeze. I can only get a photo If you are interested.