Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 4月, 2015 9 次提交
  3. 19 3月, 2015 3 次提交
  5. 09 3月, 2015 3 次提交
  7. 04 3月, 2015 1 次提交
    • D
      drm/i915: Fix modeset state confusion in the load detect code · 9128b040
      由 Daniel Vetter 提交于 
      This is a tricky story of the new atomic state handling and the legacy
code fighting over each another. The bug at hand is an underrun of the
framebuffer reference with subsequent hilarity caused by the load
detect code. Which is peculiar since the the exact same code works
fine as the implementation of the legacy setcrtc ioctl.

Let's look at the ingredients:

- Currently our code is a crazy mix of legacy modeset interfaces to
  set the parameters and half-baked atomic state tracking underneath.
  While this transition is going we're using the transitional plane
  helpers to update the atomic side (drm_plane_helper_disable/update
  and friends), i.e. plane->state->fb. Since the state structure owns
  the fb those functions take care of that themselves.

  The legacy state (specifically crtc->primary->fb) is still managed
  by the old code (and mostly by the drm core), with the fb reference
  counting done by callers (core drm for the ioctl or the i915 load
  detect code). The relevant commit is

  commit ea2c67bb
  Author: Matt Roper <matthew.d.roper@intel.com>
  Date:   Tue Dec 23 10:41:52 2014 -0800

      drm/i915: Move to atomic plane helpers (v9)

- drm_plane_helper_disable has special code to handle multiple calls
  in a row - it checks plane->crtc == NULL and bails out. This is to
  match the proper atomic implementation which needs the crtc to get
  at the implied locking context atomic updates always need. See

  commit acf24a39
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Tue Jul 29 15:33:05 2014 +0200

      drm/plane-helper: transitional atomic plane helpers

- The universal plane code split out the implicit primary plane from
  the CRTC into it's own full-blown drm_plane object. As part of that
  the setcrtc ioctl (which updated both the crtc mode and primary
  plane) learned to set crtc->primary->crtc on modeset to make sure
  the plane->crtc assignments statate up to date in

  commit e13161af
  Author: Matt Roper <matthew.d.roper@intel.com>
  Date:   Tue Apr 1 15:22:38 2014 -0700

      drm: Add drm_crtc_init_with_planes() (v2)

  Unfortunately we've forgotten to update the load detect code. Which
  wasn't a problem since the load detect modeset is temporary and
  always undone before we drop the locks.

- Finally there is a organically grown history (i.e. don't ask) around
  who sets the legacy plane->fb for the various driver entry points.
  Originally updating that was the drivers duty, but for almost all
  places we've moved that (plus updating the refcounts) into the core.
  Again the exception is the load detect code.

Taking all together the following happens:
- The load detect code doesn't set crtc->primary->crtc. This is only
  really an issue on crtcs never before used or when userspace
  explicitly disabled the primary plane.

- The plane helper glue code short-circuits because of that and leaves
  a non-NULL fb behind in plane->state->fb and plane->fb. The state
  fb isn't a real problem (it's properly refcounted on its own), it's
  just the canary.

- Load detect code drops the reference for that fb, but doesn't set
  plane->fb = NULL. This is ok since it's still living in that old
  world where drivers had to clear the pointer but the core/callers
  handled the refcounting.

- On the next modeset the drm core notices plane->fb and takes care of
  refcounting it properly by doing another unref. This drops the
  refcount to zero, leaving state->plane now pointing at freed memory.

- intel_plane_duplicate_state still assume it owns a reference to that
  very state->fb and bad things start to happen.

Fix this all by applying the same duct-tape as for the legacy setcrtc
ioctl code and set crtc->primary->crtc properly.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9128b040
  9. 01 3月, 2015 4 次提交
  11. 28 2月, 2015 2 次提交
  13. 26 2月, 2015 11 次提交
  15. 25 2月, 2015 7 次提交
    • R
      clocksource: pxa: Fix section mismatch · 6f2116eb
      由 Robert Jarzmik 提交于 
      As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()

WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      6f2116eb
    • M
      clocksource: mtk: Fix race conditions in probe code · d4a19eb3
      由 Matthias Brugger 提交于 
      We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.

