]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 14 Jan 2015 07:19:37 +0000 (23:19 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 14 Jan 2015 07:19:37 +0000 (23:19 -0800)
added patches:
mm-don-t-count-the-stack-guard-page-towards-rlimit_stack.patch
mm-propagate-error-from-stack-expansion-even-for-guard-page.patch
mm-vmscan-prevent-kswapd-livelock-due-to-pfmemalloc-throttled-process-being-killed.patch
mmc-sdhci-fix-sleep-in-atomic-after-inserting-sd-card.patch
spi-fsl-fix-problem-with-multi-message-transfers.patch

queue-3.14/mm-don-t-count-the-stack-guard-page-towards-rlimit_stack.patch [new file with mode: 0644]
queue-3.14/mm-propagate-error-from-stack-expansion-even-for-guard-page.patch [new file with mode: 0644]
queue-3.14/mm-vmscan-prevent-kswapd-livelock-due-to-pfmemalloc-throttled-process-being-killed.patch [new file with mode: 0644]
queue-3.14/mmc-sdhci-fix-sleep-in-atomic-after-inserting-sd-card.patch [new file with mode: 0644]
queue-3.14/series
queue-3.14/spi-fsl-fix-problem-with-multi-message-transfers.patch [new file with mode: 0644]

diff --git a/queue-3.14/mm-don-t-count-the-stack-guard-page-towards-rlimit_stack.patch b/queue-3.14/mm-don-t-count-the-stack-guard-page-towards-rlimit_stack.patch
new file mode 100644 (file)
index 0000000..2de29d6
--- /dev/null
@@ -0,0 +1,54 @@
+From 690eac53daff34169a4d74fc7bfbd388c4896abb Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sun, 11 Jan 2015 11:33:57 -0800
+Subject: mm: Don't count the stack guard page towards RLIMIT_STACK
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 690eac53daff34169a4d74fc7bfbd388c4896abb upstream.
+
+Commit fee7e49d4514 ("mm: propagate error from stack expansion even for
+guard page") made sure that we return the error properly for stack
+growth conditions.  It also theorized that counting the guard page
+towards the stack limit might break something, but also said "Let's see
+if anybody notices".
+
+Somebody did notice.  Apparently android-x86 sets the stack limit very
+close to the limit indeed, and including the guard page in the rlimit
+check causes the android 'zygote' process problems.
+
+So this adds the (fairly trivial) code to make the stack rlimit check be
+against the actual real stack size, rather than the size of the vma that
+includes the guard page.
+
+Reported-and-tested-by: Chih-Wei Huang <cwhuang@android-x86.org>
+Cc: Jay Foad <jay.foad@gmail.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmap.c |    7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -2058,14 +2058,17 @@ static int acct_stack_growth(struct vm_a
+ {
+       struct mm_struct *mm = vma->vm_mm;
+       struct rlimit *rlim = current->signal->rlim;
+-      unsigned long new_start;
++      unsigned long new_start, actual_size;
+       /* address space limit tests */
+       if (!may_expand_vm(mm, grow))
+               return -ENOMEM;
+       /* Stack limit test */
+-      if (size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
++      actual_size = size;
++      if (size && (vma->vm_flags & (VM_GROWSUP | VM_GROWSDOWN)))
++              actual_size -= PAGE_SIZE;
++      if (actual_size > ACCESS_ONCE(rlim[RLIMIT_STACK].rlim_cur))
+               return -ENOMEM;
+       /* mlock limit tests */
diff --git a/queue-3.14/mm-propagate-error-from-stack-expansion-even-for-guard-page.patch b/queue-3.14/mm-propagate-error-from-stack-expansion-even-for-guard-page.patch
new file mode 100644 (file)
index 0000000..5d7a251
--- /dev/null
@@ -0,0 +1,70 @@
+From fee7e49d45149fba60156f5b59014f764d3e3728 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Tue, 6 Jan 2015 13:00:05 -0800
+Subject: mm: propagate error from stack expansion even for guard page
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit fee7e49d45149fba60156f5b59014f764d3e3728 upstream.
+
+Jay Foad reports that the address sanitizer test (asan) sometimes gets
+confused by a stack pointer that ends up being outside the stack vma
+that is reported by /proc/maps.
+
+This happens due to an interaction between RLIMIT_STACK and the guard
+page: when we do the guard page check, we ignore the potential error
+from the stack expansion, which effectively results in a missing guard
+page, since the expected stack expansion won't have been done.
+
+And since /proc/maps explicitly ignores the guard page (commit
+d7824370e263: "mm: fix up some user-visible effects of the stack guard
+page"), the stack pointer ends up being outside the reported stack area.
+
+This is the minimal patch: it just propagates the error.  It also
+effectively makes the guard page part of the stack limit, which in turn
+measn that the actual real stack is one page less than the stack limit.
+
+Let's see if anybody notices.  We could teach acct_stack_growth() to
+allow an extra page for a grow-up/grow-down stack in the rlimit test,
+but I don't want to add more complexity if it isn't needed.
+
+Reported-and-tested-by: Jay Foad <jay.foad@gmail.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/mm.h |    2 +-
+ mm/memory.c        |    4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/include/linux/mm.h
++++ b/include/linux/mm.h
+@@ -1866,7 +1866,7 @@ extern int expand_downwards(struct vm_ar
+ #if VM_GROWSUP
+ extern int expand_upwards(struct vm_area_struct *vma, unsigned long address);
+ #else
+-  #define expand_upwards(vma, address) do { } while (0)
++  #define expand_upwards(vma, address) (0)
+ #endif
+ /* Look up the first VMA which satisfies  addr < vm_end,  NULL if none. */
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -3204,7 +3204,7 @@ static inline int check_stack_guard_page
+               if (prev && prev->vm_end == address)
+                       return prev->vm_flags & VM_GROWSDOWN ? 0 : -ENOMEM;
+-              expand_downwards(vma, address - PAGE_SIZE);
++              return expand_downwards(vma, address - PAGE_SIZE);
+       }
+       if ((vma->vm_flags & VM_GROWSUP) && address + PAGE_SIZE == vma->vm_end) {
+               struct vm_area_struct *next = vma->vm_next;
+@@ -3213,7 +3213,7 @@ static inline int check_stack_guard_page
+               if (next && next->vm_start == address + PAGE_SIZE)
+                       return next->vm_flags & VM_GROWSUP ? 0 : -ENOMEM;
+-              expand_upwards(vma, address + PAGE_SIZE);
++              return expand_upwards(vma, address + PAGE_SIZE);
+       }
+       return 0;
+ }
diff --git a/queue-3.14/mm-vmscan-prevent-kswapd-livelock-due-to-pfmemalloc-throttled-process-being-killed.patch b/queue-3.14/mm-vmscan-prevent-kswapd-livelock-due-to-pfmemalloc-throttled-process-being-killed.patch
new file mode 100644 (file)
index 0000000..fb1cbce
--- /dev/null
@@ -0,0 +1,109 @@
+From 9e5e3661727eaf960d3480213f8e87c8d67b6956 Mon Sep 17 00:00:00 2001
+From: Vlastimil Babka <vbabka@suse.cz>
+Date: Thu, 8 Jan 2015 14:32:40 -0800
+Subject: mm, vmscan: prevent kswapd livelock due to pfmemalloc-throttled process being killed
+
+From: Vlastimil Babka <vbabka@suse.cz>
+
+commit 9e5e3661727eaf960d3480213f8e87c8d67b6956 upstream.
+
+Charles Shirron and Paul Cassella from Cray Inc have reported kswapd
+stuck in a busy loop with nothing left to balance, but
+kswapd_try_to_sleep() failing to sleep.  Their analysis found the cause
+to be a combination of several factors:
+
+1. A process is waiting in throttle_direct_reclaim() on pgdat->pfmemalloc_wait
+
+2. The process has been killed (by OOM in this case), but has not yet been
+   scheduled to remove itself from the waitqueue and die.
+
+3. kswapd checks for throttled processes in prepare_kswapd_sleep():
+
+        if (waitqueue_active(&pgdat->pfmemalloc_wait)) {
+                wake_up(&pgdat->pfmemalloc_wait);
+               return false; // kswapd will not go to sleep
+       }
+
+   However, for a process that was already killed, wake_up() does not remove
+   the process from the waitqueue, since try_to_wake_up() checks its state
+   first and returns false when the process is no longer waiting.
+
+4. kswapd is running on the same CPU as the only CPU that the process is
+   allowed to run on (through cpus_allowed, or possibly single-cpu system).
+
+5. CONFIG_PREEMPT_NONE=y kernel is used. If there's nothing to balance, kswapd
+   encounters no voluntary preemption points and repeatedly fails
+   prepare_kswapd_sleep(), blocking the process from running and removing
+   itself from the waitqueue, which would let kswapd sleep.
+
+So, the source of the problem is that we prevent kswapd from going to
+sleep until there are processes waiting on the pfmemalloc_wait queue,
+and a process waiting on a queue is guaranteed to be removed from the
+queue only when it gets scheduled.  This was done to make sure that no
+process is left sleeping on pfmemalloc_wait when kswapd itself goes to
+sleep.
+
+However, it isn't necessary to postpone kswapd sleep until the
+pfmemalloc_wait queue actually empties.  To prevent processes from being
+left sleeping, it's actually enough to guarantee that all processes
+waiting on pfmemalloc_wait queue have been woken up by the time we put
+kswapd to sleep.
+
+This patch therefore fixes this issue by substituting 'wake_up' with
+'wake_up_all' and removing 'return false' in the code snippet from
+prepare_kswapd_sleep() above.  Note that if any process puts itself in
+the queue after this waitqueue_active() check, or after the wake up
+itself, it means that the process will also wake up kswapd - and since
+we are under prepare_to_wait(), the wake up won't be missed.  Also we
+update the comment prepare_kswapd_sleep() to hopefully more clearly
+describe the races it is preventing.
+
+Fixes: 5515061d22f0 ("mm: throttle direct reclaimers if PF_MEMALLOC reserves are low and swap is backed by network storage")
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Michal Hocko <mhocko@suse.cz>
+Acked-by: Rik van Riel <riel@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/vmscan.c |   24 +++++++++++++-----------
+ 1 file changed, 13 insertions(+), 11 deletions(-)
+
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -2860,18 +2860,20 @@ static bool prepare_kswapd_sleep(pg_data
+               return false;
+       /*
+-       * There is a potential race between when kswapd checks its watermarks
+-       * and a process gets throttled. There is also a potential race if
+-       * processes get throttled, kswapd wakes, a large process exits therby
+-       * balancing the zones that causes kswapd to miss a wakeup. If kswapd
+-       * is going to sleep, no process should be sleeping on pfmemalloc_wait
+-       * so wake them now if necessary. If necessary, processes will wake
+-       * kswapd and get throttled again
++       * The throttled processes are normally woken up in balance_pgdat() as
++       * soon as pfmemalloc_watermark_ok() is true. But there is a potential
++       * race between when kswapd checks the watermarks and a process gets
++       * throttled. There is also a potential race if processes get
++       * throttled, kswapd wakes, a large process exits thereby balancing the
++       * zones, which causes kswapd to exit balance_pgdat() before reaching
++       * the wake up checks. If kswapd is going to sleep, no process should
++       * be sleeping on pfmemalloc_wait, so wake them now if necessary. If
++       * the wake up is premature, processes will wake kswapd and get
++       * throttled again. The difference from wake ups in balance_pgdat() is
++       * that here we are under prepare_to_wait().
+        */
+-      if (waitqueue_active(&pgdat->pfmemalloc_wait)) {
+-              wake_up(&pgdat->pfmemalloc_wait);
+-              return false;
+-      }
++      if (waitqueue_active(&pgdat->pfmemalloc_wait))
++              wake_up_all(&pgdat->pfmemalloc_wait);
+       return pgdat_balanced(pgdat, order, classzone_idx);
+ }
diff --git a/queue-3.14/mmc-sdhci-fix-sleep-in-atomic-after-inserting-sd-card.patch b/queue-3.14/mmc-sdhci-fix-sleep-in-atomic-after-inserting-sd-card.patch
new file mode 100644 (file)
index 0000000..c0ee2ce
--- /dev/null
@@ -0,0 +1,98 @@
+From 2836766a9d0bd02c66073f8dd44796e6cc23848d Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
+Date: Mon, 5 Jan 2015 10:50:15 +0100
+Subject: mmc: sdhci: Fix sleep in atomic after inserting SD card
+
+From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
+
+commit 2836766a9d0bd02c66073f8dd44796e6cc23848d upstream.
+
+Sleep in atomic context happened on Trats2 board after inserting or
+removing SD card because mmc_gpio_get_cd() was called under spin lock.
+
+Fix this by moving card detection earlier, before acquiring spin lock.
+The mmc_gpio_get_cd() call does not have to be protected by spin lock
+because it does not access any sdhci internal data.
+The sdhci_do_get_cd() call access host flags (SDHCI_DEVICE_DEAD). After
+moving it out side of spin lock it could theoretically race with driver
+removal but still there is no actual protection against manual card
+eject.
+
+Dmesg after inserting SD card:
+[   41.663414] BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1511
+[   41.670469] in_atomic(): 1, irqs_disabled(): 128, pid: 30, name: kworker/u8:1
+[   41.677580] INFO: lockdep is turned off.
+[   41.681486] irq event stamp: 61972
+[   41.684872] hardirqs last  enabled at (61971): [<c0490ee0>] _raw_spin_unlock_irq+0x24/0x5c
+[   41.693118] hardirqs last disabled at (61972): [<c04907ac>] _raw_spin_lock_irq+0x18/0x54
+[   41.701190] softirqs last  enabled at (61648): [<c0026fd4>] __do_softirq+0x234/0x2c8
+[   41.708914] softirqs last disabled at (61631): [<c00273a0>] irq_exit+0xd0/0x114
+[   41.716206] Preemption disabled at:[<  (null)>]   (null)
+[   41.721500]
+[   41.722985] CPU: 3 PID: 30 Comm: kworker/u8:1 Tainted: G        W      3.18.0-rc5-next-20141121 #883
+[   41.732111] Workqueue: kmmcd mmc_rescan
+[   41.735945] [<c0014d2c>] (unwind_backtrace) from [<c0011c80>] (show_stack+0x10/0x14)
+[   41.743661] [<c0011c80>] (show_stack) from [<c0489d14>] (dump_stack+0x70/0xbc)
+[   41.750867] [<c0489d14>] (dump_stack) from [<c0228b74>] (gpiod_get_raw_value_cansleep+0x18/0x30)
+[   41.759628] [<c0228b74>] (gpiod_get_raw_value_cansleep) from [<c03646e8>] (mmc_gpio_get_cd+0x38/0x58)
+[   41.768821] [<c03646e8>] (mmc_gpio_get_cd) from [<c036d378>] (sdhci_request+0x50/0x1a4)
+[   41.776808] [<c036d378>] (sdhci_request) from [<c0357934>] (mmc_start_request+0x138/0x268)
+[   41.785051] [<c0357934>] (mmc_start_request) from [<c0357cc8>] (mmc_wait_for_req+0x58/0x1a0)
+[   41.793469] [<c0357cc8>] (mmc_wait_for_req) from [<c0357e68>] (mmc_wait_for_cmd+0x58/0x78)
+[   41.801714] [<c0357e68>] (mmc_wait_for_cmd) from [<c0361c00>] (mmc_io_rw_direct_host+0x98/0x124)
+[   41.810480] [<c0361c00>] (mmc_io_rw_direct_host) from [<c03620f8>] (sdio_reset+0x2c/0x64)
+[   41.818641] [<c03620f8>] (sdio_reset) from [<c035a3d8>] (mmc_rescan+0x254/0x2e4)
+[   41.826028] [<c035a3d8>] (mmc_rescan) from [<c003a0e0>] (process_one_work+0x180/0x3f4)
+[   41.833920] [<c003a0e0>] (process_one_work) from [<c003a3bc>] (worker_thread+0x34/0x4b0)
+[   41.841991] [<c003a3bc>] (worker_thread) from [<c003fed8>] (kthread+0xe4/0x104)
+[   41.849285] [<c003fed8>] (kthread) from [<c000f268>] (ret_from_fork+0x14/0x2c)
+[   42.038276] mmc0: new high speed SDHC card at address 1234
+
+Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
+Fixes: 94144a465dd0 ("mmc: sdhci: add get_cd() implementation")
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci.c |    8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/sdhci.c
++++ b/drivers/mmc/host/sdhci.c
+@@ -1343,6 +1343,8 @@ static void sdhci_request(struct mmc_hos
+       sdhci_runtime_pm_get(host);
++      present = mmc_gpio_get_cd(host->mmc);
++
+       spin_lock_irqsave(&host->lock, flags);
+       WARN_ON(host->mrq != NULL);
+@@ -1371,7 +1373,6 @@ static void sdhci_request(struct mmc_hos
+        *     zero: cd-gpio is used, and card is removed
+        *     one: cd-gpio is used, and card is present
+        */
+-      present = mmc_gpio_get_cd(host->mmc);
+       if (present < 0) {
+               /* If polling, assume that the card is always present. */
+               if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+@@ -2082,15 +2083,18 @@ static void sdhci_card_event(struct mmc_
+ {
+       struct sdhci_host *host = mmc_priv(mmc);
+       unsigned long flags;
++      int present;
+       /* First check if client has provided their own card event */
+       if (host->ops->card_event)
+               host->ops->card_event(host);
++      present = sdhci_do_get_cd(host);
++
+       spin_lock_irqsave(&host->lock, flags);
+       /* Check host->mrq first in case we are runtime suspended */
+-      if (host->mrq && !sdhci_do_get_cd(host)) {
++      if (host->mrq && !present) {
+               pr_err("%s: Card removed during transfer!\n",
+                       mmc_hostname(host->mmc));
+               pr_err("%s: Resetting controller.\n",
index 3cb6366cb921d46da24627ef9385d3f38be75b88..9ee43e912dc41e6ca01e9856c26bb063d696f70b 100644 (file)
@@ -70,3 +70,8 @@ btrfs-don-t-delay-inode-ref-updates-during-log-replay.patch
 perf-x86-intel-uncore-make-sure-only-uncore-events-are-collected.patch
 perf-fix-events-installation-during-moving-group.patch
 perf-session-do-not-fail-on-processing-out-of-order-event.patch
+spi-fsl-fix-problem-with-multi-message-transfers.patch
+mmc-sdhci-fix-sleep-in-atomic-after-inserting-sd-card.patch
+mm-vmscan-prevent-kswapd-livelock-due-to-pfmemalloc-throttled-process-being-killed.patch
+mm-propagate-error-from-stack-expansion-even-for-guard-page.patch
+mm-don-t-count-the-stack-guard-page-towards-rlimit_stack.patch
diff --git a/queue-3.14/spi-fsl-fix-problem-with-multi-message-transfers.patch b/queue-3.14/spi-fsl-fix-problem-with-multi-message-transfers.patch
new file mode 100644 (file)
index 0000000..6026882
--- /dev/null
@@ -0,0 +1,65 @@
+From 4302a59629f7a0bd70fd1605d2b558597517372a Mon Sep 17 00:00:00 2001
+From: Stefan Roese <sr@denx.de>
+Date: Fri, 31 Jan 2014 13:44:59 +0100
+Subject: spi: fsl: Fix problem with multi message transfers
+
+From: Stefan Roese <sr@denx.de>
+
+commit 4302a59629f7a0bd70fd1605d2b558597517372a upstream.
+
+When used via spidev with more than one messages to tranfer via
+SPI_IOC_MESSAGE the current implementation would return with
+-EINVAL, since bits_per_word and speed_hz are set in all
+transfer structs. And in the 2nd loop status will stay at
+-EINVAL as its not overwritten again via fsl_spi_setup_transfer().
+
+This patch changes this behavious by first checking if one of
+the messages uses different settings. If this is the case
+the function will return with -EINVAL. If not, the messages
+are transferred correctly.
+
+Signed-off-by: Stefan Roese <sr@denx.de>
+Signed-off-by: Mark Brown <broonie@linaro.org>
+Cc: Esben Haabendal <esbenhaabendal@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-fsl-spi.c |   20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+--- a/drivers/spi/spi-fsl-spi.c
++++ b/drivers/spi/spi-fsl-spi.c
+@@ -362,18 +362,28 @@ static int fsl_spi_bufs(struct spi_devic
+ static void fsl_spi_do_one_msg(struct spi_message *m)
+ {
+       struct spi_device *spi = m->spi;
+-      struct spi_transfer *t;
++      struct spi_transfer *t, *first;
+       unsigned int cs_change;
+       const int nsecs = 50;
+       int status;
+-      cs_change = 1;
+-      status = 0;
++      /* Don't allow changes if CS is active */
++      first = list_first_entry(&m->transfers, struct spi_transfer,
++                      transfer_list);
+       list_for_each_entry(t, &m->transfers, transfer_list) {
+-              if (t->bits_per_word || t->speed_hz) {
+-                      /* Don't allow changes if CS is active */
++              if ((first->bits_per_word != t->bits_per_word) ||
++                      (first->speed_hz != t->speed_hz)) {
+                       status = -EINVAL;
++                      dev_err(&spi->dev,
++                              "bits_per_word/speed_hz should be same for the same SPI transfer\n");
++                      return;
++              }
++      }
++      cs_change = 1;
++      status = -EINVAL;
++      list_for_each_entry(t, &m->transfers, transfer_list) {
++              if (t->bits_per_word || t->speed_hz) {
+                       if (cs_change)
+                               status = fsl_spi_setup_transfer(spi, t);
+                       if (status < 0)