1. 18 May, 2016 1 commit
  2. 16 May, 2016 4 commits
  3. 13 May, 2016 2 commits
    • Konstantin Khlebnikov's avatar
      mm/balloon_compaction: fix deflation when compaction is disabled · 1f649733
      Konstantin Khlebnikov authored
      commit 4d88e6f7 upstream.
      
      If CONFIG_BALLOON_COMPACTION=n balloon_page_insert() does not link pages
      with balloon and doesn't set PagePrivate flag, as a result
      balloon_page_dequeue() cannot get any pages because it thinks that all
      of them are isolated.  Without balloon compaction nobody can isolate
      ballooned pages.  It's safe to remove this check.
      
      Fixes: d6d86c0a ("mm/balloon_compaction: redesign ballooned pages management").
      Signed-off-by: default avatarKonstantin Khlebnikov <k.khlebnikov@samsung.com>
      Reported-by: default avatarMatt Mullins <mmullins@mmlx.us>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Gavin Guo <gavin.guo@canonical.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1f649733
    • Konstantin Khlebnikov's avatar
      mm/balloon_compaction: redesign ballooned pages management · 33904d89
      Konstantin Khlebnikov authored
      commit d6d86c0a upstream.
      
      Sasha Levin reported KASAN splash inside isolate_migratepages_range().
      Problem is in the function __is_movable_balloon_page() which tests
      AS_BALLOON_MAP in page->mapping->flags.  This function has no protection
      against anonymous pages.  As result it tried to check address space flags
      inside struct anon_vma.
      
      Further investigation shows more problems in current implementation:
      
      * Special branch in __unmap_and_move() never works:
        balloon_page_movable() checks page flags and page_count.  In
        __unmap_and_move() page is locked, reference counter is elevated, thus
        balloon_page_movable() always fails.  As a result execution goes to the
        normal migration path.  virtballoon_migratepage() returns
        MIGRATEPAGE_BALLOON_SUCCESS instead of MIGRATEPAGE_SUCCESS,
        move_to_new_page() thinks this is an error code and assigns
        newpage->mapping to NULL.  Newly migrated page lose connectivity with
        balloon an all ability for further migration.
      
      * lru_lock erroneously required in isolate_migratepages_range() for
        isolation ballooned page.  This function releases lru_lock periodically,
        this makes migration mostly impossible for some pages.
      
      * balloon_page_dequeue have a tight race with balloon_page_isolate:
        balloon_page_isolate could be executed in parallel with dequeue between
        picking page from list and locking page_lock.  Race is rare because they
        use trylock_page() for locking.
      
      This patch fixes all of them.
      
      Instead of fake mapping with special flag this patch uses special state of
      page->_mapcount: PAGE_BALLOON_MAPCOUNT_VALUE = -256.  Buddy allocator uses
      PAGE_BUDDY_MAPCOUNT_VALUE = -128 for similar purpose.  Storing mark
      directly in struct page makes everything safer and easier.
      
      PagePrivate is used to mark pages present in page list (i.e.  not
      isolated, like PageLRU for normal pages).  It replaces special rules for
      reference counter and makes balloon migration similar to migration of
      normal pages.  This flag is protected by page_lock together with link to
      the balloon device.
      
      [js] backport to 3.12. MIGRATEPAGE_BALLOON_SUCCESS had to be removed
           from one more place. VM_BUG_ON_PAGE does not exist in 3.12 yet,
           use plain VM_BUG_ON.
      Signed-off-by: default avatarKonstantin Khlebnikov <k.khlebnikov@samsung.com>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Link: http://lkml.kernel.org/p/53E6CEAA.9020105@oracle.com
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Gavin Guo <gavin.guo@canonical.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      33904d89
  4. 11 May, 2016 20 commits
  5. 03 May, 2016 13 commits
    • John Stultz's avatar
      cpuset: Fix potential deadlock w/ set_mems_allowed · d9aa9f58
      John Stultz authored
      commit db751fe3 upstream.
      
      After adding lockdep support to seqlock/seqcount structures,
      I started seeing the following warning:
      
      [    1.070907] ======================================================
      [    1.072015] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      [    1.073181] 3.11.0+ #67 Not tainted
      [    1.073801] ------------------------------------------------------
      [    1.074882] kworker/u4:2/708 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      [    1.076088]  (&p->mems_allowed_seq){+.+...}, at: [<ffffffff81187d7f>] new_slab+0x5f/0x280
      [    1.077572]
      [    1.077572] and this task is already holding:
      [    1.078593]  (&(&q->__queue_lock)->rlock){..-...}, at: [<ffffffff81339f03>] blk_execute_rq_nowait+0x53/0xf0
      [    1.080042] which would create a new lock dependency:
      [    1.080042]  (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...}
      [    1.080042]
      [    1.080042] but this new dependency connects a SOFTIRQ-irq-safe lock:
      [    1.080042]  (&(&q->__queue_lock)->rlock){..-...}
      [    1.080042] ... which became SOFTIRQ-irq-safe at:
      [    1.080042]   [<ffffffff810ec179>] __lock_acquire+0x5b9/0x1db0
      [    1.080042]   [<ffffffff810edfe5>] lock_acquire+0x95/0x130
      [    1.080042]   [<ffffffff818968a1>] _raw_spin_lock+0x41/0x80
      [    1.080042]   [<ffffffff81560c9e>] scsi_device_unbusy+0x7e/0xd0
      [    1.080042]   [<ffffffff8155a612>] scsi_finish_command+0x32/0xf0
      [    1.080042]   [<ffffffff81560e91>] scsi_softirq_done+0xa1/0x130
      [    1.080042]   [<ffffffff8133b0f3>] blk_done_softirq+0x73/0x90
      [    1.080042]   [<ffffffff81095dc0>] __do_softirq+0x110/0x2f0
      [    1.080042]   [<ffffffff81095fcd>] run_ksoftirqd+0x2d/0x60
      [    1.080042]   [<ffffffff810bc506>] smpboot_thread_fn+0x156/0x1e0
      [    1.080042]   [<ffffffff810b3916>] kthread+0xd6/0xe0
      [    1.080042]   [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
      [    1.080042]
      [    1.080042] to a SOFTIRQ-irq-unsafe lock:
      [    1.080042]  (&p->mems_allowed_seq){+.+...}
      [    1.080042] ... which became SOFTIRQ-irq-unsafe at:
      [    1.080042] ...  [<ffffffff810ec1d3>] __lock_acquire+0x613/0x1db0
      [    1.080042]   [<ffffffff810edfe5>] lock_acquire+0x95/0x130
      [    1.080042]   [<ffffffff810b3df2>] kthreadd+0x82/0x180
      [    1.080042]   [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
      [    1.080042]
      [    1.080042] other info that might help us debug this:
      [    1.080042]
      [    1.080042]  Possible interrupt unsafe locking scenario:
      [    1.080042]
      [    1.080042]        CPU0                    CPU1
      [    1.080042]        ----                    ----
      [    1.080042]   lock(&p->mems_allowed_seq);
      [    1.080042]                                local_irq_disable();
      [    1.080042]                                lock(&(&q->__queue_lock)->rlock);
      [    1.080042]                                lock(&p->mems_allowed_seq);
      [    1.080042]   <Interrupt>
      [    1.080042]     lock(&(&q->__queue_lock)->rlock);
      [    1.080042]
      [    1.080042]  *** DEADLOCK ***
      
      The issue stems from the kthreadd() function calling set_mems_allowed
      with irqs enabled. While its possibly unlikely for the actual deadlock
      to trigger, a fix is fairly simple: disable irqs before taking the
      mems_allowed_seq lock.
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: default avatarLi Zefan <lizefan@huawei.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/1381186321-4906-4-git-send-email-john.stultz@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d9aa9f58
    • Ewan D. Milne's avatar
      scsi: Avoid crashing if device uses DIX but adapter does not support it · afa099d3
      Ewan D. Milne authored
      commit 91724c20 upstream.
      
      This can happen if a multipathed device uses DIX and another path is
      added via an adapter that does not support it.  Multipath should not
      allow this path to be added, but we should not depend upon that to avoid
      crashing.
      Signed-off-by: default avatarEwan D. Milne <emilne@redhat.com>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      afa099d3
    • Adrian Hunter's avatar
      mmc: sdhci: Allow for irq being shared · d9a22915
      Adrian Hunter authored
      commit 655bca76 upstream.
      
      If the SDHCI irq is shared with another device then the interrupt
      handler can get called while SDHCI is runtime suspended.  That is
      harmless but the warning message is not useful so remove it.  Also
      returning IRQ_NONE is more appropriate.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d9a22915
    • Jiri Slaby's avatar
      Revert "xfs: add capability check to free eofblocks ioctl" · 928efcfe
      Jiri Slaby authored
      This reverts commit eaeeaec3, upstream
      commit 8c567a7f.
      
      It was (mis)applied twice to stable-3.12.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Brian Foster <bfoster@redhat.com>
      Cc: Dave Chinner <dchinner@redhat.com>
      Cc: Gao feng <gaofeng@cn.fujitsu.com>
      Cc: Dwight Engen <dwight.engen@oracle.com>
      Cc: Ben Myers <bpm@sgi.com>
      928efcfe
    • NeilBrown's avatar
      sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race · 6fa6f0c4
      NeilBrown authored
      commit a6ab1e81 upstream.
      
      sunrpc_cache_pipe_upcall() can detect a race if CACHE_PENDING is no longer
      set.  In this case it aborts the queuing of the upcall.
      However it has already taken a new counted reference on "h" and
      doesn't "put" it, even though it frees the data structure holding the reference.
      
      So let's delay the "cache_get" until we know we need it.
      
      Fixes: f9e1aedc ("sunrpc/cache: remove races with queuing an upcall.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6fa6f0c4
    • Fabio Estevam's avatar
      bus: imx-weim: Take the 'status' property value into account · b4a6367c
      Fabio Estevam authored
      commit 33b96d2c upstream.
      
      Currently we have an incorrect behaviour when multiple devices
      are present under the weim node. For example:
      
      &weim {
      	...
      	status = "okay";
      
      	sram@0,0 {
      		...
              	status = "okay";
      	};
      
      	mram@0,0 {
      		...
              	status = "disabled";
          	};
      };
      
      In this case only the 'sram' device should be probed and not 'mram'.
      
      However what happens currently is that the status variable is ignored,
      causing the 'sram' device to be disabled and 'mram' to be enabled.
      
      Change the weim_parse_dt() function to use
      for_each_available_child_of_node()so that the devices marked with
      'status = disabled' are not probed.
      Suggested-by: default avatarWolfgang Netbal <wolfgang.netbal@sigmatek.at>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Reviewed-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b4a6367c
    • Pali Rohár's avatar
      ARM: OMAP3: Add cpuidle parameters table for omap3430 · fecd577e
      Pali Rohár authored
      commit 98f42221 upstream.
      
      Based on CPU type choose generic omap3 or omap3430 specific cpuidle
      parameters. Parameters for omap3430 were measured on Nokia N900 device and
      added by commit 5a1b1d3a ("OMAP3: RX-51: Pass cpu idle parameters")
      which were later removed by commit 231900af ("ARM: OMAP3: cpuidle -
      remove rx51 cpuidle parameters table") due to huge code complexity.
      
      This patch brings cpuidle parameters for omap3430 devices again, but uses
      simple condition based on CPU type.
      
      Fixes: 231900af ("ARM: OMAP3: cpuidle - remove rx51 cpuidle
      parameters table")
      Signed-off-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      fecd577e
    • Borislav Petkov's avatar
      perf stat: Document --detailed option · 891923b0
      Borislav Petkov authored
      commit f594bae0 upstream.
      
      I'm surprised this remained undocumented since at least 2011. And it is
      actually a very useful switch, as Steve and I came to realize recently.
      
      Add the text from
      
        2cba3ffb ("perf stat: Add -d -d and -d -d -d options to show more CPU events")
      
      which added the incrementing aspect to -d.
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Davidlohr Bueso <dbueso@suse.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mel Gorman <mgorman@suse.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 2cba3ffb ("perf stat: Add -d -d and -d -d -d options to show more CPU events")
      Link: http://lkml.kernel.org/r/1457347294-32546-1-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      891923b0
    • Vitaly Kuznetsov's avatar
      Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors · 76be64a9
      Vitaly Kuznetsov authored
      commit e513229b upstream.
      
      When an SMP Hyper-V guest is running on top of 2012R2 Server and secondary
      cpus are sent offline (with echo 0 > /sys/devices/system/cpu/cpu$cpu/online)
      the system freeze is observed. This happens due to the fact that on newer
      hypervisors (Win8, WS2012R2, ...) vmbus channel handlers are distributed
      across all cpus (see init_vp_index() function in drivers/hv/channel_mgmt.c)
      and on cpu offlining nobody reassigns them to CPU0. Prevent cpu offlining
      when vmbus is loaded until the issue is fixed host-side.
      
      This patch also disables hibernation but it is OK as it is also broken (MCE
      error is hit on resume). Suspend still works.
      
      Tested with WS2008R2 and WS2012R2.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      [ 3chas3@gmail.com: rebase to 3.14-stable ]
      Signed-off-by: default avatarChas Williams <3chas3@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      76be64a9
    • Vasily Kulikov's avatar
      include/linux/poison.h: fix LIST_POISON{1,2} offset · c7ecfa39
      Vasily Kulikov authored
      commit 8a5e5e02 upstream.
      
      Poison pointer values should be small enough to find a room in
      non-mmap'able/hardly-mmap'able space.  E.g.  on x86 "poison pointer space"
      is located starting from 0x0.  Given unprivileged users cannot mmap
      anything below mmap_min_addr, it should be safe to use poison pointers
      lower than mmap_min_addr.
      
      The current poison pointer values of LIST_POISON{1,2} might be too big for
      mmap_min_addr values equal or less than 1 MB (common case, e.g.  Ubuntu
      uses only 0x10000).  There is little point to use such a big value given
      the "poison pointer space" below 1 MB is not yet exhausted.  Changing it
      to a smaller value solves the problem for small mmap_min_addr setups.
      
      The values are suggested by Solar Designer:
      http://www.openwall.com/lists/oss-security/2015/05/02/6Signed-off-by: default avatarVasily Kulikov <segoon@openwall.com>
      Cc: Solar Designer <solar@openwall.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c7ecfa39
    • Geert Uytterhoeven's avatar
      serial: sh-sci: Remove cpufreq notifier to fix crash/deadlock · 07c681f2
      Geert Uytterhoeven authored
      commit ff1cab37 upstream.
      
      The BSP team noticed that there is spin/mutex lock issue on sh-sci when
      CPUFREQ is used.  The issue is that the notifier function may call
      mutex_lock() while the spinlock is held, which can lead to a BUG().
      This may happen if CPUFREQ is changed while another CPU calls
      clk_get_rate().
      
      Taking the spinlock was added to the notifier function in commit
      e552de24 ("sh-sci: add platform device private data"), to
      protect the list of serial ports against modification during traversal.
      At that time the Common Clock Framework didn't exist yet, and
      clk_get_rate() just returned clk->rate without taking a mutex.
      Note that since commit d535a230 ("serial: sh-sci: Require a
      device per port mapping."), there's no longer a list of serial ports to
      traverse, and taking the spinlock became superfluous.
      
      To fix the issue, just remove the cpufreq notifier:
        1. The notifier doesn't work correctly: all it does is update stored
           clock rates; it does not update the divider in the hardware.
           The divider will only be updated when calling sci_set_termios().
           I believe this was broken back in 2004, when the old
           drivers/char/sh-sci.c driver (where the notifier did update the
           divider) was replaced by drivers/serial/sh-sci.c (where the
           notifier just updated port->uartclk).
           Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port
           sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH]
           Remove old sh-sci driver").
        2. On modern SoCs, the sh-sci parent clock rate is no longer related
           to the CPU clock rate anyway, so using a cpufreq notifier is
           futile.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      
      
      07c681f2
    • Michael Hennerich's avatar
      drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors · 0aec7cb0
      Michael Hennerich authored
      commit f3df53e4 upstream.
      
      Fix RDAC read back errors caused by a typo. Value must shift by 2.
      
      Fixes: a4bd3949 ("drivers/misc/ad525x_dpot.c: new features")
      Signed-off-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      0aec7cb0
    • Geert Uytterhoeven's avatar
      rtc: vr41xx: Wire up alarm_irq_enable · 2e369706
      Geert Uytterhoeven authored
      commit a25f4a95 upstream.
      
      drivers/rtc/rtc-vr41xx.c:229: warning: ‘vr41xx_rtc_alarm_irq_enable’ defined but not used
      
      Apparently the conversion to alarm_irq_enable forgot to wire up the
      callback.
      
      Fixes: 16380c15 ("RTC: Convert rtc drivers to use the alarm_irq_enable method")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2e369706