The interrupt handler accesses the clockevent device, which may not yet be
registered.

First race condition happens when the interrupt handler gets registered before
the interrupts get disabled. The second race condition happens when the
interrupts get enabled, but the clockevent device is not yet registered.

Fix that by disabling the interrupts before we register the interrupt and enable
the interrupts after the clockevent device got registered.
Reported-by: NGongbae Park <yongbae2@gmail.com>
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      d4a19eb3
    • D
      clockevents: asm9260: Fix compilation error with sparc/sparc64 allyesconfig · a8b1b9fc
      由 Daniel Lezcano 提交于 
      The Kconfig options for the asm9260 timer is wrong as it can be selected by
another platform with allyes config and thus leading to a compilation failure
as some non arch related code is pulled by the compilation.

Fix this by having the platform Kconfig to select the timer as it is done for
the others drivers.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NOleksij Rempel <linux@rempel-privat.de>

Conflicts:
	drivers/clocksource/Kconfig
      a8b1b9fc
    • R
      drm/i915: Fix frontbuffer false positve. · 62e537f8
      由 Rodrigo Vivi 提交于 
      This return 0 without setting atomic bits on fb == crtc->cursor->fb
where causing frontbuffer false positives.

According to Daniel:

The original regression seems to have been introduced in the original
check/commit split:

commit 757f9a3e
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Wed Sep 24 14:20:24 2014 -0300

    drm/i915: move check of intel_crtc_cursor_set_obj() out

Which already cause other trouble, resulting in the check getting moved in

commit e391ea88
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Wed Sep 24 14:20:25 2014 -0300

    drm/i915: Fix not checking cursor and object sizes

The frontbuffer tracking itself only was broken when we shifted it into
the check/commit logic with:

commit 32b7eeec
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Wed Dec 24 07:59:06 2014 -0800

    drm/i915: Refactor work that can sleep out of commit (v7)

v2: When putting more debug prints I notice the solution was simpler
than I thought. AMS design is solid, just this return was wrong.
Sorry for the noise.

v3: Remove the entire chunck that would probably
    be removed by gcc anyway. (by Daniel)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      62e537f8
    • N
      md: mark some attributes as pre-alloc · 750f199e
      由 NeilBrown 提交于 
      Since __ATTR_PREALLOC was introduced in v3.19-rc1~78^2~18
it can now be used by md.

This ensure that writing to these sysfs attributes will never
block due to a memory allocation.
Such blocking could become a deadlock if mdmon is trying to
reconfigure an array after a failure prior to re-enabling writes.
Signed-off-by: NNeilBrown <neilb@suse.de>
      750f199e
    • E
      raid5: check faulty flag for array status during recovery. · 16d9cfab
      由 Eric Mei 提交于 
      When we have more than 1 drive failure, it's possible we start
rebuild one drive while leaving another faulty drive in array.
To determine whether array will be optimal after building, current
code only check whether a drive is missing, which could potentially
lead to data corruption. This patch is to add checking Faulty flag.
Signed-off-by: NNeilBrown <neilb@suse.de>
      16d9cfab
    • T
      md/raid1: fix read balance when a drive is write-mostly. · d1901ef0
      由 Tomáš Hodek 提交于 
      When a drive is marked write-mostly it should only be the
target of reads if there is no other option.

This behaviour was broken by

commit 9dedf603
    md/raid1: read balance chooses idlest disk for SSD

which causes a write-mostly device to be *preferred* is some cases.

Restore correct behaviour by checking and setting
best_dist_disk and best_pending_disk rather than best_disk.

We only need to test one of these as they are both changed
from -1 or >=0 at the same time.

As we leave min_pending and best_dist unchanged, any non-write-mostly
device will appear better than the write-mostly device.
Reported-by: NTomáš Hodek <tomas.hodek@volny.cz>
Reported-by: NDark Penguin <darkpenguin@yandex.ru>
Signed-off-by: NNeilBrown <neilb@suse.de>
Link: http://marc.info/?l=linux-raid&m=135982797322422
Fixes: 9dedf603
Cc: stable@vger.kernel.org (3.6+)
      d1901ef0