1. 09 8月, 2016 29 次提交
  2. 08 8月, 2016 9 次提交
    • D
      drm: Paper over locking inversion after registration rework · 5c6c201c
      Daniel Vetter 提交于
      drm_connector_register_all requires a few too many locks because our
      connector_list locking is busted. Add another FIXME+hack to work
      around this. This should address the below lockdep splat:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      4.7.0-rc5+ #524 Tainted: G           O
      -------------------------------------------------------
      kworker/u8:0/6 is trying to acquire lock:
       (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
      
      but task is already holding lock:
       ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 ((fb_notifier_list).rwsem){++++.+}:
             [<ffffffff810df611>] lock_acquire+0xb1/0x200
             [<ffffffff819a55b4>] down_write+0x44/0x80
             [<ffffffff810abf91>] blocking_notifier_chain_register+0x21/0xb0
             [<ffffffff814c7448>] fb_register_client+0x18/0x20
             [<ffffffff814c6c86>] backlight_device_register+0x136/0x260
             [<ffffffffa0127eb2>] intel_backlight_device_register+0xa2/0x160 [i915]
             [<ffffffffa00f46be>] intel_connector_register+0xe/0x10 [i915]
             [<ffffffffa0112bfb>] intel_dp_connector_register+0x1b/0x80 [i915]
             [<ffffffff8159dfea>] drm_connector_register+0x4a/0x80
             [<ffffffff8159fe44>] drm_connector_register_all+0x64/0xf0
             [<ffffffff815a2a64>] drm_modeset_register_all+0x174/0x1c0
             [<ffffffff81599b72>] drm_dev_register+0xc2/0xd0
             [<ffffffffa00621d7>] i915_driver_load+0x1547/0x2200 [i915]
             [<ffffffffa006d80f>] i915_pci_probe+0x4f/0x70 [i915]
             [<ffffffff814a2135>] local_pci_probe+0x45/0xa0
             [<ffffffff814a349b>] pci_device_probe+0xdb/0x130
             [<ffffffff815c07e3>] driver_probe_device+0x223/0x440
             [<ffffffff815c0ad5>] __driver_attach+0xd5/0x100
             [<ffffffff815be386>] bus_for_each_dev+0x66/0xa0
             [<ffffffff815c002e>] driver_attach+0x1e/0x20
             [<ffffffff815bf9be>] bus_add_driver+0x1ee/0x280
             [<ffffffff815c1810>] driver_register+0x60/0xe0
             [<ffffffff814a1a10>] __pci_register_driver+0x60/0x70
             [<ffffffffa01a905b>] i915_init+0x5b/0x62 [i915]
             [<ffffffff8100042d>] do_one_initcall+0x3d/0x150
             [<ffffffff811a935b>] do_init_module+0x5f/0x1d9
             [<ffffffff81124416>] load_module+0x20e6/0x27e0
             [<ffffffff81124d63>] SYSC_finit_module+0xc3/0xf0
             [<ffffffff81124dae>] SyS_finit_module+0xe/0x10
             [<ffffffff819a83a9>] entry_SYSCALL_64_fastpath+0x1c/0xac
      
      -> #0 (&dev->mode_config.mutex){+.+.+.}:
             [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
             [<ffffffff810df611>] lock_acquire+0xb1/0x200
             [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
             [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
             [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
             [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
             [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
             [<ffffffff814c13c6>] fbcon_init+0x586/0x610
             [<ffffffff8154d16a>] visual_init+0xca/0x130
             [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
             [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
             [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
             [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
             [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
             [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
             [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
             [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
             [<ffffffff814c86b1>] register_framebuffer+0x251/0x330
             [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
             [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
             [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
             [<ffffffff810a3947>] process_one_work+0x1e7/0x750
             [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
             [<ffffffff810aad4f>] kthread+0xef/0x110
             [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((fb_notifier_list).rwsem);
                                     lock(&dev->mode_config.mutex);
                                     lock((fb_notifier_list).rwsem);
        lock(&dev->mode_config.mutex);
      
       *** DEADLOCK ***
      
      6 locks held by kworker/u8:0/6:
       #0:  ("events_unbound"){.+.+.+}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
       #1:  ((&entry->work)){+.+.+.}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
       #2:  (registration_lock){+.+.+.}, at: [<ffffffff814c8487>] register_framebuffer+0x27/0x330
       #3:  (console_lock){+.+.+.}, at: [<ffffffff814c86ce>] register_framebuffer+0x26e/0x330
       #4:  (&fb_info->lock){+.+.+.}, at: [<ffffffff814c78dd>] lock_fb_info+0x1d/0x40
       #5:  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70
      
      stack backtrace:
      CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G           O    4.7.0-rc5+ #524
      Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016
      Workqueue: events_unbound async_run_entry_fn
       0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900
       ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880
       ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0
      Call Trace:
       [<ffffffff814507a5>] dump_stack+0x67/0x92
       [<ffffffff810dc6fa>] print_circular_bug+0x1aa/0x200
       [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
       [<ffffffff810df611>] lock_acquire+0xb1/0x200
       [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
       [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
       [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
       [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
       [<ffffffff810fa85f>] ? rcu_read_lock_sched_held+0x7f/0x90
       [<ffffffff81208218>] ? kmem_cache_alloc_trace+0x248/0x2b0
       [<ffffffff815afdc5>] ? drm_modeset_lock_all+0x25/0x120
       [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
       [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
       [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
       [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
       [<ffffffff814c13c6>] fbcon_init+0x586/0x610
       [<ffffffff8154d16a>] visual_init+0xca/0x130
       [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
       [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
       [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
       [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
       [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
       [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
       [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
       [<ffffffff814c86b1>] register_framebuffer+0x251/0x330
       [<ffffffff815b7e8d>] ? vga_switcheroo_client_fb_set+0x5d/0x70
       [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
       [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
       [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
       [<ffffffff810a3947>] process_one_work+0x1e7/0x750
       [<ffffffff810a38c9>] ? process_one_work+0x169/0x750
       [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
       [<ffffffff810a3eb0>] ? process_one_work+0x750/0x750
       [<ffffffff810aad4f>] kthread+0xef/0x110
       [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
       [<ffffffff810aac60>] ? kthread_stop+0x2e0/0x2e0
      
      v2: Rebase onto the right branch (hand-editing patches ftw) and add more
      reporters.
      Reported-by: NImre Deak <imre.deak@intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reported-by: NJiri Kosina <jikos@kernel.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5c6c201c
    • L
      drm: rcar-du: Link HDMI encoder with bridge · 29986cc8
      Laurent Pinchart 提交于
      The conversion of the rcar-du driver from the I2C slave encoder to the
      DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing
      the bridge from being handled automatically by the DRM core. Fix it.
      
      Fixes: 1d926114 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder")
      Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      29986cc8
    • L
      Linux 4.8-rc1 · 29b4817d
      Linus Torvalds 提交于
      29b4817d
    • L
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 857953d7
      Linus Torvalds 提交于
      Pull more block fixes from Jens Axboe:
       "As mentioned in the pull the other day, a few more fixes for this
        round, all related to the bio op changes in this series.
      
        Two fixes, and then a cleanup, renaming bio->bi_rw to bio->bi_opf.  I
        wanted to do that change right after or right before -rc1, so that
        risk of conflict was reduced.  I just rebased the series on top of
        current master, and no new ->bi_rw usage has snuck in"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: rename bio bi_rw to bi_opf
        target: iblock_execute_sync_cache() should use bio_set_op_attrs()
        mm: make __swap_writepage() use bio_set_op_attrs()
        block/mm: make bdev_ops->rw_page() take a bool for read/write
      857953d7
    • L
      Merge tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux · 635a4ba1
      Linus Torvalds 提交于
      Pull drm zpos property support from Dave Airlie:
       "This tree was waiting on some media stuff I hadn't had time to get a
        stable branchpoint off, so I just waited until it was all in your tree
        first.
      
        It's been around a bit on the list and shouldn't affect anything
        outside adding the generic API and moving some ARM drivers to using
        it"
      
      * tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux:
        drm: rcar: use generic code for managing zpos plane property
        drm/exynos: use generic code for managing zpos plane property
        drm: sti: use generic zpos for plane
        drm: add generic zpos property
      635a4ba1
    • J
      block: rename bio bi_rw to bi_opf · 1eff9d32
      Jens Axboe 提交于
      Since commit 63a4cc24, bio->bi_rw contains flags in the lower
      portion and the op code in the higher portions. This means that
      old code that relies on manually setting bi_rw is most likely
      going to be broken. Instead of letting that brokeness linger,
      rename the member, to force old and out-of-tree code to break
      at compile time instead of at runtime.
      
      No intended functional changes in this commit.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      1eff9d32
    • J
      target: iblock_execute_sync_cache() should use bio_set_op_attrs() · 31c64f78
      Jens Axboe 提交于
      The original commit missed this function, it needs to mark it a
      write flush.
      
      Cc: Mike Christie <mchristi@redhat.com>
      Fixes: e742fc32 ("target: use bio op accessors")
      Signed-off-by: NJens Axboe <axboe@fb.com>
      31c64f78
    • J
      mm: make __swap_writepage() use bio_set_op_attrs() · ba13e83e
      Jens Axboe 提交于
      Cleaner than manipulating bio->bi_rw flags directly.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      ba13e83e
    • J
      block/mm: make bdev_ops->rw_page() take a bool for read/write · c11f0c0b
      Jens Axboe 提交于
      Commit abf54548 changed it from an 'rw' flags type to the
      newer ops based interface, but now we're effectively leaking
      some bdev internals to the rest of the kernel. Since we only
      care about whether it's a read or a write at that level, just
      pass in a bool 'is_write' parameter instead.
      
      Then we can also move op_is_write() and friends back under
      CONFIG_BLOCK protection.
      Reviewed-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      c11f0c0b
  3. 07 8月, 2016 2 次提交
    • L
      Merge tag 'doc-4.8-fixes' of git://git.lwn.net/linux · 52ddb7e9
      Linus Torvalds 提交于
      Pull documentation fixes from Jonathan Corbet:
       "Three fixes for the docs build, including removing an annoying warning
        on 'make help' if sphinx isn't present"
      
      * tag 'doc-4.8-fixes' of git://git.lwn.net/linux:
        DocBook: use DOCBOOKS="" to ignore DocBooks instead of IGNORE_DOCBOOKS=1
        Documenation: update cgroup's document path
        Documentation/sphinx: do not warn about missing tools in 'make help'
      52ddb7e9
    • L
      Merge tag 'binfmt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/binfmt_misc · e9d488c3
      Linus Torvalds 提交于
      Pull binfmt_misc update from James Bottomley:
       "This update is to allow architecture emulation containers to function
        such that the emulation binary can be housed outside the container
        itself.  The container and fs parts both have acks from relevant
        experts.
      
        To use the new feature you have to add an F option to your binfmt_misc
        configuration"
      
      From the docs:
       "The usual behaviour of binfmt_misc is to spawn the binary lazily when
        the misc format file is invoked.  However, this doesn't work very well
        in the face of mount namespaces and changeroots, so the F mode opens
        the binary as soon as the emulation is installed and uses the opened
        image to spawn the emulator, meaning it is always available once
        installed, regardless of how the environment changes"
      
      * tag 'binfmt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/binfmt_misc:
        binfmt_misc: add F option description to documentation
        binfmt_misc: add persistent opened binary handler for containers
        fs: add filp_clone_open API
      e9d488c3