9e769ff3f5
A lock ordering issue can cause deadlocks: in framebuffer/console code, all needed struct fb_info locks are taken before acquire_console_sem(), in places which need to take console semaphore. But fb_set_suspend is always called with console semaphore held, and inside it we call lock_fb_info which gets the fb_info lock, inverse locking order of what the rest of the code does. This causes a real deadlock issue, when we write to state fb sysfs attribute (which calls fb_set_suspend) while a framebuffer is being unregistered by remove_conflicting_framebuffers, as can be shown by following show blocked state trace on a test program which loads i915 and runs another forked processes writing to state attribute: Test process with semaphore held and trying to get fb_info lock: .. fb-test2 D 0000000000000000 0 237 228 0x00000000 ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0 ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530 00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0 Call Trace: [<ffffffff8141287a>] __mutex_lock_slowpath+0x11a/0x1e0 [<ffffffff814142f2>] ? _raw_spin_lock_irq+0x22/0x40 [<ffffffff814123d3>] mutex_lock+0x23/0x50 [<ffffffff8125dfc5>] lock_fb_info+0x25/0x60 [<ffffffff8125e3f0>] fb_set_suspend+0x20/0x80 [<ffffffff81263e2f>] store_fbstate+0x4f/0x70 [<ffffffff812e7f70>] dev_attr_store+0x20/0x30 [<ffffffff811c46b4>] sysfs_write_file+0xd4/0x160 [<ffffffff81155a26>] vfs_write+0xc6/0x190 [<ffffffff81155d51>] sys_write+0x51/0x90 [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b .. modprobe process stalled because has the fb_info lock (got inside unregister_framebuffer) but waiting for the semaphore held by the test process which is waiting to get the fb_info lock: .. modprobe D 0000000000000000 0 230 218 0x00000000 ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001 ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20 00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0 Call Trace: [<ffffffff81411fe5>] schedule_timeout+0x215/0x310 [<ffffffff81058051>] ? get_parent_ip+0x11/0x50 [<ffffffff814130dd>] __down+0x6d/0xb0 [<ffffffff81089f71>] down+0x41/0x50 [<ffffffff810629ac>] acquire_console_sem+0x2c/0x50 [<ffffffff812ca53d>] unbind_con_driver+0xad/0x2d0 [<ffffffff8126f5f7>] fbcon_event_notify+0x457/0x890 [<ffffffff814144ff>] ? _raw_spin_unlock_irqrestore+0x1f/0x50 [<ffffffff81058051>] ? get_parent_ip+0x11/0x50 [<ffffffff8141836d>] notifier_call_chain+0x4d/0x70 [<ffffffff8108a3b8>] __blocking_notifier_call_chain+0x58/0x80 [<ffffffff8108a3f6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff8125dabb>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff8125e6ac>] unregister_framebuffer+0x7c/0x130 [<ffffffff8125e8b3>] remove_conflicting_framebuffers+0x153/0x180 [<ffffffff8125eef3>] register_framebuffer+0x93/0x2c0 [<ffffffffa0331112>] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper] [<ffffffffa03314a3>] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper] [<ffffffffa03318dd>] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper] [<ffffffffa037b588>] intel_fbdev_init+0xa8/0x160 [i915] [<ffffffffa0343d74>] i915_driver_load+0x854/0x12b0 [i915] [<ffffffffa02f0e7e>] drm_get_pci_dev+0x19e/0x360 [drm] [<ffffffff8141821d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffffa0386f91>] i915_pci_probe+0x15/0x17 [i915] [<ffffffff8124481f>] local_pci_probe+0x5f/0xd0 [<ffffffff81244f89>] pci_device_probe+0x119/0x120 [<ffffffff812eccaa>] ? driver_sysfs_add+0x7a/0xb0 [<ffffffff812ed003>] driver_probe_device+0xa3/0x290 [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0 [<ffffffff812ed29b>] __driver_attach+0xab/0xb0 [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0 [<ffffffff812ebd3e>] bus_for_each_dev+0x5e/0x90 [<ffffffff812ecc2e>] driver_attach+0x1e/0x20 [<ffffffff812ec6f2>] bus_add_driver+0xe2/0x320 [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffff812ed536>] driver_register+0x76/0x140 [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffff81245216>] __pci_register_driver+0x56/0xd0 [<ffffffffa02f1264>] drm_pci_init+0xe4/0xf0 [drm] [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffffa02e84a8>] drm_init+0x58/0x70 [drm] [<ffffffffa03aa094>] i915_init+0x94/0x96 [i915] [<ffffffff81002194>] do_one_initcall+0x44/0x190 [<ffffffff810a066b>] sys_init_module+0xcb/0x210 [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b .. fb-test2 which reproduces above is available on kernel.org bug #26232. To solve this issue, avoid calling lock_fb_info inside fb_set_suspend, and move it out to where needed (callers of fb_set_suspend must call lock_fb_info before if needed). So far, the only place which needs to call lock_fb_info is store_fbstate, all other places which calls fb_set_suspend are suspend/resume hooks that should not need the lock as they should be run only when processes are already frozen in suspend/resume. References: https://bugzilla.kernel.org/show_bug.cgi?id=26232 Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: stable@kernel.org |
||
---|---|---|
.. | ||
aty | ||
backlight | ||
console | ||
display | ||
geode | ||
i810 | ||
intelfb | ||
kyro | ||
logo | ||
matrox | ||
mb862xx | ||
mbx | ||
msm | ||
nvidia | ||
omap | ||
omap2 | ||
pnx4008 | ||
riva | ||
savage | ||
sis | ||
vermilion | ||
via | ||
68328fb.c | ||
acornfb.c | ||
acornfb.h | ||
amba-clcd.c | ||
amifb.c | ||
arcfb.c | ||
arkfb.c | ||
asiliantfb.c | ||
atafb_iplan2p2.c | ||
atafb_iplan2p4.c | ||
atafb_iplan2p8.c | ||
atafb_mfb.c | ||
atafb_utils.h | ||
atafb.c | ||
atafb.h | ||
atmel_lcdfb.c | ||
au1100fb.c | ||
au1100fb.h | ||
au1200fb.c | ||
au1200fb.h | ||
bf54x-lq043fb.c | ||
bf537-lq035.c | ||
bfin_adv7393fb.c | ||
bfin_adv7393fb.h | ||
bfin-lq035q1-fb.c | ||
bfin-t350mcqb-fb.c | ||
broadsheetfb.c | ||
bt431.h | ||
bt455.h | ||
bw2.c | ||
c2p_core.h | ||
c2p_iplan2.c | ||
c2p_planar.c | ||
c2p.h | ||
carminefb_regs.h | ||
carminefb.c | ||
carminefb.h | ||
cfbcopyarea.c | ||
cfbfillrect.c | ||
cfbimgblt.c | ||
cg3.c | ||
cg6.c | ||
cg14.c | ||
chipsfb.c | ||
cirrusfb.c | ||
clps711xfb.c | ||
cobalt_lcdfb.c | ||
controlfb.c | ||
controlfb.h | ||
cyber2000fb.c | ||
cyber2000fb.h | ||
da8xx-fb.c | ||
dnfb.c | ||
edid.h | ||
efifb.c | ||
ep93xx-fb.c | ||
epson1355fb.c | ||
fb_ddc.c | ||
fb_defio.c | ||
fb_draw.h | ||
fb_notify.c | ||
fb_sys_fops.c | ||
fb-puv3.c | ||
fbcmap.c | ||
fbcvt.c | ||
fbmem.c | ||
fbmon.c | ||
fbsysfs.c | ||
ffb.c | ||
fm2fb.c | ||
fsl-diu-fb.c | ||
g364fb.c | ||
gbefb.c | ||
grvga.c | ||
gxt4500.c | ||
hecubafb.c | ||
hgafb.c | ||
hitfb.c | ||
hpfb.c | ||
igafb.c | ||
imsttfb.c | ||
imxfb.c | ||
jz4740_fb.c | ||
Kconfig | ||
leo.c | ||
macfb.c | ||
macmodes.c | ||
macmodes.h | ||
Makefile | ||
maxinefb.c | ||
metronomefb.c | ||
modedb.c | ||
mx3fb.c | ||
mxsfb.c | ||
n411.c | ||
neofb.c | ||
nuc900fb.c | ||
nuc900fb.h | ||
offb.c | ||
output.c | ||
p9100.c | ||
platinumfb.c | ||
platinumfb.h | ||
pm2fb.c | ||
pm3fb.c | ||
pmag-aa-fb.c | ||
pmag-ba-fb.c | ||
pmagb-b-fb.c | ||
ps3fb.c | ||
pvr2fb.c | ||
pxa3xx-gcu.c | ||
pxa3xx-gcu.h | ||
pxa168fb.c | ||
pxa168fb.h | ||
pxafb.c | ||
pxafb.h | ||
q40fb.c | ||
s1d13xxxfb.c | ||
s3c2410fb.c | ||
s3c2410fb.h | ||
s3c-fb.c | ||
s3fb.c | ||
sa1100fb.c | ||
sa1100fb.h | ||
sbuslib.c | ||
sbuslib.h | ||
sgivwfb.c | ||
sh7760fb.c | ||
sh_mipi_dsi.c | ||
sh_mobile_hdmi.c | ||
sh_mobile_lcdcfb.c | ||
sh_mobile_lcdcfb.h | ||
sh_mobile_meram.c | ||
skeletonfb.c | ||
sm501fb.c | ||
sstfb.c | ||
sticore.h | ||
stifb.c | ||
sunxvr500.c | ||
sunxvr1000.c | ||
sunxvr2500.c | ||
svgalib.c | ||
syscopyarea.c | ||
sysfillrect.c | ||
sysimgblt.c | ||
tcx.c | ||
tdfxfb.c | ||
tgafb.c | ||
tmiofb.c | ||
tridentfb.c | ||
udlfb.c | ||
uvesafb.c | ||
valkyriefb.c | ||
valkyriefb.h | ||
vesafb.c | ||
vfb.c | ||
vga16fb.c | ||
vgastate.c | ||
vt8500lcdfb.c | ||
vt8500lcdfb.h | ||
vt8623fb.c | ||
w100fb.c | ||
w100fb.h | ||
wm8505fb_regs.h | ||
wm8505fb.c | ||
wmt_ge_rops.c | ||
wmt_ge_rops.h | ||
xen-fbfront.c | ||
xilinxfb.c |