1. 05 Sep, 2011 8 commits
  2. 02 Sep, 2011 4 commits
    • Bruno Prémont's avatar
      fb: sh-mobile: Fix deadlock risk between lock_fb_info() and console_lock() · 4a47a0e0
      Bruno Prémont authored
      Following on Herton's patch "fb: avoid possible deadlock caused by
      fb_set_suspend" which moves lock_fb_info() out of fb_set_suspend()
      to its callers, correct sh-mobile's locking around call to
      fb_set_suspend() and the same sort of deaklocks with console_lock()
      due to order of taking the lock.
      
      console_lock() must be taken while fb_info is already locked and fb_info
      must be locked while calling fb_set_suspend().
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@kernel.org
      4a47a0e0
    • Herton Ronaldo Krzesinski's avatar
      fb: avoid possible deadlock caused by fb_set_suspend · 9e769ff3
      Herton Ronaldo Krzesinski authored
      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=26232Signed-off-by: default avatarHerton Ronaldo Krzesinski <herton@mandriva.com.br>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@kernel.org
      9e769ff3
    • Manuel Lauss's avatar
      fbdev: au1200fb: silence debug output · f49446eb
      Manuel Lauss authored
      it's annoying and takes up way too much space in dmesg.
      Signed-off-by: default avatarManuel Lauss <manuel.lauss@googlemail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      f49446eb
    • Anatolij Gustschin's avatar
      video: mb862xx-i2c: fix for reliable decoder register access · 363d58f5
      Anatolij Gustschin authored
      Increase delay when polling for tx status. This fixes
      the unreliable video decoder i2c register access.
      Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      363d58f5
  3. 01 Sep, 2011 3 commits
    • Tomi Valkeinen's avatar
      fbdev: fix parsing of standard timings · 43dcd13b
      Tomi Valkeinen authored
      The standard timings parses uses 1:1 dimensions when the ratio in the
      EDID data is 0. However, for EDID 1.3 and later the dimensions are 16:10
      when the ratio is 0.
      
      Pass the version and revision numbers to get_std_timing() which can then
      make the right decision about dimensions.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      43dcd13b
    • Axel Lin's avatar
      video: nuc900fb: remove include of mach/clkdev.h · f88a91cc
      Axel Lin authored
      Since commit aa3831cf
      "ARM: Consolidate the clkdev header files",
      the header file arch/arm/mach-nuc93x/include/mach/clkdev.h is removed.
      
      This patch fixes below build error:
      
      drivers/video/nuc900fb.c:42:25: error: mach/clkdev.h: No such file or directory
      make[2]: *** [drivers/video/nuc900fb.o] Error 1
      make[1]: *** [drivers/video] Error 2
      make: *** [drivers] Error 2
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      f88a91cc
    • Axel Lin's avatar
      video: mxsfb: add missing include of linux/module.h · 36893674
      Axel Lin authored
      Include linux/module.h to fix below build error:
      
                       from drivers/video/mxsfb.c:42:
      arch/arm/mach-mxs/include/mach/memory.h:22:1: warning: this is the location of the previous definition
      drivers/video/mxsfb.c:574: error: 'THIS_MODULE' undeclared here (not in a function)
      drivers/video/mxsfb.c:893: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:893: warning: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
      drivers/video/mxsfb.c:893: warning: parameter names (without types) in function declaration
      drivers/video/mxsfb.c:917: error: expected declaration specifiers or '...' before string constant
      drivers/video/mxsfb.c:917: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:917: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
      drivers/video/mxsfb.c:917: warning: function declaration isn't a prototype
      drivers/video/mxsfb.c:918: error: expected declaration specifiers or '...' before string constant
      drivers/video/mxsfb.c:918: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:918: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
      drivers/video/mxsfb.c:918: warning: function declaration isn't a prototype
      drivers/video/mxsfb.c:919: error: expected declaration specifiers or '...' before string constant
      drivers/video/mxsfb.c:919: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:919: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
      drivers/video/mxsfb.c:919: warning: function declaration isn't a prototype
      make[2]: *** [drivers/video/mxsfb.o] Error 1
      make[1]: *** [drivers/video] Error 2
      make: *** [drivers] Error 2
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      36893674
  4. 30 Aug, 2011 1 commit
  5. 29 Aug, 2011 1 commit
  6. 24 Aug, 2011 8 commits
  7. 22 Aug, 2011 6 commits
  8. 21 Aug, 2011 4 commits
  9. 20 Aug, 2011 4 commits
  10. 19 Aug, 2011 1 commit
    • Jiaying Zhang's avatar
      ext4: flush any pending end_io requests before DIO reads w/dioread_nolock · dccaf33f
      Jiaying Zhang authored
      There is a race between ext4 buffer write and direct_IO read with
      dioread_nolock mount option enabled. The problem is that we clear
      PageWriteback flag during end_io time but will do
      uninitialized-to-initialized extent conversion later with dioread_nolock.
      If an O_direct read request comes in during this period, ext4 will return
      zero instead of the recently written data.
      
      This patch checks whether there are any pending uninitialized-to-initialized
      extent conversion requests before doing O_direct read to close the race.
      Note that this is just a bandaid fix. The fundamental issue is that we
      clear PageWriteback flag before we really complete an IO, which is
      problem-prone. To fix the fundamental issue, we may need to implement an
      extent tree cache that we can use to look up pending to-be-converted extents.
      Signed-off-by: default avatarJiaying Zhang <jiayingz@google.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      dccaf33f