1. 06 Jul, 2016 3 commits
    • Anilkumar Kolli's avatar
      ath10k: fix debugfs pktlog_filter write · 5231c3df
      Anilkumar Kolli authored
      commit 9ddc486a upstream.
      
      It is observed that, we are disabling the packet log if we write same
      value to the pktlog_filter for the second time. Always enable pktlogs
      on non zero filter.
      
      Fixes: 90174455 ("ath10k: add support to configure pktlog filter")
      Signed-off-by: default avatarAnilkumar Kolli <akolli@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      5231c3df
    • Lyude's avatar
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · 0d5bd657
      Lyude authored
      commit 1f771755 upstream.
      
      After unplugging a DP MST display from the system, we have to go through
      and destroy all of the DRM connectors associated with it since none of
      them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
      doesn't do a good enough job of ensuring that throughout the destruction
      process that no modesettings can be done with the connectors. As it is
      right now, intel_dp_destroy_mst_connector() works like this:
      
      * Take all modeset locks
      * Clear the configuration of the crtc on the connector, if there is one
      * Drop all modeset locks, this is required because of circular
        dependency issues that arise with trying to remove the connector from
        sysfs with modeset locks held
      * Unregister the connector
      * Take all modeset locks, again
      * Do the rest of the required cleaning for destroying the connector
      * Finally drop all modeset locks for good
      
      This only works sometimes. During the destruction process, it's very
      possible that a userspace application will attempt to do a modesetting
      using the connector. When we drop the modeset locks, an ioctl handler
      such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
      locks from us. When this happens, one thing leads to another and
      eventually we end up committing a mode with the non-existent connector:
      
      	[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
      	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
      	[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
      	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
      	[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
      
      And in some cases, such as with the T460s using an MST dock, this
      results in breaking modesetting and/or panicking the system.
      
      To work around this, we now unregister the connector at the very
      beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
      locks, and then hold them until we finish the rest of the function.
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarRob Clark <rclark@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
      [ kamal: backport to 4.2-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0d5bd657
    • Rajkumar Manoharan's avatar
      ath10k: fix firmware assert in monitor mode · cd6e21c1
      Rajkumar Manoharan authored
      commit 8a75fc54 upstream.
      
      commit 166de3f1 ("ath10k: remove supported chain mask") had revealed
      an issue on monitor mode. Configuring NSS upon monitor interface
      creation is causing target assert in all qca9888x and qca6174 firmware.
      Firmware assert issue can be reproduced by below sequence even after
      reverting commit 166de3f1 ("ath10k: remove supported chain mask").
      
      ip link set wlan0 down
      iw wlan0 set type monitor
      iw phy0 set antenna 7
      ip link set wlan0 up
      
      This issue is originally reported on qca9888 with 10.1 firmware.
      
      Fixes: 5572a95b ("ath10k: apply chainmask settings to vdev on creation")
      Reported-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      cd6e21c1
  2. 22 Jun, 2016 1 commit
    • Hugh Dickins's avatar
      mm: migrate dirty page without clear_page_dirty_for_io etc · f1032b34
      Hugh Dickins authored
      commit 42cb14b1 upstream.
      
      clear_page_dirty_for_io() has accumulated writeback and memcg subtleties
      since v2.6.16 first introduced page migration; and the set_page_dirty()
      which completed its migration of PageDirty, later had to be moderated to
      __set_page_dirty_nobuffers(); then PageSwapBacked had to skip that too.
      
      No actual problems seen with this procedure recently, but if you look into
      what the clear_page_dirty_for_io(page)+set_page_dirty(newpage) is actually
      achieving, it turns out to be nothing more than moving the PageDirty flag,
      and its NR_FILE_DIRTY stat from one zone to another.
      
      It would be good to avoid a pile of irrelevant decrementations and
      incrementations, and improper event counting, and unnecessary descent of
      the radix_tree under tree_lock (to set the PAGECACHE_TAG_DIRTY which
      radix_tree_replace_slot() left in place anyway).
      
      Do the NR_FILE_DIRTY movement, like the other stats movements, while
      interrupts still disabled in migrate_page_move_mapping(); and don't even
      bother if the zone is the same.  Do the PageDirty movement there under
      tree_lock too, where old page is frozen and newpage not yet visible:
      bearing in mind that as soon as newpage becomes visible in radix_tree, an
      un-page-locked set_page_dirty() might interfere (or perhaps that's just
      not possible: anything doing so should already hold an additional
      reference to the old page, preventing its migration; but play safe).
      
      But we do still need to transfer PageDirty in migrate_page_copy(), for
      those who don't go the mapping route through migrate_page_move_mapping().
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: adjust context.  This is not just an optimisation,
       but turned out to fix a possible oops (CVE-2016-3070).]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      f1032b34
  3. 31 May, 2016 1 commit
  4. 25 May, 2016 35 commits