1. 13 2月, 2019 30 次提交
  2. 07 2月, 2019 10 次提交
    • G
      Linux 4.19.20 · 323e0195
      Greg Kroah-Hartman 提交于
      323e0195
    • P
      cifs: Always resolve hostname before reconnecting · c0be6247
      Paulo Alcantara 提交于
      commit 28eb24ff75c5ac130eb326b3b4d0dcecfc0f427d upstream.
      
      In case a hostname resolves to a different IP address (e.g. long
      running mounts), make sure to resolve it every time prior to calling
      generic_ip_connect() in reconnect.
      Suggested-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NPaulo Alcantara <palcantara@suse.de>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0be6247
    • A
      md/raid5: fix 'out of memory' during raid cache recovery · e7f11c55
      Alexei Naberezhnov 提交于
      commit 483cbbeddd5fe2c80fd4141ff0748fa06c4ff146 upstream.
      
      This fixes the case when md array assembly fails because of raid cache recovery
      unable to allocate a stripe, despite attempts to replay stripes and increase
      cache size. This happens because stripes released by r5c_recovery_replay_stripes
      and raid5_set_cache_size don't become available for allocation immediately.
      Released stripes first are placed on conf->released_stripes list and require
      md thread to merge them on conf->inactive_list before they can be allocated.
      
      Patch allows final allocation attempt during cache recovery to wait for
      new stripes to become availabe for allocation.
      
      Cc: linux-raid@vger.kernel.org
      Cc: Shaohua Li <shli@kernel.org>
      Cc: linux-stable <stable@vger.kernel.org> # 4.10+
      Fixes: b4c625c6 ("md/r5cache: r5cache recovery: part 1")
      Signed-off-by: NAlexei Naberezhnov <anaberezhnov@fb.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e7f11c55
    • F
      of: overlay: do not duplicate properties from overlay for new nodes · 5b3109eb
      Frank Rowand 提交于
      commit 8814dc46bd9e347d4de55ec5bf8f16ea54470499 upstream.
      
      When allocating a new node, add_changeset_node() was duplicating the
      properties from the respective node in the overlay instead of
      allocating a node with no properties.
      
      When this patch is applied the errors reported by the devictree
      unittest from patch "of: overlay: add tests to validate kfrees from
      overlay removal" will no longer occur.  These error messages are of
      the form:
      
         "OF: ERROR: ..."
      
      and the unittest results will change from:
      
         ### dt-test ### end of unittest - 203 passed, 7 failed
      
      to
      
         ### dt-test ### end of unittest - 210 passed, 0 failed
      Tested-by: NAlan Tull <atull@kernel.org>
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b3109eb
    • F
      of: overlay: use prop add changeset entry for property in new nodes · 7251e4b8
      Frank Rowand 提交于
      commit 6b4955ba7bc05e40c8c41071cc121bc26ca65277 upstream.
      
      The changeset entry 'update property' was used for new properties in
      an overlay instead of 'add property'.
      
      The decision of whether to use 'update property' was based on whether
      the property already exists in the subtree where the node is being
      spliced into.  At the top level of creating a changeset describing the
      overlay, the target node is in the live devicetree, so checking whether
      the property exists in the target node returns the correct result.
      As soon as the changeset creation algorithm recurses into a new node,
      the target is no longer in the live devicetree, but is instead in the
      detached overlay tree, thus all properties are incorrectly found to
      already exist in the target.
      
      This fix will expose another devicetree bug that will be fixed
      in the following patch in the series.
      
      When this patch is applied the errors reported by the devictree
      unittest will change, and the unittest results will change from:
      
         ### dt-test ### end of unittest - 210 passed, 0 failed
      
      to
      
         ### dt-test ### end of unittest - 203 passed, 7 failed
      Tested-by: NAlan Tull <atull@kernel.org>
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7251e4b8
    • F
      of: overlay: add missing of_node_get() in __of_attach_node_sysfs · 9af27fab
      Frank Rowand 提交于
      commit 5b2c2f5a0ea3a43e0dee78059e34c7cb54136dcc upstream.
      
      There is a matching of_node_put() in __of_detach_node_sysfs()
      
      Remove misleading comment from function header comment for
      of_detach_node().
      
      This patch may result in memory leaks from code that directly calls
      the dynamic node add and delete functions directly instead of
      using changesets.
      
      This commit should result in powerpc systems that dynamically
      allocate a node, then later deallocate the node to have a
      memory leak when the node is deallocated.
      
      The next commit will fix the leak.
      Tested-by: NAlan Tull <atull@kernel.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9af27fab
    • F
      of: overlay: add tests to validate kfrees from overlay removal · 5006496f
      Frank Rowand 提交于
      commit 144552c786925314c1e7cb8f91a71dae1aca8798 upstream.
      
      Add checks:
        - attempted kfree due to refcount reaching zero before overlay
          is removed
        - properties linked to an overlay node when the node is removed
        - node refcount > one during node removal in a changeset destroy,
          if the node was created by the changeset
      
      After applying this patch, several validation warnings will be
      reported from the devicetree unittest during boot due to
      pre-existing devicetree bugs. The warnings will be similar to:
      
        OF: ERROR: of_node_release(), unexpected properties in /testcase-data/overlay-node/test-bus/test-unittest11
        OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /testcase-data-2/substation@100/
        hvac-medium-2
      Tested-by: NAlan Tull <atull@kernel.org>
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5006496f
    • R
      of: Convert to using %pOFn instead of device_node.name · 3edc2fac
      Rob Herring 提交于
      commit a613b26a50136ae90ab13943afe90bcbd34adb44 upstream.
      
      In preparation to remove the node name pointer from struct device_node,
      convert printf users to use the %pOFn format specifier.
      Reviewed-by: NFrank Rowand <frank.rowand@sony.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3edc2fac
    • D
      mm: migrate: don't rely on __PageMovable() of newpage after unlocking it · 214dea14
      David Hildenbrand 提交于
      commit e0a352fabce61f730341d119fbedf71ffdb8663f upstream.
      
      We had a race in the old balloon compaction code before b1123ea6
      ("mm: balloon: use general non-lru movable page feature") refactored it
      that became visible after backporting 195a8c43 ("virtio-balloon:
      deflate via a page list") without the refactoring.
      
      The bug existed from commit d6d86c0a ("mm/balloon_compaction:
      redesign ballooned pages management") till b1123ea6 ("mm: balloon:
      use general non-lru movable page feature").  d6d86c0a
      ("mm/balloon_compaction: redesign ballooned pages management") was
      backported to 3.12, so the broken kernels are stable kernels [3.12 -
      4.7].
      
      There was a subtle race between dropping the page lock of the newpage in
      __unmap_and_move() and checking for __is_movable_balloon_page(newpage).
      
      Just after dropping this page lock, virtio-balloon could go ahead and
      deflate the newpage, effectively dequeueing it and clearing PageBalloon,
      in turn making __is_movable_balloon_page(newpage) fail.
      
      This resulted in dropping the reference of the newpage via
      putback_lru_page(newpage) instead of put_page(newpage), leading to
      page->lru getting modified and a !LRU page ending up in the LRU lists.
      With 195a8c43 ("virtio-balloon: deflate via a page list")
      backported, one would suddenly get corrupted lists in
      release_pages_balloon():
      
      - WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0
      - list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100
      
      Nowadays this race is no longer possible, but it is hidden behind very
      ugly handling of __ClearPageMovable() and __PageMovable().
      
      __ClearPageMovable() will not make __PageMovable() fail, only
      PageMovable().  So the new check (__PageMovable(newpage)) will still
      hold even after newpage was dequeued by virtio-balloon.
      
      If anybody would ever change that special handling, the BUG would be
      introduced again.  So instead, make it explicit and use the information
      of the original isolated page before migration.
      
      This patch can be backported fairly easy to stable kernels (in contrast
      to the refactoring).
      
      Link: http://lkml.kernel.org/r/20190129233217.10747-1-david@redhat.com
      Fixes: d6d86c0a ("mm/balloon_compaction: redesign ballooned pages management")
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Reported-by: NVratislav Bendel <vbendel@redhat.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NRafael Aquini <aquini@redhat.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Vratislav Bendel <vbendel@redhat.com>
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: <stable@vger.kernel.org>	[3.12 - 4.7]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      214dea14
    • N
      mm: hwpoison: use do_send_sig_info() instead of force_sig() · ced41d9d
      Naoya Horiguchi 提交于
      commit 6376360ecbe525a9c17b3d081dfd88ba3e4ed65b upstream.
      
      Currently memory_failure() is racy against process's exiting, which
      results in kernel crash by null pointer dereference.
      
      The root cause is that memory_failure() uses force_sig() to forcibly
      kill asynchronous (meaning not in the current context) processes.  As
      discussed in thread https://lkml.org/lkml/2010/6/8/236 years ago for OOM
      fixes, this is not a right thing to do.  OOM solves this issue by using
      do_send_sig_info() as done in commit d2d39309 ("signal:
      oom_kill_task: use SEND_SIG_FORCED instead of force_sig()"), so this
      patch is suggesting to do the same for hwpoison.  do_send_sig_info()
      properly accesses to siglock with lock_task_sighand(), so is free from
      the reported race.
      
      I confirmed that the reported bug reproduces with inserting some delay
      in kill_procs(), and it never reproduces with this patch.
      
      Note that memory_failure() can send another type of signal using
      force_sig_mceerr(), and the reported race shouldn't happen on it because
      force_sig_mceerr() is called only for synchronous processes (i.e.
      BUS_MCEERR_AR happens only when some process accesses to the corrupted
      memory.)
      
      Link: http://lkml.kernel.org/r/20190116093046.GA29835@hori1.linux.bs1.fc.nec.co.jpSigned-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Reported-by: NJane Chu <jane.chu@oracle.com>
      Reviewed-by: NDan Williams <dan.j.williams@intel.com>
      Reviewed-by: NWilliam Kucharski <william.kucharski@oracle.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ced41d9d