Re: Patch not upstream: fix race between open and removal of framebuffers

From: Anca Emanuel
Date: Thu May 05 2011 - 12:54:27 EST


On Thu, Apr 7, 2011 at 5:00 PM, Tim Gardner <tim.gardner@xxxxxxxxxxxxx> wrote:
> On 04/02/2011 09:37 AM, Anca Emanuel wrote:
>>
>> This patch: http://is.gd/otIfGc is not in mainline. Any reason for that ?
>>
>> see: https://lkml.org/lkml/2011/2/24/445
>>
>> Please post c5a742b5f78e161d6a13853a7e3e6e1dfa429e69
>> UBUNTU: SAUCE: fbcon -- fix race between open and removal of framebuffers
>> to lkml with CC: stable@xxxxxxxxxx
>>
>> -----------------------------------------------------------------
>>
>>
>>  From c5a742b5f78e161d6a13853a7e3e6e1dfa429e69 Mon Sep 17 00:00:00 2001
>> From: Andy Whitcroft<apw@xxxxxxxxxxxxx>
>> Date: Thu, 29 Jul 2010 16:48:20 +0100
>> Subject: [PATCH 1/1] UBUNTU: SAUCE: fbcon -- fix race between open and
>> removal of framebuffers
>>
>> Currently there is no locking for updates to the registered_fb list.
>> This allows an open through /dev/fbN to pick up a registered framebuffer
>> pointer in parallel with it being released, as happens when a conflicting
>> framebuffer is ejected or on module unload.  There is also no reference
>> counting on the framebuffer descriptor which is referenced from all open
>> files, leading to references to released or reused memory to persist on
>> these open files.
>>
>> This patch adds a reference count to the framebuffer descriptor to prevent
>> it from being released until after all pending opens are closed.  This
>> allows the pending opens to detect the closed status and unmap themselves.
>> It also adds locking to the framebuffer lookup path, locking it against
>> the removal path such that it is possible to atomically lookup and take a
>> reference to the descriptor.  It also adds locking to the read and write
>> paths which currently could access the framebuffer descriptor after it
>> has been freed.  Finally it moves the device to FBINFO_STATE_REMOVED to
>> indicate that all access should be errored for this device.
>>
>> Signed-off-by: Andy Whitcroft<apw@xxxxxxxxxxxxx>
>> Acked-by: Stefan Bader<stefan.bader@xxxxxxxxxxxxx>
>> Signed-off-by: Leann Ogasawara<leann.ogasawara@xxxxxxxxxxxxx>
>> ---
>>  drivers/video/fbmem.c |  132
>> ++++++++++++++++++++++++++++++++++++++-----------
>>  include/linux/fb.h    |    2 +
>>  2 files changed, 105 insertions(+), 29 deletions(-)
>>
>
> The patch author is away on vacation. I'm gonna leave it up to him to pursue
> upstreaming upon his return.
>
> rtg
> --
> Tim Gardner tim.gardner@xxxxxxxxxxxxx
>

I'm using 2.6.39-rc6 now

I still get:
[ 21.964367] BUG: unable to handle kernel paging request at 0000010a00000010
[ 21.964396] IP: [<ffffffff8130abe0>] fb_release+0x30/0x70
[ 21.964410] PGD 0
[ 21.964416] Oops: 0000 [#1] SMP
[ 21.964424] last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/uevent
[ 21.964434] CPU 1
[ 21.964438] Modules linked in: parport_pc ppdev
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
adt7475 hwmon_vid snd_seq_midi snd_rawmidi snd_seq_midi_event nouveau
snd_seq snd_timer snd_seq_device ttm drm_kms_helper snd intel_agp
psmouse soundcore serio_raw intel_gtt snd_page_alloc drm i2c_algo_bit
video lp parport pata_marvell ahci libahci r8169 mii
[ 21.964528]
[ 21.964533] Pid: 221, comm: plymouthd Not tainted 2.6.39-rc6 #7
MICRO-STAR INTERNATIONAL CO.,LTD MS-7360/MS-7360
[ 21.964548] RIP: 0010:[<ffffffff8130abe0>] [<ffffffff8130abe0>]
fb_release+0x30/0x70
[ 21.964560] RSP: 0018:ffff880037211eb8 EFLAGS: 00010286
[ 21.964566] RAX: ffff880037210000 RBX: ffff88007f817000 RCX: 0000000000000001
[ 21.964573] RDX: 0000010a00000000 RSI: ffff8800370f5540 RDI: ffff88007f817008
[ 21.964580] RBP: ffff880037211ec8 R08: 0000000000000000 R09: 0000000000000000
[ 21.964588] R10: ffff8800370f5550 R11: 0000000000000246 R12: ffff88007f817008
[ 21.964595] R13: ffff88007d3db540 R14: ffff88007be34d90 R15: ffff88007be34d90
[ 21.964604] FS: 00007fb335025720(0000) GS:ffff88007fc80000(0000)
knlGS:0000000000000000
[ 21.964739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 21.964746] CR2: 0000010a00000010 CR3: 000000007b41a000 CR4: 00000000000006e0
[ 21.964754] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 21.964762] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 21.964770] Process plymouthd (pid: 221, threadinfo
ffff880037210000, task ffff880036cd16c0)
[ 21.964778] Stack:
[ 21.964782] ffff8800370f5540 0000000000000008 ffff880037211f18
ffffffff8115cfaa
[ 21.964797] ffff8800370f5550 ffff8800793c7b00 ffff88006744fcd0
ffff8800370f5540
[ 21.964811] ffff88007c3b9080 0000000000000000 000000000000000b
0000000000000000
[ 21.964825] Call Trace:
[ 21.964834] [<ffffffff8115cfaa>] fput+0xea/0x220
[ 21.964842] [<ffffffff811591f6>] filp_close+0x66/0x90
[ 21.964849] [<ffffffff811597c7>] sys_close+0xb7/0x120
[ 21.964858] [<ffffffff815b3002>] system_call_fastpath+0x16/0x1b
[ 21.964865] Code: 83 ec 10 48 89 1c 24 4c 89 64 24 08 0f 1f 44 00
00 48 8b 9e a0 00 00 00 4c 8d 63 08 4c 89 e7 e8 d7 ea 29 00 48 8b 93
b8 03 00 00
[ 21.964944] 8b 42 10 48 85 c0 74 11 be 01 00 00 00 48 89 df ff d0 48 8b
[ 21.964983] RIP [<ffffffff8130abe0>] fb_release+0x30/0x70
[ 21.964992] RSP <ffff880037211eb8>
[ 21.964997] CR2: 0000010a00000010

I can use de PC, but when it wake up from S3, hangs.
full dmesg at: http://pastebin.com/rhMJrF2x
uname -a
Linux ubuntu 2.6.39-rc6 #7 SMP Wed May 4 12:26:39 EEST 2011 x86_64
x86_64 x86_64 GNU/Linux

I read that Ubuntu have something like 150 patches NOT upstreamed. Why ?
And other guys complaining about the hard work they do to maintain
stable and mainline.

If you not upstream your work, then what is the ideea ? Keep it only
for Ubuntu users ?

I have the latest Linus git tree, and I applied the patch like this:
wget http://is.gd/otIfGc
git apply otIfGc

Linus, if nobody ask you, please apply the patch.
With Tested-by: Anca Emanuel <anca.emanuel@xxxxxxxxx>

full dmesg after the patch: http://pastebin.com/XtNXzgPc
Tested sleep and wake up from S3.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/