]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.9-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 20 Mar 2019 18:06:41 +0000 (19:06 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 20 Mar 2019 18:06:41 +0000 (19:06 +0100)
added patches:
btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch
btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch
clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch
clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch
crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch
fs-devpts-always-delete-dcache-dentry-s-in-dput.patch
m68k-add-ffreestanding-to-cflags.patch
regulator-max77620-initialize-values-for-dt-properties.patch
regulator-s2mpa01-fix-step-values-for-some-ldos.patch
regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch
s390-virtio-handle-find-on-invalid-queue-gracefully.patch
scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch
scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch
spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch
splice-don-t-merge-into-linked-buffers.patch

19 files changed:
queue-4.9/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch [new file with mode: 0644]
queue-4.9/btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch [new file with mode: 0644]
queue-4.9/btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch [new file with mode: 0644]
queue-4.9/clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch [new file with mode: 0644]
queue-4.9/clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch [new file with mode: 0644]
queue-4.9/crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch [new file with mode: 0644]
queue-4.9/fs-devpts-always-delete-dcache-dentry-s-in-dput.patch [new file with mode: 0644]
queue-4.9/m68k-add-ffreestanding-to-cflags.patch [new file with mode: 0644]
queue-4.9/regulator-max77620-initialize-values-for-dt-properties.patch [new file with mode: 0644]
queue-4.9/regulator-s2mpa01-fix-step-values-for-some-ldos.patch [new file with mode: 0644]
queue-4.9/regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch [new file with mode: 0644]
queue-4.9/s390-virtio-handle-find-on-invalid-queue-gracefully.patch [new file with mode: 0644]
queue-4.9/scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch [new file with mode: 0644]
queue-4.9/scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch [new file with mode: 0644]
queue-4.9/scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch [new file with mode: 0644]
queue-4.9/series
queue-4.9/spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch [new file with mode: 0644]
queue-4.9/spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch [new file with mode: 0644]
queue-4.9/splice-don-t-merge-into-linked-buffers.patch [new file with mode: 0644]

diff --git a/queue-4.9/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch b/queue-4.9/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
new file mode 100644 (file)
index 0000000..779454a
--- /dev/null
@@ -0,0 +1,55 @@
+From 349ae63f40638a28c6fce52e8447c2d14b84cc0c Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <jthumshirn@suse.de>
+Date: Mon, 18 Feb 2019 11:28:37 +0100
+Subject: btrfs: ensure that a DUP or RAID1 block group has exactly two stripes
+
+From: Johannes Thumshirn <jthumshirn@suse.de>
+
+commit 349ae63f40638a28c6fce52e8447c2d14b84cc0c upstream.
+
+We recently had a customer issue with a corrupted filesystem. When
+trying to mount this image btrfs panicked with a division by zero in
+calc_stripe_length().
+
+The corrupt chunk had a 'num_stripes' value of 1. calc_stripe_length()
+takes this value and divides it by the number of copies the RAID profile
+is expected to have to calculate the amount of data stripes. As a DUP
+profile is expected to have 2 copies this division resulted in 1/2 = 0.
+Later then the 'data_stripes' variable is used as a divisor in the
+stripe length calculation which results in a division by 0 and thus a
+kernel panic.
+
+When encountering a filesystem with a DUP block group and a
+'num_stripes' value unequal to 2, refuse mounting as the image is
+corrupted and will lead to unexpected behaviour.
+
+Code inspection showed a RAID1 block group has the same issues.
+
+Fixes: e06cd3dd7cea ("Btrfs: add validadtion checks for chunk loading")
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/volumes.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/volumes.c
++++ b/fs/btrfs/volumes.c
+@@ -6439,10 +6439,10 @@ static int btrfs_check_chunk_valid(struc
+       }
+       if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) ||
+-          (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) ||
++          (type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes != 2) ||
+           (type & BTRFS_BLOCK_GROUP_RAID5 && num_stripes < 2) ||
+           (type & BTRFS_BLOCK_GROUP_RAID6 && num_stripes < 3) ||
+-          (type & BTRFS_BLOCK_GROUP_DUP && num_stripes > 2) ||
++          (type & BTRFS_BLOCK_GROUP_DUP && num_stripes != 2) ||
+           ((type & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 0 &&
+            num_stripes != 1)) {
+               btrfs_err(root->fs_info,
diff --git a/queue-4.9/btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch b/queue-4.9/btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch
new file mode 100644 (file)
index 0000000..91798d9
--- /dev/null
@@ -0,0 +1,118 @@
+From 8e928218780e2f1cf2f5891c7575e8f0b284fcce Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 14 Feb 2019 15:17:20 +0000
+Subject: Btrfs: fix corruption reading shared and compressed extents after hole punching
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 8e928218780e2f1cf2f5891c7575e8f0b284fcce upstream.
+
+In the past we had data corruption when reading compressed extents that
+are shared within the same file and they are consecutive, this got fixed
+by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and
+shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read
+corruption of compressed and shared extents"). However there was a case
+that was missing in those fixes, which is when the shared and compressed
+extents are referenced with a non-zero offset. The following shell script
+creates a reproducer for this issue:
+
+  #!/bin/bash
+
+  mkfs.btrfs -f /dev/sdc &> /dev/null
+  mount -o compress /dev/sdc /mnt/sdc
+
+  # Create a file with 3 consecutive compressed extents, each has an
+  # uncompressed size of 128Kb and a compressed size of 4Kb.
+  for ((i = 1; i <= 3; i++)); do
+      head -c 4096 /dev/zero
+      for ((j = 1; j <= 31; j++)); do
+          head -c 4096 /dev/zero | tr '\0' "\377"
+      done
+  done > /mnt/sdc/foobar
+  sync
+
+  echo "Digest after file creation:   $(md5sum /mnt/sdc/foobar)"
+
+  # Clone the first extent into offsets 128K and 256K.
+  xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar
+  xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar
+  sync
+
+  echo "Digest after cloning:         $(md5sum /mnt/sdc/foobar)"
+
+  # Punch holes into the regions that are already full of zeroes.
+  xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
+  xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
+  xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
+  sync
+
+  echo "Digest after hole punching:   $(md5sum /mnt/sdc/foobar)"
+
+  echo "Dropping page cache..."
+  sysctl -q vm.drop_caches=1
+  echo "Digest after hole punching:   $(md5sum /mnt/sdc/foobar)"
+
+  umount /dev/sdc
+
+When running the script we get the following output:
+
+  Digest after file creation:   5a0888d80d7ab1fd31c229f83a3bbcc8  /mnt/sdc/foobar
+  linked 131072/131072 bytes at offset 131072
+  128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec)
+  linked 131072/131072 bytes at offset 262144
+  128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
+  Digest after cloning:         5a0888d80d7ab1fd31c229f83a3bbcc8  /mnt/sdc/foobar
+  Digest after hole punching:   5a0888d80d7ab1fd31c229f83a3bbcc8  /mnt/sdc/foobar
+  Dropping page cache...
+  Digest after hole punching:   fba694ae8664ed0c2e9ff8937e7f1484  /mnt/sdc/foobar
+
+This happens because after reading all the pages of the extent in the
+range from 128K to 256K for example, we read the hole at offset 256K
+and then when reading the page at offset 260K we don't submit the
+existing bio, which is responsible for filling all the page in the
+range 128K to 256K only, therefore adding the pages from range 260K
+to 384K to the existing bio and submitting it after iterating over the
+entire range. Once the bio completes, the uncompressed data fills only
+the pages in the range 128K to 256K because there's no more data read
+from disk, leaving the pages in the range 260K to 384K unfilled. It is
+just a slightly different variant of what was solved by commit
+005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared
+extents").
+
+Fix this by forcing a bio submit, during readpages(), whenever we find a
+compressed extent map for a page that is different from the extent map
+for the previous page or has a different starting offset (in case it's
+the same compressed extent), instead of the extent map's original start
+offset.
+
+A test case for fstests follows soon.
+
+Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+Fixes: 808f80b46790f ("Btrfs: update fix for read corruption of compressed and shared extents")
+Fixes: 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared extents")
+Cc: stable@vger.kernel.org # 4.3+
+Tested-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent_io.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/extent_io.c
++++ b/fs/btrfs/extent_io.c
+@@ -3018,11 +3018,11 @@ static int __do_readpage(struct extent_i
+                */
+               if (test_bit(EXTENT_FLAG_COMPRESSED, &em->flags) &&
+                   prev_em_start && *prev_em_start != (u64)-1 &&
+-                  *prev_em_start != em->orig_start)
++                  *prev_em_start != em->start)
+                       force_bio_submit = true;
+               if (prev_em_start)
+-                      *prev_em_start = em->orig_start;
++                      *prev_em_start = em->start;
+               free_extent_map(em);
+               em = NULL;
diff --git a/queue-4.9/btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch b/queue-4.9/btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch
new file mode 100644 (file)
index 0000000..5be6179
--- /dev/null
@@ -0,0 +1,52 @@
+From a0873490660246db587849a9e172f2b7b21fa88a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 13 Dec 2018 21:16:56 +0000
+Subject: Btrfs: setup a nofs context for memory allocation at __btrfs_set_acl
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit a0873490660246db587849a9e172f2b7b21fa88a upstream.
+
+We are holding a transaction handle when setting an acl, therefore we can
+not allocate the xattr value buffer using GFP_KERNEL, as we could deadlock
+if reclaim is triggered by the allocation, therefore setup a nofs context.
+
+Fixes: 39a27ec1004e8 ("btrfs: use GFP_KERNEL for xattr and acl allocations")
+CC: stable@vger.kernel.org # 4.9+
+Reviewed-by: Nikolay Borisov <nborisov@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/acl.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/btrfs/acl.c
++++ b/fs/btrfs/acl.c
+@@ -22,6 +22,7 @@
+ #include <linux/posix_acl_xattr.h>
+ #include <linux/posix_acl.h>
+ #include <linux/sched.h>
++#include <linux/sched/mm.h>
+ #include <linux/slab.h>
+ #include "ctree.h"
+@@ -89,8 +90,16 @@ static int __btrfs_set_acl(struct btrfs_
+       }
+       if (acl) {
++              unsigned int nofs_flag;
++
+               size = posix_acl_xattr_size(acl->a_count);
++              /*
++               * We're holding a transaction handle, so use a NOFS memory
++               * allocation context to avoid deadlock if reclaim happens.
++               */
++              nofs_flag = memalloc_nofs_save();
+               value = kmalloc(size, GFP_KERNEL);
++              memalloc_nofs_restore(nofs_flag);
+               if (!value) {
+                       ret = -ENOMEM;
+                       goto out;
diff --git a/queue-4.9/clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch b/queue-4.9/clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch
new file mode 100644 (file)
index 0000000..cdbaed3
--- /dev/null
@@ -0,0 +1,36 @@
+From d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Sun, 10 Feb 2019 22:51:14 +0000
+Subject: clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c upstream.
+
+When shutting down the timer, ensure that after we have stopped the
+timer any pending interrupts are cleared. This fixes a problem when
+suspending, as interrupts are disabled before the timer is stopped,
+so the timer interrupt may still be asserted, preventing the system
+entering a low power state when the wfi is executed.
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: <stable@vger.kernel.org> # v4.3+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/exynos_mct.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clocksource/exynos_mct.c
++++ b/drivers/clocksource/exynos_mct.c
+@@ -411,6 +411,7 @@ static int set_state_shutdown(struct clo
+       mevt = container_of(evt, struct mct_clock_event_device, evt);
+       exynos4_mct_tick_stop(mevt);
++      exynos4_mct_tick_clear(mevt);
+       return 0;
+ }
diff --git a/queue-4.9/clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch b/queue-4.9/clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch
new file mode 100644 (file)
index 0000000..4440582
--- /dev/null
@@ -0,0 +1,73 @@
+From a5719a40aef956ba704f2aa1c7b977224d60fa96 Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Sun, 10 Feb 2019 22:51:13 +0000
+Subject: clocksource/drivers/exynos_mct: Move one-shot check from tick clear to ISR
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit a5719a40aef956ba704f2aa1c7b977224d60fa96 upstream.
+
+When a timer tick occurs and the clock is in one-shot mode, the timer
+needs to be stopped to prevent it triggering subsequent interrupts.
+Currently this code is in exynos4_mct_tick_clear(), but as it is
+only needed when an ISR occurs move it into exynos4_mct_tick_isr(),
+leaving exynos4_mct_tick_clear() just doing what its name suggests it
+should.
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: stable@vger.kernel.org # v4.3+
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clocksource/exynos_mct.c |   22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+--- a/drivers/clocksource/exynos_mct.c
++++ b/drivers/clocksource/exynos_mct.c
+@@ -388,6 +388,13 @@ static void exynos4_mct_tick_start(unsig
+       exynos4_mct_write(tmp, mevt->base + MCT_L_TCON_OFFSET);
+ }
++static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
++{
++      /* Clear the MCT tick interrupt */
++      if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
++              exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
++}
++
+ static int exynos4_tick_set_next_event(unsigned long cycles,
+                                      struct clock_event_device *evt)
+ {
+@@ -420,8 +427,11 @@ static int set_state_periodic(struct clo
+       return 0;
+ }
+-static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
++static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
+ {
++      struct mct_clock_event_device *mevt = dev_id;
++      struct clock_event_device *evt = &mevt->evt;
++
+       /*
+        * This is for supporting oneshot mode.
+        * Mct would generate interrupt periodically
+@@ -430,16 +440,6 @@ static void exynos4_mct_tick_clear(struc
+       if (!clockevent_state_periodic(&mevt->evt))
+               exynos4_mct_tick_stop(mevt);
+-      /* Clear the MCT tick interrupt */
+-      if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
+-              exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
+-}
+-
+-static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
+-{
+-      struct mct_clock_event_device *mevt = dev_id;
+-      struct clock_event_device *evt = &mevt->evt;
+-
+       exynos4_mct_tick_clear(mevt);
+       evt->event_handler(evt);
diff --git a/queue-4.9/crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch b/queue-4.9/crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch
new file mode 100644 (file)
index 0000000..f35662f
--- /dev/null
@@ -0,0 +1,93 @@
+From 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Thu, 3 Jan 2019 20:16:13 -0800
+Subject: crypto: pcbc - remove bogus memcpy()s with src == dest
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 251b7aea34ba3c4d4fdfa9447695642eb8b8b098 upstream.
+
+The memcpy()s in the PCBC implementation use walk->iv as both the source
+and destination, which has undefined behavior.  These memcpy()'s are
+actually unneeded, because walk->iv is already used to hold the previous
+plaintext block XOR'd with the previous ciphertext block.  Thus,
+walk->iv is already updated to its final value.
+
+So remove the broken and unnecessary memcpy()s.
+
+Fixes: 91652be5d1b9 ("[CRYPTO] pcbc: Add Propagated CBC template")
+Cc: <stable@vger.kernel.org> # v2.6.21+
+Cc: David Howells <dhowells@redhat.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Maxim Zhukov <mussitantesmortem@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/pcbc.c |   14 ++++----------
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/crypto/pcbc.c
++++ b/crypto/pcbc.c
+@@ -52,7 +52,7 @@ static int crypto_pcbc_encrypt_segment(s
+       unsigned int nbytes = walk->nbytes;
+       u8 *src = walk->src.virt.addr;
+       u8 *dst = walk->dst.virt.addr;
+-      u8 *iv = walk->iv;
++      u8 * const iv = walk->iv;
+       do {
+               crypto_xor(iv, src, bsize);
+@@ -76,7 +76,7 @@ static int crypto_pcbc_encrypt_inplace(s
+       int bsize = crypto_cipher_blocksize(tfm);
+       unsigned int nbytes = walk->nbytes;
+       u8 *src = walk->src.virt.addr;
+-      u8 *iv = walk->iv;
++      u8 * const iv = walk->iv;
+       u8 tmpbuf[bsize];
+       do {
+@@ -89,8 +89,6 @@ static int crypto_pcbc_encrypt_inplace(s
+               src += bsize;
+       } while ((nbytes -= bsize) >= bsize);
+-      memcpy(walk->iv, iv, bsize);
+-
+       return nbytes;
+ }
+@@ -130,7 +128,7 @@ static int crypto_pcbc_decrypt_segment(s
+       unsigned int nbytes = walk->nbytes;
+       u8 *src = walk->src.virt.addr;
+       u8 *dst = walk->dst.virt.addr;
+-      u8 *iv = walk->iv;
++      u8 * const iv = walk->iv;
+       do {
+               fn(crypto_cipher_tfm(tfm), dst, src);
+@@ -142,8 +140,6 @@ static int crypto_pcbc_decrypt_segment(s
+               dst += bsize;
+       } while ((nbytes -= bsize) >= bsize);
+-      memcpy(walk->iv, iv, bsize);
+-
+       return nbytes;
+ }
+@@ -156,7 +152,7 @@ static int crypto_pcbc_decrypt_inplace(s
+       int bsize = crypto_cipher_blocksize(tfm);
+       unsigned int nbytes = walk->nbytes;
+       u8 *src = walk->src.virt.addr;
+-      u8 *iv = walk->iv;
++      u8 * const iv = walk->iv;
+       u8 tmpbuf[bsize];
+       do {
+@@ -169,8 +165,6 @@ static int crypto_pcbc_decrypt_inplace(s
+               src += bsize;
+       } while ((nbytes -= bsize) >= bsize);
+-      memcpy(walk->iv, iv, bsize);
+-
+       return nbytes;
+ }
diff --git a/queue-4.9/fs-devpts-always-delete-dcache-dentry-s-in-dput.patch b/queue-4.9/fs-devpts-always-delete-dcache-dentry-s-in-dput.patch
new file mode 100644 (file)
index 0000000..dd571b8
--- /dev/null
@@ -0,0 +1,80 @@
+From 73052b0daee0b750b39af18460dfec683e4f5887 Mon Sep 17 00:00:00 2001
+From: Varad Gautam <vrd@amazon.de>
+Date: Thu, 24 Jan 2019 14:03:06 +0100
+Subject: fs/devpts: always delete dcache dentry-s in dput()
+
+From: Varad Gautam <vrd@amazon.de>
+
+commit 73052b0daee0b750b39af18460dfec683e4f5887 upstream.
+
+d_delete only unhashes an entry if it is reached with
+dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts:
+more pty driver interface cleanups"), d_delete was called on a dentry
+from devpts_pty_kill with two references held, which would trigger the
+unhashing, and the subsequent dputs would release it.
+
+Commit 8ead9dd54716 reworked devpts_pty_kill to stop acquiring the second
+reference from d_find_alias, and the d_delete call left the dentries
+still on the hashed list without actually ever being dropped from dcache
+before explicit cleanup. This causes the number of negative dentries for
+devpts to pile up, and an `ls /dev/pts` invocation can take seconds to
+return.
+
+Provide always_delete_dentry() from simple_dentry_operations
+as .d_delete for devpts, to make the dentry be dropped from dcache.
+
+Without this cleanup, the number of dentries in /dev/pts/ can be grown
+arbitrarily as:
+
+`python -c 'import pty; pty.spawn(["ls", "/dev/pts"])'`
+
+A systemtap probe on dcache_readdir to count d_subdirs shows this count
+to increase with each pty spawn invocation above:
+
+probe kernel.function("dcache_readdir") {
+    subdirs = &@cast($file->f_path->dentry, "dentry")->d_subdirs;
+    p = subdirs;
+    p = @cast(p, "list_head")->next;
+    i = 0
+    while (p != subdirs) {
+      p = @cast(p, "list_head")->next;
+      i = i+1;
+    }
+    printf("number of dentries: %d\n", i);
+}
+
+Fixes: 8ead9dd54716 ("devpts: more pty driver interface cleanups")
+Signed-off-by: Varad Gautam <vrd@amazon.de>
+Reported-by: Zheng Wang <wanz@amazon.de>
+Reported-by: Brandon Schwartz <bsschwar@amazon.de>
+Root-caused-by: Maximilian Heyne <mheyne@amazon.de>
+Root-caused-by: Nicolas Pernas Maradei <npernas@amazon.de>
+CC: David Woodhouse <dwmw@amazon.co.uk>
+CC: Maximilian Heyne <mheyne@amazon.de>
+CC: Stefan Nuernberger <snu@amazon.de>
+CC: Amit Shah <aams@amazon.de>
+CC: Linus Torvalds <torvalds@linux-foundation.org>
+CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+CC: Al Viro <viro@ZenIV.linux.org.uk>
+CC: Christian Brauner <christian.brauner@ubuntu.com>
+CC: Eric W. Biederman <ebiederm@xmission.com>
+CC: Matthew Wilcox <willy@infradead.org>
+CC: Eric Biggers <ebiggers@google.com>
+CC: <stable@vger.kernel.org> # 4.9+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/devpts/inode.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/devpts/inode.c
++++ b/fs/devpts/inode.c
+@@ -396,6 +396,7 @@ devpts_fill_super(struct super_block *s,
+       s->s_blocksize_bits = 10;
+       s->s_magic = DEVPTS_SUPER_MAGIC;
+       s->s_op = &devpts_sops;
++      s->s_d_op = &simple_dentry_operations;
+       s->s_time_gran = 1;
+       error = -ENOMEM;
diff --git a/queue-4.9/m68k-add-ffreestanding-to-cflags.patch b/queue-4.9/m68k-add-ffreestanding-to-cflags.patch
new file mode 100644 (file)
index 0000000..ac8bdc1
--- /dev/null
@@ -0,0 +1,55 @@
+From 28713169d879b67be2ef2f84dcf54905de238294 Mon Sep 17 00:00:00 2001
+From: Finn Thain <fthain@telegraphics.com.au>
+Date: Wed, 16 Jan 2019 16:23:24 +1100
+Subject: m68k: Add -ffreestanding to CFLAGS
+
+From: Finn Thain <fthain@telegraphics.com.au>
+
+commit 28713169d879b67be2ef2f84dcf54905de238294 upstream.
+
+This patch fixes a build failure when using GCC 8.1:
+
+/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':
+block/partitions/ldm.c:153: undefined reference to `strcmp'
+
+This is caused by a new optimization which effectively replaces a
+strncmp() call with a strcmp() call. This affects a number of strncmp()
+call sites in the kernel.
+
+The entire class of optimizations is avoided with -fno-builtin, which
+gets enabled by -ffreestanding. This may avoid possible future build
+failures in case new optimizations appear in future compilers.
+
+I haven't done any performance measurements with this patch but I did
+count the function calls in a defconfig build. For example, there are now
+23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the
+other libc functions is smaller.
+
+If this harms performance we can tackle that regression by optimizing
+the call sites, ideally using semantic patches. That way, clang and ICC
+builds might benfit too.
+
+Cc: stable@vger.kernel.org
+Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
+Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/m68k/Makefile |    5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/m68k/Makefile
++++ b/arch/m68k/Makefile
+@@ -58,7 +58,10 @@ cpuflags-$(CONFIG_M5206e)   := $(call cc-o
+ cpuflags-$(CONFIG_M5206)      := $(call cc-option,-mcpu=5206,-m5200)
+ KBUILD_AFLAGS += $(cpuflags-y)
+-KBUILD_CFLAGS += $(cpuflags-y) -pipe
++KBUILD_CFLAGS += $(cpuflags-y)
++
++KBUILD_CFLAGS += -pipe -ffreestanding
++
+ ifdef CONFIG_MMU
+ # without -fno-strength-reduce the 53c7xx.c driver fails ;-(
+ KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
diff --git a/queue-4.9/regulator-max77620-initialize-values-for-dt-properties.patch b/queue-4.9/regulator-max77620-initialize-values-for-dt-properties.patch
new file mode 100644 (file)
index 0000000..94351db
--- /dev/null
@@ -0,0 +1,50 @@
+From 0ab66b3c326ef8f77dae9f528118966365757c0c Mon Sep 17 00:00:00 2001
+From: Mark Zhang <markz@nvidia.com>
+Date: Thu, 10 Jan 2019 12:11:16 +0800
+Subject: regulator: max77620: Initialize values for DT properties
+
+From: Mark Zhang <markz@nvidia.com>
+
+commit 0ab66b3c326ef8f77dae9f528118966365757c0c upstream.
+
+If regulator DT node doesn't exist, its of_parse_cb callback
+function isn't called. Then all values for DT properties are
+filled with zero. This leads to wrong register update for
+FPS and POK settings.
+
+Signed-off-by: Jinyoung Park <jinyoungp@nvidia.com>
+Signed-off-by: Mark Zhang <markz@nvidia.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/max77620-regulator.c |   10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/regulator/max77620-regulator.c
++++ b/drivers/regulator/max77620-regulator.c
+@@ -1,7 +1,7 @@
+ /*
+  * Maxim MAX77620 Regulator driver
+  *
+- * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
++ * Copyright (c) 2016-2018, NVIDIA CORPORATION.  All rights reserved.
+  *
+  * Author: Mallikarjun Kasoju <mkasoju@nvidia.com>
+  *    Laxman Dewangan <ldewangan@nvidia.com>
+@@ -760,6 +760,14 @@ static int max77620_regulator_probe(stru
+               rdesc = &rinfo[id].desc;
+               pmic->rinfo[id] = &max77620_regs_info[id];
+               pmic->enable_power_mode[id] = MAX77620_POWER_MODE_NORMAL;
++              pmic->reg_pdata[id].active_fps_src = -1;
++              pmic->reg_pdata[id].active_fps_pd_slot = -1;
++              pmic->reg_pdata[id].active_fps_pu_slot = -1;
++              pmic->reg_pdata[id].suspend_fps_src = -1;
++              pmic->reg_pdata[id].suspend_fps_pd_slot = -1;
++              pmic->reg_pdata[id].suspend_fps_pu_slot = -1;
++              pmic->reg_pdata[id].power_ok = -1;
++              pmic->reg_pdata[id].ramp_rate_setting = -1;
+               ret = max77620_read_slew_rate(pmic, id);
+               if (ret < 0)
diff --git a/queue-4.9/regulator-s2mpa01-fix-step-values-for-some-ldos.patch b/queue-4.9/regulator-s2mpa01-fix-step-values-for-some-ldos.patch
new file mode 100644 (file)
index 0000000..ccdaf45
--- /dev/null
@@ -0,0 +1,56 @@
+From 28c4f730d2a44f2591cb104091da29a38dac49fe Mon Sep 17 00:00:00 2001
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+Date: Tue, 12 Feb 2019 21:51:18 +0000
+Subject: regulator: s2mpa01: Fix step values for some LDOs
+
+From: Stuart Menefy <stuart.menefy@mathembedded.com>
+
+commit 28c4f730d2a44f2591cb104091da29a38dac49fe upstream.
+
+The step values for some of the LDOs appears to be incorrect, resulting
+in incorrect voltages (or at least, ones which are different from the
+Samsung 3.4 vendor kernel).
+
+Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/s2mpa01.c |   10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/regulator/s2mpa01.c
++++ b/drivers/regulator/s2mpa01.c
+@@ -303,13 +303,13 @@ static const struct regulator_desc regul
+       regulator_desc_ldo(2, STEP_50_MV),
+       regulator_desc_ldo(3, STEP_50_MV),
+       regulator_desc_ldo(4, STEP_50_MV),
+-      regulator_desc_ldo(5, STEP_50_MV),
++      regulator_desc_ldo(5, STEP_25_MV),
+       regulator_desc_ldo(6, STEP_25_MV),
+       regulator_desc_ldo(7, STEP_50_MV),
+       regulator_desc_ldo(8, STEP_50_MV),
+       regulator_desc_ldo(9, STEP_50_MV),
+       regulator_desc_ldo(10, STEP_50_MV),
+-      regulator_desc_ldo(11, STEP_25_MV),
++      regulator_desc_ldo(11, STEP_50_MV),
+       regulator_desc_ldo(12, STEP_50_MV),
+       regulator_desc_ldo(13, STEP_50_MV),
+       regulator_desc_ldo(14, STEP_50_MV),
+@@ -320,11 +320,11 @@ static const struct regulator_desc regul
+       regulator_desc_ldo(19, STEP_50_MV),
+       regulator_desc_ldo(20, STEP_50_MV),
+       regulator_desc_ldo(21, STEP_50_MV),
+-      regulator_desc_ldo(22, STEP_25_MV),
+-      regulator_desc_ldo(23, STEP_25_MV),
++      regulator_desc_ldo(22, STEP_50_MV),
++      regulator_desc_ldo(23, STEP_50_MV),
+       regulator_desc_ldo(24, STEP_50_MV),
+       regulator_desc_ldo(25, STEP_50_MV),
+-      regulator_desc_ldo(26, STEP_50_MV),
++      regulator_desc_ldo(26, STEP_25_MV),
+       regulator_desc_buck1_4(1),
+       regulator_desc_buck1_4(2),
+       regulator_desc_buck1_4(3),
diff --git a/queue-4.9/regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch b/queue-4.9/regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch
new file mode 100644 (file)
index 0000000..c529edd
--- /dev/null
@@ -0,0 +1,46 @@
+From 56b5d4ea778c1b0989c5cdb5406d4a488144c416 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Sat, 9 Feb 2019 18:14:14 +0100
+Subject: regulator: s2mps11: Fix steps for buck7, buck8 and LDO35
+
+From: Krzysztof Kozlowski <krzk@kernel.org>
+
+commit 56b5d4ea778c1b0989c5cdb5406d4a488144c416 upstream.
+
+LDO35 uses 25 mV step, not 50 mV.  Bucks 7 and 8 use 12.5 mV step
+instead of 6.25 mV.  Wrong step caused over-voltage (LDO35) or
+under-voltage (buck7 and 8) if regulators were used (e.g. on Exynos5420
+Arndale Octa board).
+
+Cc: <stable@vger.kernel.org>
+Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver")
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/s2mps11.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/regulator/s2mps11.c
++++ b/drivers/regulator/s2mps11.c
+@@ -376,7 +376,7 @@ static const struct regulator_desc s2mps
+       regulator_desc_s2mps11_ldo(32, STEP_50_MV),
+       regulator_desc_s2mps11_ldo(33, STEP_50_MV),
+       regulator_desc_s2mps11_ldo(34, STEP_50_MV),
+-      regulator_desc_s2mps11_ldo(35, STEP_50_MV),
++      regulator_desc_s2mps11_ldo(35, STEP_25_MV),
+       regulator_desc_s2mps11_ldo(36, STEP_50_MV),
+       regulator_desc_s2mps11_ldo(37, STEP_50_MV),
+       regulator_desc_s2mps11_ldo(38, STEP_50_MV),
+@@ -386,8 +386,8 @@ static const struct regulator_desc s2mps
+       regulator_desc_s2mps11_buck1_4(4),
+       regulator_desc_s2mps11_buck5,
+       regulator_desc_s2mps11_buck67810(6, MIN_600_MV, STEP_6_25_MV),
+-      regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_6_25_MV),
+-      regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_6_25_MV),
++      regulator_desc_s2mps11_buck67810(7, MIN_600_MV, STEP_12_5_MV),
++      regulator_desc_s2mps11_buck67810(8, MIN_600_MV, STEP_12_5_MV),
+       regulator_desc_s2mps11_buck9,
+       regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
+ };
diff --git a/queue-4.9/s390-virtio-handle-find-on-invalid-queue-gracefully.patch b/queue-4.9/s390-virtio-handle-find-on-invalid-queue-gracefully.patch
new file mode 100644 (file)
index 0000000..22f13e9
--- /dev/null
@@ -0,0 +1,44 @@
+From 3438b2c039b4bf26881786a1f3450f016d66ad11 Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Mon, 21 Jan 2019 13:19:43 +0100
+Subject: s390/virtio: handle find on invalid queue gracefully
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit 3438b2c039b4bf26881786a1f3450f016d66ad11 upstream.
+
+A queue with a capacity of zero is clearly not a valid virtio queue.
+Some emulators report zero queue size if queried with an invalid queue
+index. Instead of crashing in this case let us just return -ENOENT. To
+make that work properly, let us fix the notifier cleanup logic as well.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Signed-off-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/virtio/virtio_ccw.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/virtio/virtio_ccw.c
++++ b/drivers/s390/virtio/virtio_ccw.c
+@@ -283,6 +283,8 @@ static void virtio_ccw_drop_indicators(s
+ {
+       struct virtio_ccw_vq_info *info;
++      if (!vcdev->airq_info)
++              return;
+       list_for_each_entry(info, &vcdev->virtqueues, node)
+               drop_airq_indicator(info->vq, vcdev->airq_info);
+ }
+@@ -424,7 +426,7 @@ static int virtio_ccw_read_vq_conf(struc
+       ret = ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_READ_VQ_CONF);
+       if (ret)
+               return ret;
+-      return vcdev->config_block->num;
++      return vcdev->config_block->num ?: -ENOENT;
+ }
+ static void virtio_ccw_del_vq(struct virtqueue *vq, struct ccw1 *ccw)
diff --git a/queue-4.9/scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch b/queue-4.9/scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch
new file mode 100644 (file)
index 0000000..ee5a50f
--- /dev/null
@@ -0,0 +1,106 @@
+From a83da8a4509d3ebfe03bb7fffce022e4d5d4764f Mon Sep 17 00:00:00 2001
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+Date: Tue, 12 Feb 2019 16:21:05 -0500
+Subject: scsi: sd: Optimal I/O size should be a multiple of physical block size
+
+From: Martin K. Petersen <martin.petersen@oracle.com>
+
+commit a83da8a4509d3ebfe03bb7fffce022e4d5d4764f upstream.
+
+It was reported that some devices report an OPTIMAL TRANSFER LENGTH of
+0xFFFF blocks. That looks bogus, especially for a device with a
+4096-byte physical block size.
+
+Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's
+reported physical block size.
+
+To make the sanity checking conditionals more readable--and to
+facilitate printing warnings--relocate the checking to a helper
+function. No functional change aside from the printks.
+
+Cc: <stable@vger.kernel.org>
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759
+Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sd.c |   59 +++++++++++++++++++++++++++++++++++++++++++++---------
+ 1 file changed, 50 insertions(+), 9 deletions(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -2834,6 +2834,55 @@ static void sd_read_write_same(struct sc
+               sdkp->ws10 = 1;
+ }
++/*
++ * Determine the device's preferred I/O size for reads and writes
++ * unless the reported value is unreasonably small, large, not a
++ * multiple of the physical block size, or simply garbage.
++ */
++static bool sd_validate_opt_xfer_size(struct scsi_disk *sdkp,
++                                    unsigned int dev_max)
++{
++      struct scsi_device *sdp = sdkp->device;
++      unsigned int opt_xfer_bytes =
++              logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
++
++      if (sdkp->opt_xfer_blocks > dev_max) {
++              sd_first_printk(KERN_WARNING, sdkp,
++                              "Optimal transfer size %u logical blocks " \
++                              "> dev_max (%u logical blocks)\n",
++                              sdkp->opt_xfer_blocks, dev_max);
++              return false;
++      }
++
++      if (sdkp->opt_xfer_blocks > SD_DEF_XFER_BLOCKS) {
++              sd_first_printk(KERN_WARNING, sdkp,
++                              "Optimal transfer size %u logical blocks " \
++                              "> sd driver limit (%u logical blocks)\n",
++                              sdkp->opt_xfer_blocks, SD_DEF_XFER_BLOCKS);
++              return false;
++      }
++
++      if (opt_xfer_bytes < PAGE_SIZE) {
++              sd_first_printk(KERN_WARNING, sdkp,
++                              "Optimal transfer size %u bytes < " \
++                              "PAGE_SIZE (%u bytes)\n",
++                              opt_xfer_bytes, (unsigned int)PAGE_SIZE);
++              return false;
++      }
++
++      if (opt_xfer_bytes & (sdkp->physical_block_size - 1)) {
++              sd_first_printk(KERN_WARNING, sdkp,
++                              "Optimal transfer size %u bytes not a " \
++                              "multiple of physical block size (%u bytes)\n",
++                              opt_xfer_bytes, sdkp->physical_block_size);
++              return false;
++      }
++
++      sd_first_printk(KERN_INFO, sdkp, "Optimal transfer size %u bytes\n",
++                      opt_xfer_bytes);
++      return true;
++}
++
+ /**
+  *    sd_revalidate_disk - called the first time a new disk is seen,
+  *    performs disk spin up, read_capacity, etc.
+@@ -2898,15 +2947,7 @@ static int sd_revalidate_disk(struct gen
+       dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks);
+       q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
+-      /*
+-       * Determine the device's preferred I/O size for reads and writes
+-       * unless the reported value is unreasonably small, large, or
+-       * garbage.
+-       */
+-      if (sdkp->opt_xfer_blocks &&
+-          sdkp->opt_xfer_blocks <= dev_max &&
+-          sdkp->opt_xfer_blocks <= SD_DEF_XFER_BLOCKS &&
+-          logical_to_bytes(sdp, sdkp->opt_xfer_blocks) >= PAGE_SIZE) {
++      if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
+               q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
+               rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks);
+       } else
diff --git a/queue-4.9/scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch b/queue-4.9/scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
new file mode 100644 (file)
index 0000000..7631600
--- /dev/null
@@ -0,0 +1,61 @@
+From 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Fri, 25 Jan 2019 10:34:56 -0800
+Subject: scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+commit 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 upstream.
+
+When using SCSI passthrough in combination with the iSCSI target driver
+then cmd->t_state_lock may be obtained from interrupt context. Hence, all
+code that obtains cmd->t_state_lock from thread context must disable
+interrupts first. This patch avoids that lockdep reports the following:
+
+WARNING: inconsistent lock state
+4.18.0-dbg+ #1 Not tainted
+--------------------------------
+inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
+iscsi_ttx/1800 [HC1[1]:SC0[2]:HE0:SE0] takes:
+000000006e7b0ceb (&(&cmd->t_state_lock)->rlock){?...}, at: target_complete_cmd+0x47/0x2c0 [target_core_mod]
+{HARDIRQ-ON-W} state was registered at:
+ lock_acquire+0xd2/0x260
+ _raw_spin_lock+0x32/0x50
+ iscsit_close_connection+0x97e/0x1020 [iscsi_target_mod]
+ iscsit_take_action_for_connection_exit+0x108/0x200 [iscsi_target_mod]
+ iscsi_target_rx_thread+0x180/0x190 [iscsi_target_mod]
+ kthread+0x1cf/0x1f0
+ ret_from_fork+0x24/0x30
+irq event stamp: 1281
+hardirqs last  enabled at (1279): [<ffffffff970ade79>] __local_bh_enable_ip+0xa9/0x160
+hardirqs last disabled at (1281): [<ffffffff97a008a5>] interrupt_entry+0xb5/0xd0
+softirqs last  enabled at (1278): [<ffffffff977cd9a1>] lock_sock_nested+0x51/0xc0
+softirqs last disabled at (1280): [<ffffffffc07a6e04>] ip6_finish_output2+0x124/0xe40 [ipv6]
+
+other info that might help us debug this:
+Possible unsafe locking scenario:
+
+      CPU0
+      ----
+ lock(&(&cmd->t_state_lock)->rlock);
+ <Interrupt>
+   lock(&(&cmd->t_state_lock)->rlock);
+
+---
+ drivers/target/iscsi/iscsi_target.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/target/iscsi/iscsi_target.c
++++ b/drivers/target/iscsi/iscsi_target.c
+@@ -4084,9 +4084,9 @@ static void iscsit_release_commands_from
+               struct se_cmd *se_cmd = &cmd->se_cmd;
+               if (se_cmd->se_tfo != NULL) {
+-                      spin_lock(&se_cmd->t_state_lock);
++                      spin_lock_irq(&se_cmd->t_state_lock);
+                       se_cmd->transport_state |= CMD_T_FABRIC_STOP;
+-                      spin_unlock(&se_cmd->t_state_lock);
++                      spin_unlock_irq(&se_cmd->t_state_lock);
+               }
+       }
+       spin_unlock_bh(&conn->cmd_lock);
diff --git a/queue-4.9/scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch b/queue-4.9/scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
new file mode 100644 (file)
index 0000000..3fb9df2
--- /dev/null
@@ -0,0 +1,63 @@
+From 3722e6a52174d7c3a00e6f5efd006ca093f346c1 Mon Sep 17 00:00:00 2001
+From: Felipe Franciosi <felipe@nutanix.com>
+Date: Wed, 27 Feb 2019 16:10:34 +0000
+Subject: scsi: virtio_scsi: don't send sc payload with tmfs
+
+From: Felipe Franciosi <felipe@nutanix.com>
+
+commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.
+
+The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of
+device-readable records and a single device-writable response entry:
+
+    struct virtio_scsi_ctrl_tmf
+    {
+        // Device-readable part
+        le32 type;
+        le32 subtype;
+        u8 lun[8];
+        le64 id;
+        // Device-writable part
+        u8 response;
+    }
+
+The above should be organised as two descriptor entries (or potentially
+more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64
+id" or after "u8 response".
+
+The Linux driver doesn't respect that, with virtscsi_abort() and
+virtscsi_device_reset() setting cmd->sc before calling virtscsi_tmf().  It
+results in the original scsi command payload (or writable buffers) added to
+the tmf.
+
+This fixes the problem by leaving cmd->sc zeroed out, which makes
+virtscsi_kick_cmd() add the tmf to the control vq without any payload.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/virtio_scsi.c |    2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/scsi/virtio_scsi.c
++++ b/drivers/scsi/virtio_scsi.c
+@@ -693,7 +693,6 @@ static int virtscsi_device_reset(struct
+               return FAILED;
+       memset(cmd, 0, sizeof(*cmd));
+-      cmd->sc = sc;
+       cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
+               .type = VIRTIO_SCSI_T_TMF,
+               .subtype = cpu_to_virtio32(vscsi->vdev,
+@@ -752,7 +751,6 @@ static int virtscsi_abort(struct scsi_cm
+               return FAILED;
+       memset(cmd, 0, sizeof(*cmd));
+-      cmd->sc = sc;
+       cmd->req.tmf = (struct virtio_scsi_ctrl_tmf_req){
+               .type = VIRTIO_SCSI_T_TMF,
+               .subtype = VIRTIO_SCSI_T_TMF_ABORT_TASK,
index 6e4178619669894fff9f11304559824c3334462f..01b8d4b7c722db46b890ed2b9b122b101a0a98d7 100644 (file)
@@ -52,3 +52,21 @@ cifs-fix-read-after-write-for-files-with-read-caching.patch
 tracing-use-strncpy-instead-of-memcpy-for-string-keys-in-hist-triggers.patch
 tracing-do-not-free-iter-trace-in-fail-path-of-tracing_open_pipe.patch
 acpi-device_sysfs-avoid-of-modalias-creation-for-removed-device.patch
+spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch
+spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch
+regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch
+regulator-max77620-initialize-values-for-dt-properties.patch
+regulator-s2mpa01-fix-step-values-for-some-ldos.patch
+clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch
+clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch
+s390-virtio-handle-find-on-invalid-queue-gracefully.patch
+scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
+scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch
+scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
+fs-devpts-always-delete-dcache-dentry-s-in-dput.patch
+splice-don-t-merge-into-linked-buffers.patch
+m68k-add-ffreestanding-to-cflags.patch
+btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch
+btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
+btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch
+crypto-pcbc-remove-bogus-memcpy-s-with-src-dest.patch
diff --git a/queue-4.9/spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch b/queue-4.9/spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch
new file mode 100644 (file)
index 0000000..c5b6cc0
--- /dev/null
@@ -0,0 +1,43 @@
+From ef070b4e4aa25bb5f8632ad196644026c11903bf Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Tue, 19 Feb 2019 23:21:28 +0300
+Subject: spi: pxa2xx: Setup maximum supported DMA transfer length
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit ef070b4e4aa25bb5f8632ad196644026c11903bf upstream.
+
+When the commit b6ced294fb61
+
+   ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
+
+switches to SPI core provided DMA helpers, it missed to setup maximum
+supported DMA transfer length for the controller and thus users
+mistakenly try to send more data than supported with the following
+warning:
+
+  ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
+
+Setup maximum supported DMA transfer length in order to make users know
+the limit.
+
+Fixes: b6ced294fb61 ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-pxa2xx.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -1668,6 +1668,7 @@ static int pxa2xx_spi_probe(struct platf
+                       platform_info->enable_dma = false;
+               } else {
+                       master->can_dma = pxa2xx_spi_can_dma;
++                      master->max_dma_len = MAX_DMA_LEN;
+               }
+       }
diff --git a/queue-4.9/spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch b/queue-4.9/spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch
new file mode 100644 (file)
index 0000000..bd5e1c7
--- /dev/null
@@ -0,0 +1,48 @@
+From 673c865efbdc5fec3cc525c46d71844d42c60072 Mon Sep 17 00:00:00 2001
+From: Vignesh R <vigneshr@ti.com>
+Date: Tue, 29 Jan 2019 13:14:22 +0530
+Subject: spi: ti-qspi: Fix mmap read when more than one CS in use
+
+From: Vignesh R <vigneshr@ti.com>
+
+commit 673c865efbdc5fec3cc525c46d71844d42c60072 upstream.
+
+Commit 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support") has
+has got order of parameter wrong when calling regmap_update_bits() to
+select CS for mmap access. Mask and value arguments are interchanged.
+Code will work on a system with single slave, but fails when more than
+one CS is in use. Fix this by correcting the order of parameters when
+calling regmap_update_bits().
+
+Fixes: 4dea6c9b0b64 ("spi: spi-ti-qspi: add mmap mode read support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vignesh R <vigneshr@ti.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-ti-qspi.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/spi/spi-ti-qspi.c
++++ b/drivers/spi/spi-ti-qspi.c
+@@ -457,8 +457,8 @@ static void ti_qspi_enable_memory_map(st
+       ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+       if (qspi->ctrl_base) {
+               regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+-                                 MEM_CS_EN(spi->chip_select),
+-                                 MEM_CS_MASK);
++                                 MEM_CS_MASK,
++                                 MEM_CS_EN(spi->chip_select));
+       }
+       qspi->mmap_enabled = true;
+ }
+@@ -470,7 +470,7 @@ static void ti_qspi_disable_memory_map(s
+       ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+       if (qspi->ctrl_base)
+               regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+-                                 0, MEM_CS_MASK);
++                                 MEM_CS_MASK, 0);
+       qspi->mmap_enabled = false;
+ }
diff --git a/queue-4.9/splice-don-t-merge-into-linked-buffers.patch b/queue-4.9/splice-don-t-merge-into-linked-buffers.patch
new file mode 100644 (file)
index 0000000..6752c2f
--- /dev/null
@@ -0,0 +1,113 @@
+From a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 23 Jan 2019 15:19:17 +0100
+Subject: splice: don't merge into linked buffers
+
+From: Jann Horn <jannh@google.com>
+
+commit a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 upstream.
+
+Before this patch, it was possible for two pipes to affect each other after
+data had been transferred between them with tee():
+
+============
+$ cat tee_test.c
+
+int main(void) {
+  int pipe_a[2];
+  if (pipe(pipe_a)) err(1, "pipe");
+  int pipe_b[2];
+  if (pipe(pipe_b)) err(1, "pipe");
+  if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
+  if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
+  if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
+
+  char buf[5];
+  if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
+  buf[4] = 0;
+  printf("got back: '%s'\n", buf);
+}
+$ gcc -o tee_test tee_test.c
+$ ./tee_test
+got back: 'abxx'
+$
+============
+
+As suggested by Al Viro, fix it by creating a separate type for
+non-mergeable pipe buffers, then changing the types of buffers in
+splice_pipe_to_pipe() and link_pipe().
+
+Cc: <stable@vger.kernel.org>
+Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
+Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
+Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pipe.c                 |   14 ++++++++++++++
+ fs/splice.c               |    4 ++++
+ include/linux/pipe_fs_i.h |    1 +
+ 3 files changed, 19 insertions(+)
+
+--- a/fs/pipe.c
++++ b/fs/pipe.c
+@@ -238,6 +238,14 @@ static const struct pipe_buf_operations
+       .get = generic_pipe_buf_get,
+ };
++static const struct pipe_buf_operations anon_pipe_buf_nomerge_ops = {
++      .can_merge = 0,
++      .confirm = generic_pipe_buf_confirm,
++      .release = anon_pipe_buf_release,
++      .steal = anon_pipe_buf_steal,
++      .get = generic_pipe_buf_get,
++};
++
+ static const struct pipe_buf_operations packet_pipe_buf_ops = {
+       .can_merge = 0,
+       .confirm = generic_pipe_buf_confirm,
+@@ -246,6 +254,12 @@ static const struct pipe_buf_operations
+       .get = generic_pipe_buf_get,
+ };
++void pipe_buf_mark_unmergeable(struct pipe_buffer *buf)
++{
++      if (buf->ops == &anon_pipe_buf_ops)
++              buf->ops = &anon_pipe_buf_nomerge_ops;
++}
++
+ static ssize_t
+ pipe_read(struct kiocb *iocb, struct iov_iter *to)
+ {
+--- a/fs/splice.c
++++ b/fs/splice.c
+@@ -1594,6 +1594,8 @@ retry:
+                        */
+                       obuf->flags &= ~PIPE_BUF_FLAG_GIFT;
++                      pipe_buf_mark_unmergeable(obuf);
++
+                       obuf->len = len;
+                       opipe->nrbufs++;
+                       ibuf->offset += obuf->len;
+@@ -1668,6 +1670,8 @@ static int link_pipe(struct pipe_inode_i
+                */
+               obuf->flags &= ~PIPE_BUF_FLAG_GIFT;
++              pipe_buf_mark_unmergeable(obuf);
++
+               if (obuf->len > len)
+                       obuf->len = len;
+--- a/include/linux/pipe_fs_i.h
++++ b/include/linux/pipe_fs_i.h
+@@ -182,6 +182,7 @@ void generic_pipe_buf_get(struct pipe_in
+ int generic_pipe_buf_confirm(struct pipe_inode_info *, struct pipe_buffer *);
+ int generic_pipe_buf_steal(struct pipe_inode_info *, struct pipe_buffer *);
+ void generic_pipe_buf_release(struct pipe_inode_info *, struct pipe_buffer *);
++void pipe_buf_mark_unmergeable(struct pipe_buffer *buf);
+ extern const struct pipe_buf_operations nosteal_pipe_buf_ops;