From: Greg Kroah-Hartman Date: Wed, 20 Mar 2019 18:07:32 +0000 (+0100) Subject: 4.19-stable patches X-Git-Tag: v3.18.137~63 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=df1bfe5fd751884512f88aa7ad373c15bfbc0523;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: btrfs-drop-the-lock-on-error-in-btrfs_dev_replace_cancel.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 btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch btrfs-setup-a-nofs-context-for-memory-allocation-at-btrfs_create_tree.patch clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.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 fs-devpts-always-delete-dcache-dentry-s-in-dput.patch m68k-add-ffreestanding-to-cflags.patch mmc-fix-a-bug-when-max_discard-is-0.patch mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch netfilter-ipt_clusterip-fix-warning-unused-variable-cn.patch ovl-do-not-lose-security.capability-xattr-over-metadata-file-copy-up.patch ovl-during-copy-up-first-copy-up-data-and-then-xattrs.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-setup-fix-early-warning-messages.patch s390-virtio-handle-find-on-invalid-queue-gracefully.patch scsi-aacraid-fix-performance-issue-on-logical-drives.patch scsi-qla2xxx-fix-lun-discovery-if-loop-id-is-not-assigned-yet-by-firmware.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 virtio-blk-consider-virtio_max_dma_size-for-maximum-segment-size.patch virtio-introduce-virtio_max_dma_size.patch --- diff --git a/queue-4.19/btrfs-drop-the-lock-on-error-in-btrfs_dev_replace_cancel.patch b/queue-4.19/btrfs-drop-the-lock-on-error-in-btrfs_dev_replace_cancel.patch new file mode 100644 index 00000000000..0200aafe4f3 --- /dev/null +++ b/queue-4.19/btrfs-drop-the-lock-on-error-in-btrfs_dev_replace_cancel.patch @@ -0,0 +1,39 @@ +From 669e859b5ea7c6f4fce0149d3907c64e550c294b Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 11 Feb 2019 21:32:10 +0300 +Subject: btrfs: drop the lock on error in btrfs_dev_replace_cancel + +From: Dan Carpenter + +commit 669e859b5ea7c6f4fce0149d3907c64e550c294b upstream. + +We should drop the lock on this error path. This has been found by a +static tool. + +The lock needs to be released, it's there to protect access to the +dev_replace members and is not supposed to be left locked. The value of +state that's being switched would need to be artifically changed to an +invalid value so the default: branch is taken. + +Fixes: d189dd70e255 ("btrfs: fix use-after-free due to race between replace start and cancel") +CC: stable@vger.kernel.org # 5.0+ +Reviewed-by: Anand Jain +Signed-off-by: Dan Carpenter +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/dev-replace.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/btrfs/dev-replace.c ++++ b/fs/btrfs/dev-replace.c +@@ -849,6 +849,7 @@ int btrfs_dev_replace_cancel(struct btrf + btrfs_destroy_dev_replace_tgtdev(tgt_device); + break; + default: ++ up_write(&dev_replace->rwsem); + result = -EINVAL; + } + diff --git a/queue-4.19/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch b/queue-4.19/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch new file mode 100644 index 00000000000..6789b5c2a19 --- /dev/null +++ b/queue-4.19/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch @@ -0,0 +1,55 @@ +From 349ae63f40638a28c6fce52e8447c2d14b84cc0c Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +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 + +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 +Reviewed-by: Nikolay Borisov +Signed-off-by: Johannes Thumshirn +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/volumes.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -6425,10 +6425,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(fs_info, diff --git a/queue-4.19/btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch b/queue-4.19/btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch new file mode 100644 index 00000000000..1235f408473 --- /dev/null +++ b/queue-4.19/btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch @@ -0,0 +1,118 @@ +From 8e928218780e2f1cf2f5891c7575e8f0b284fcce Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 14 Feb 2019 15:17:20 +0000 +Subject: Btrfs: fix corruption reading shared and compressed extents after hole punching + +From: Filipe Manana + +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 +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 +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -3002,11 +3002,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.19/btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch b/queue-4.19/btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch new file mode 100644 index 00000000000..5f527bb87a6 --- /dev/null +++ b/queue-4.19/btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch @@ -0,0 +1,52 @@ +From a0873490660246db587849a9e172f2b7b21fa88a Mon Sep 17 00:00:00 2001 +From: Filipe Manana +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 + +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 +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/acl.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/fs/btrfs/acl.c ++++ b/fs/btrfs/acl.c +@@ -9,6 +9,7 @@ + #include + #include + #include ++#include + #include + + #include "ctree.h" +@@ -72,8 +73,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.19/btrfs-setup-a-nofs-context-for-memory-allocation-at-btrfs_create_tree.patch b/queue-4.19/btrfs-setup-a-nofs-context-for-memory-allocation-at-btrfs_create_tree.patch new file mode 100644 index 00000000000..2d5d11d8f92 --- /dev/null +++ b/queue-4.19/btrfs-setup-a-nofs-context-for-memory-allocation-at-btrfs_create_tree.patch @@ -0,0 +1,53 @@ +From b89f6d1fcb30a8cbdc18ce00c7d93792076af453 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 13 Dec 2018 21:16:45 +0000 +Subject: Btrfs: setup a nofs context for memory allocation at btrfs_create_tree() + +From: Filipe Manana + +commit b89f6d1fcb30a8cbdc18ce00c7d93792076af453 upstream. + +We are holding a transaction handle when creating a tree, therefore we can +not allocate the root using GFP_KERNEL, as we could deadlock if reclaim is +triggered by the allocation, therefore setup a nofs context. + +Fixes: 74e4d82757f74 ("btrfs: let callers of btrfs_alloc_root pass gfp flags") +CC: stable@vger.kernel.org # 4.9+ +Reviewed-by: Nikolay Borisov +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/disk-io.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -17,6 +17,7 @@ + #include + #include + #include ++#include + #include + #include "ctree.h" + #include "disk-io.h" +@@ -1236,10 +1237,17 @@ struct btrfs_root *btrfs_create_tree(str + struct btrfs_root *tree_root = fs_info->tree_root; + struct btrfs_root *root; + struct btrfs_key key; ++ unsigned int nofs_flag; + int ret = 0; + uuid_le uuid = NULL_UUID_LE; + ++ /* ++ * We're holding a transaction handle, so use a NOFS memory allocation ++ * context to avoid deadlock if reclaim happens. ++ */ ++ nofs_flag = memalloc_nofs_save(); + root = btrfs_alloc_root(fs_info, GFP_KERNEL); ++ memalloc_nofs_restore(nofs_flag); + if (!root) + return ERR_PTR(-ENOMEM); + diff --git a/queue-4.19/clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch b/queue-4.19/clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch new file mode 100644 index 00000000000..3857e78596e --- /dev/null +++ b/queue-4.19/clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch @@ -0,0 +1,249 @@ +From c950ca8c35eeb32224a63adc47e12f9e226da241 Mon Sep 17 00:00:00 2001 +From: Samuel Holland +Date: Sat, 12 Jan 2019 20:17:18 -0600 +Subject: clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Samuel Holland + +commit c950ca8c35eeb32224a63adc47e12f9e226da241 upstream. + +The Allwinner A64 SoC is known[1] to have an unstable architectural +timer, which manifests itself most obviously in the time jumping forward +a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a +timer frequency of 24 MHz, implying that the time went slightly backward +(and this was interpreted by the kernel as it jumping forward and +wrapping around past the epoch). + +Investigation revealed instability in the low bits of CNTVCT at the +point a high bit rolls over. This leads to power-of-two cycle forward +and backward jumps. (Testing shows that forward jumps are about twice as +likely as backward jumps.) Since the counter value returns to normal +after an indeterminate read, each "jump" really consists of both a +forward and backward jump from the software perspective. + +Unless the kernel is trapping CNTVCT reads, a userspace program is able +to read the register in a loop faster than it changes. A test program +running on all 4 CPU cores that reported jumps larger than 100 ms was +run for 13.6 hours and reported the following: + + Count | Event +-------+--------------------------- + 9940 | jumped backward 699ms + 268 | jumped backward 1398ms + 1 | jumped backward 2097ms + 16020 | jumped forward 175ms + 6443 | jumped forward 699ms + 2976 | jumped forward 1398ms + 9 | jumped forward 356516ms + 9 | jumped forward 357215ms + 4 | jumped forward 714430ms + 1 | jumped forward 3578440ms + +This works out to a jump larger than 100 ms about every 5.5 seconds on +each CPU core. + +The largest jump (almost an hour!) was the following sequence of reads: + 0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000 + +Note that the middle bits don't necessarily all read as all zeroes or +all ones during the anomalous behavior; however the low 10 bits checked +by the function in this patch have never been observed with any other +value. + +Also note that smaller jumps are much more common, with backward jumps +of 2048 (2^11) cycles observed over 400 times per second on each core. +(Of course, this is partially explained by lower bits rolling over more +frequently.) Any one of these could have caused the 95 year time skip. + +Similar anomalies were observed while reading CNTPCT (after patching the +kernel to allow reads from userspace). However, the CNTPCT jumps are +much less frequent, and only small jumps were observed. The same program +as before (except now reading CNTPCT) observed after 72 hours: + + Count | Event +-------+--------------------------- + 17 | jumped backward 699ms + 52 | jumped forward 175ms + 2831 | jumped forward 699ms + 5 | jumped forward 1398ms + +Further investigation showed that the instability in CNTPCT/CNTVCT also +affected the respective timer's TVAL register. The following values were +observed immediately after writing CNVT_TVAL to 0x10000000: + + CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error +--------------------+------------+--------------------+----------------- + 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000 + 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000 + 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000 + 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000 + +The pattern of errors in CNTV_TVAL seemed to depend on exactly which +value was written to it. For example, after writing 0x10101010: + + CNTVCT | CNTV_TVAL | CNTV_CVAL | CNTV_TVAL Error +--------------------+------------+--------------------+----------------- + 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000 + 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000 + 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000 + 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000 + 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000 + 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000 + +I was also twice able to reproduce the issue covered by Allwinner's +workaround[4], that writing to TVAL sometimes fails, and both CVAL and +TVAL are left with entirely bogus values. One was the following values: + + CNTVCT | CNTV_TVAL | CNTV_CVAL +--------------------+------------+-------------------------------------- + 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past) +Reviewed-by: Marc Zyngier + +======================================================================== + +Because the CPU can read the CNTPCT/CNTVCT registers faster than they +change, performing two reads of the register and comparing the high bits +(like other workarounds) is not a workable solution. And because the +timer can jump both forward and backward, no pair of reads can +distinguish a good value from a bad one. The only way to guarantee a +good value from consecutive reads would be to read _three_ times, and +take the middle value only if the three values are 1) each unique and +2) increasing. This takes at minimum 3 counter cycles (125 ns), or more +if an anomaly is detected. + +However, since there is a distinct pattern to the bad values, we can +optimize the common case (1022/1024 of the time) to a single read by +simply ignoring values that match the error pattern. This still takes no +more than 3 cycles in the worst case, and requires much less code. As an +additional safety check, we still limit the loop iteration to the number +of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods. + +For the TVAL registers, the simple solution is to not use them. Instead, +read or write the CVAL and calculate the TVAL value in software. + +Although the manufacturer is aware of at least part of the erratum[4], +there is no official name for it. For now, use the kernel-internal name +"UNKNOWN1". + +[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9 +[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/ +[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26 +[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272 + +Acked-by: Maxime Ripard +Tested-by: Andre Przywara +Signed-off-by: Samuel Holland +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Lezcano +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/arm64/silicon-errata.txt | 2 + + drivers/clocksource/Kconfig | 10 ++++++ + drivers/clocksource/arm_arch_timer.c | 55 +++++++++++++++++++++++++++++++++ + 3 files changed, 67 insertions(+) + +--- a/Documentation/arm64/silicon-errata.txt ++++ b/Documentation/arm64/silicon-errata.txt +@@ -44,6 +44,8 @@ stable kernels. + + | Implementor | Component | Erratum ID | Kconfig | + +----------------+-----------------+-----------------+-----------------------------+ ++| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | ++| | | | | + | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | + | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | + | ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +--- a/drivers/clocksource/Kconfig ++++ b/drivers/clocksource/Kconfig +@@ -365,6 +365,16 @@ config ARM64_ERRATUM_858921 + The workaround will be dynamically enabled when an affected + core is detected. + ++config SUN50I_ERRATUM_UNKNOWN1 ++ bool "Workaround for Allwinner A64 erratum UNKNOWN1" ++ default y ++ depends on ARM_ARCH_TIMER && ARM64 && ARCH_SUNXI ++ select ARM_ARCH_TIMER_OOL_WORKAROUND ++ help ++ This option enables a workaround for instability in the timer on ++ the Allwinner A64 SoC. The workaround will only be active if the ++ allwinner,erratum-unknown1 property is found in the timer node. ++ + config ARM_GLOBAL_TIMER + bool "Support for the ARM global timer" if COMPILE_TEST + select TIMER_OF if OF +--- a/drivers/clocksource/arm_arch_timer.c ++++ b/drivers/clocksource/arm_arch_timer.c +@@ -319,6 +319,48 @@ static u64 notrace arm64_858921_read_cnt + } + #endif + ++#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1 ++/* ++ * The low bits of the counter registers are indeterminate while bit 10 or ++ * greater is rolling over. Since the counter value can jump both backward ++ * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), ignore register values ++ * with all ones or all zeros in the low bits. Bound the loop by the maximum ++ * number of CPU cycles in 3 consecutive 24 MHz counter periods. ++ */ ++#define __sun50i_a64_read_reg(reg) ({ \ ++ u64 _val; \ ++ int _retries = 150; \ ++ \ ++ do { \ ++ _val = read_sysreg(reg); \ ++ _retries--; \ ++ } while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries); \ ++ \ ++ WARN_ON_ONCE(!_retries); \ ++ _val; \ ++}) ++ ++static u64 notrace sun50i_a64_read_cntpct_el0(void) ++{ ++ return __sun50i_a64_read_reg(cntpct_el0); ++} ++ ++static u64 notrace sun50i_a64_read_cntvct_el0(void) ++{ ++ return __sun50i_a64_read_reg(cntvct_el0); ++} ++ ++static u32 notrace sun50i_a64_read_cntp_tval_el0(void) ++{ ++ return read_sysreg(cntp_cval_el0) - sun50i_a64_read_cntpct_el0(); ++} ++ ++static u32 notrace sun50i_a64_read_cntv_tval_el0(void) ++{ ++ return read_sysreg(cntv_cval_el0) - sun50i_a64_read_cntvct_el0(); ++} ++#endif ++ + #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND + DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *, timer_unstable_counter_workaround); + EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround); +@@ -408,6 +450,19 @@ static const struct arch_timer_erratum_w + .read_cntvct_el0 = arm64_858921_read_cntvct_el0, + }, + #endif ++#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1 ++ { ++ .match_type = ate_match_dt, ++ .id = "allwinner,erratum-unknown1", ++ .desc = "Allwinner erratum UNKNOWN1", ++ .read_cntp_tval_el0 = sun50i_a64_read_cntp_tval_el0, ++ .read_cntv_tval_el0 = sun50i_a64_read_cntv_tval_el0, ++ .read_cntpct_el0 = sun50i_a64_read_cntpct_el0, ++ .read_cntvct_el0 = sun50i_a64_read_cntvct_el0, ++ .set_next_event_phys = erratum_set_next_event_tval_phys, ++ .set_next_event_virt = erratum_set_next_event_tval_virt, ++ }, ++#endif + }; + + typedef bool (*ate_match_fn_t)(const struct arch_timer_erratum_workaround *, diff --git a/queue-4.19/clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch b/queue-4.19/clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch new file mode 100644 index 00000000000..cdbaed3e545 --- /dev/null +++ b/queue-4.19/clocksource-drivers-exynos_mct-clear-timer-interrupt-when-shutdown.patch @@ -0,0 +1,36 @@ +From d2f276c8d3c224d5b493c42b6cf006ae4e64fb1c Mon Sep 17 00:00:00 2001 +From: Stuart Menefy +Date: Sun, 10 Feb 2019 22:51:14 +0000 +Subject: clocksource/drivers/exynos_mct: Clear timer interrupt when shutdown + +From: Stuart Menefy + +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 +Reviewed-by: Krzysztof Kozlowski +Tested-by: Marek Szyprowski +Cc: # v4.3+ +Signed-off-by: Daniel Lezcano +Signed-off-by: Greg Kroah-Hartman + +--- + 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.19/clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch b/queue-4.19/clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch new file mode 100644 index 00000000000..4440582b2f2 --- /dev/null +++ b/queue-4.19/clocksource-drivers-exynos_mct-move-one-shot-check-from-tick-clear-to-isr.patch @@ -0,0 +1,73 @@ +From a5719a40aef956ba704f2aa1c7b977224d60fa96 Mon Sep 17 00:00:00 2001 +From: Stuart Menefy +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 + +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 +Reviewed-by: Krzysztof Kozlowski +Tested-by: Marek Szyprowski +Cc: stable@vger.kernel.org # v4.3+ +Signed-off-by: Daniel Lezcano +Signed-off-by: Greg Kroah-Hartman + +--- + 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.19/fs-devpts-always-delete-dcache-dentry-s-in-dput.patch b/queue-4.19/fs-devpts-always-delete-dcache-dentry-s-in-dput.patch new file mode 100644 index 00000000000..344e30a5634 --- /dev/null +++ b/queue-4.19/fs-devpts-always-delete-dcache-dentry-s-in-dput.patch @@ -0,0 +1,80 @@ +From 73052b0daee0b750b39af18460dfec683e4f5887 Mon Sep 17 00:00:00 2001 +From: Varad Gautam +Date: Thu, 24 Jan 2019 14:03:06 +0100 +Subject: fs/devpts: always delete dcache dentry-s in dput() + +From: Varad Gautam + +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 +Reported-by: Zheng Wang +Reported-by: Brandon Schwartz +Root-caused-by: Maximilian Heyne +Root-caused-by: Nicolas Pernas Maradei +CC: David Woodhouse +CC: Maximilian Heyne +CC: Stefan Nuernberger +CC: Amit Shah +CC: Linus Torvalds +CC: Greg Kroah-Hartman +CC: Al Viro +CC: Christian Brauner +CC: Eric W. Biederman +CC: Matthew Wilcox +CC: Eric Biggers +CC: # 4.9+ +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + fs/devpts/inode.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/devpts/inode.c ++++ b/fs/devpts/inode.c +@@ -455,6 +455,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.19/m68k-add-ffreestanding-to-cflags.patch b/queue-4.19/m68k-add-ffreestanding-to-cflags.patch new file mode 100644 index 00000000000..ac8bdc15105 --- /dev/null +++ b/queue-4.19/m68k-add-ffreestanding-to-cflags.patch @@ -0,0 +1,55 @@ +From 28713169d879b67be2ef2f84dcf54905de238294 Mon Sep 17 00:00:00 2001 +From: Finn Thain +Date: Wed, 16 Jan 2019 16:23:24 +1100 +Subject: m68k: Add -ffreestanding to CFLAGS + +From: Finn Thain + +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 +Signed-off-by: Geert Uytterhoeven +Signed-off-by: Greg Kroah-Hartman + +--- + 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.19/mmc-fix-a-bug-when-max_discard-is-0.patch b/queue-4.19/mmc-fix-a-bug-when-max_discard-is-0.patch new file mode 100644 index 00000000000..32865d295ee --- /dev/null +++ b/queue-4.19/mmc-fix-a-bug-when-max_discard-is-0.patch @@ -0,0 +1,49 @@ +From d4721339dcca7def04909a8e60da43c19a24d8bf Mon Sep 17 00:00:00 2001 +From: Jiong Wu +Date: Fri, 1 Mar 2019 00:18:33 +0800 +Subject: mmc:fix a bug when max_discard is 0 + +From: Jiong Wu + +commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream. + +The original purpose of the code I fix is to replace max_discard with +max_trim if max_trim is less than max_discard. When max_discard is 0 +we should replace max_discard with max_trim as well, because +max_discard equals 0 happens only when the max_do_calc_max_discard +process is overflowed, so if mmc_can_trim(card) is true, max_discard +should be replaced by an available max_trim. +However, in the original code, there are two lines of code interfere +the right process. +1) if (max_discard && mmc_can_trim(card)) +when max_discard is 0, it skips the process checking if max_discard +needs to be replaced with max_trim. +2) if (max_trim < max_discard) +the condition is false when max_discard is 0. it also skips the process +that replaces max_discard with max_trim, in fact, we should replace the +0-valued max_discard with max_trim. + +Signed-off-by: Jiong Wu +Fixes: b305882fbc87 (mmc: core: optimize mmc_calc_max_discard) +Cc: stable@vger.kernel.org # v4.17+ +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/core/core.c ++++ b/drivers/mmc/core/core.c +@@ -2378,9 +2378,9 @@ unsigned int mmc_calc_max_discard(struct + return card->pref_erase; + + max_discard = mmc_do_calc_max_discard(card, MMC_ERASE_ARG); +- if (max_discard && mmc_can_trim(card)) { ++ if (mmc_can_trim(card)) { + max_trim = mmc_do_calc_max_discard(card, MMC_TRIM_ARG); +- if (max_trim < max_discard) ++ if (max_trim < max_discard || max_discard == 0) + max_discard = max_trim; + } else if (max_discard < card->erase_size) { + max_discard = 0; diff --git a/queue-4.19/mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch b/queue-4.19/mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch new file mode 100644 index 00000000000..a0cf1487181 --- /dev/null +++ b/queue-4.19/mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch @@ -0,0 +1,39 @@ +From de0a0decf2edfc5b0c782915f4120cf990a9bd13 Mon Sep 17 00:00:00 2001 +From: BOUGH CHEN +Date: Thu, 27 Dec 2018 11:20:24 +0000 +Subject: mmc: sdhci-esdhc-imx: fix HS400 timing issue + +From: BOUGH CHEN + +commit de0a0decf2edfc5b0c782915f4120cf990a9bd13 upstream. + +Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/ +MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS, +we can not do tuning reset, otherwise HS400 timing is not right. + +Here is the process of init HS400, first finish tuning in HS200 mode, +then switch to HS mode and 8 bit DDR mode, finally switch to HS400 +mode. If we do tuning reset in HS mode, this will cause HS400 mode +lost the tuning setting, which will cause CRC error. + +Signed-off-by: Haibo Chen +Cc: stable@vger.kernel.org # v4.12+ +Acked-by: Adrian Hunter +Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card") +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-esdhc-imx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mmc/host/sdhci-esdhc-imx.c ++++ b/drivers/mmc/host/sdhci-esdhc-imx.c +@@ -981,6 +981,7 @@ static void esdhc_set_uhs_signaling(stru + case MMC_TIMING_UHS_SDR25: + case MMC_TIMING_UHS_SDR50: + case MMC_TIMING_UHS_SDR104: ++ case MMC_TIMING_MMC_HS: + case MMC_TIMING_MMC_HS200: + writel(m, host->ioaddr + ESDHC_MIX_CTRL); + break; diff --git a/queue-4.19/netfilter-ipt_clusterip-fix-warning-unused-variable-cn.patch b/queue-4.19/netfilter-ipt_clusterip-fix-warning-unused-variable-cn.patch new file mode 100644 index 00000000000..e0f2a47c1a8 --- /dev/null +++ b/queue-4.19/netfilter-ipt_clusterip-fix-warning-unused-variable-cn.patch @@ -0,0 +1,43 @@ +From 206b8cc514d7ff2b79dd2d5ad939adc7c493f07a Mon Sep 17 00:00:00 2001 +From: Anders Roxell +Date: Wed, 23 Jan 2019 12:48:11 +0100 +Subject: netfilter: ipt_CLUSTERIP: fix warning unused variable cn +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Anders Roxell + +commit 206b8cc514d7ff2b79dd2d5ad939adc7c493f07a upstream. + +When CONFIG_PROC_FS isn't set the variable cn isn't used. + +net/ipv4/netfilter/ipt_CLUSTERIP.c: In function ‘clusterip_net_exit’: +net/ipv4/netfilter/ipt_CLUSTERIP.c:849:24: warning: unused variable ‘cn’ [-Wunused-variable] + struct clusterip_net *cn = clusterip_pernet(net); + ^~ + +Rework so the variable 'cn' is declared inside "#ifdef CONFIG_PROC_FS". + +Fixes: b12f7bad5ad3 ("netfilter: ipt_CLUSTERIP: remove wrong WARN_ON_ONCE in netns exit routine") +Signed-off-by: Anders Roxell +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Greg Kroah-Hartman + +--- + net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c ++++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c +@@ -846,9 +846,9 @@ static int clusterip_net_init(struct net + + static void clusterip_net_exit(struct net *net) + { ++#ifdef CONFIG_PROC_FS + struct clusterip_net *cn = clusterip_pernet(net); + +-#ifdef CONFIG_PROC_FS + mutex_lock(&cn->mutex); + proc_remove(cn->procdir); + cn->procdir = NULL; diff --git a/queue-4.19/ovl-do-not-lose-security.capability-xattr-over-metadata-file-copy-up.patch b/queue-4.19/ovl-do-not-lose-security.capability-xattr-over-metadata-file-copy-up.patch new file mode 100644 index 00000000000..91fd0942fb1 --- /dev/null +++ b/queue-4.19/ovl-do-not-lose-security.capability-xattr-over-metadata-file-copy-up.patch @@ -0,0 +1,175 @@ +From 993a0b2aec52754f0897b1dab4c453be8217cae5 Mon Sep 17 00:00:00 2001 +From: Vivek Goyal +Date: Wed, 30 Jan 2019 14:01:57 -0500 +Subject: ovl: Do not lose security.capability xattr over metadata file copy-up + +From: Vivek Goyal + +commit 993a0b2aec52754f0897b1dab4c453be8217cae5 upstream. + +If a file has been copied up metadata only, and later data is copied up, +upper loses any security.capability xattr it has (underlying filesystem +clears it as upon file write). + +From a user's point of view, this is just a file copy-up and that should +not result in losing security.capability xattr. Hence, before data copy +up, save security.capability xattr (if any) and restore it on upper after +data copy up is complete. + +Signed-off-by: Vivek Goyal +Reviewed-by: Amir Goldstein +Fixes: 0c2888749363 ("ovl: A new xattr OVL_XATTR_METACOPY for file on upper") +Cc: # v4.19+ +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/overlayfs/copy_up.c | 28 ++++++++++++++++++++++- + fs/overlayfs/overlayfs.h | 2 + + fs/overlayfs/util.c | 55 +++++++++++++++++++++++++++++------------------ + 3 files changed, 63 insertions(+), 22 deletions(-) + +--- a/fs/overlayfs/copy_up.c ++++ b/fs/overlayfs/copy_up.c +@@ -711,6 +711,8 @@ static int ovl_copy_up_meta_inode_data(s + { + struct path upperpath, datapath; + int err; ++ char *capability = NULL; ++ ssize_t uninitialized_var(cap_size); + + ovl_path_upper(c->dentry, &upperpath); + if (WARN_ON(upperpath.dentry == NULL)) +@@ -720,15 +722,37 @@ static int ovl_copy_up_meta_inode_data(s + if (WARN_ON(datapath.dentry == NULL)) + return -EIO; + ++ if (c->stat.size) { ++ err = cap_size = ovl_getxattr(upperpath.dentry, XATTR_NAME_CAPS, ++ &capability, 0); ++ if (err < 0 && err != -ENODATA) ++ goto out; ++ } ++ + err = ovl_copy_up_data(&datapath, &upperpath, c->stat.size); + if (err) +- return err; ++ goto out_free; ++ ++ /* ++ * Writing to upper file will clear security.capability xattr. We ++ * don't want that to happen for normal copy-up operation. ++ */ ++ if (capability) { ++ err = ovl_do_setxattr(upperpath.dentry, XATTR_NAME_CAPS, ++ capability, cap_size, 0); ++ if (err) ++ goto out_free; ++ } ++ + + err = vfs_removexattr(upperpath.dentry, OVL_XATTR_METACOPY); + if (err) +- return err; ++ goto out_free; + + ovl_set_upperdata(d_inode(c->dentry)); ++out_free: ++ kfree(capability); ++out: + return err; + } + +--- a/fs/overlayfs/overlayfs.h ++++ b/fs/overlayfs/overlayfs.h +@@ -277,6 +277,8 @@ int ovl_lock_rename_workdir(struct dentr + int ovl_check_metacopy_xattr(struct dentry *dentry); + bool ovl_is_metacopy_dentry(struct dentry *dentry); + char *ovl_get_redirect_xattr(struct dentry *dentry, int padding); ++ssize_t ovl_getxattr(struct dentry *dentry, char *name, char **value, ++ size_t padding); + + static inline bool ovl_is_impuredir(struct dentry *dentry) + { +--- a/fs/overlayfs/util.c ++++ b/fs/overlayfs/util.c +@@ -867,28 +867,49 @@ bool ovl_is_metacopy_dentry(struct dentr + return (oe->numlower > 1); + } + +-char *ovl_get_redirect_xattr(struct dentry *dentry, int padding) ++ssize_t ovl_getxattr(struct dentry *dentry, char *name, char **value, ++ size_t padding) + { +- int res; +- char *s, *next, *buf = NULL; ++ ssize_t res; ++ char *buf = NULL; + +- res = vfs_getxattr(dentry, OVL_XATTR_REDIRECT, NULL, 0); ++ res = vfs_getxattr(dentry, name, NULL, 0); + if (res < 0) { + if (res == -ENODATA || res == -EOPNOTSUPP) +- return NULL; ++ return -ENODATA; + goto fail; + } + +- buf = kzalloc(res + padding + 1, GFP_KERNEL); +- if (!buf) +- return ERR_PTR(-ENOMEM); ++ if (res != 0) { ++ buf = kzalloc(res + padding, GFP_KERNEL); ++ if (!buf) ++ return -ENOMEM; ++ ++ res = vfs_getxattr(dentry, name, buf, res); ++ if (res < 0) ++ goto fail; ++ } ++ *value = buf; + +- if (res == 0) +- goto invalid; ++ return res; ++ ++fail: ++ pr_warn_ratelimited("overlayfs: failed to get xattr %s: err=%zi)\n", ++ name, res); ++ kfree(buf); ++ return res; ++} ++ ++char *ovl_get_redirect_xattr(struct dentry *dentry, int padding) ++{ ++ int res; ++ char *s, *next, *buf = NULL; + +- res = vfs_getxattr(dentry, OVL_XATTR_REDIRECT, buf, res); ++ res = ovl_getxattr(dentry, OVL_XATTR_REDIRECT, &buf, padding + 1); ++ if (res == -ENODATA) ++ return NULL; + if (res < 0) +- goto fail; ++ return ERR_PTR(res); + if (res == 0) + goto invalid; + +@@ -904,15 +925,9 @@ char *ovl_get_redirect_xattr(struct dent + } + + return buf; +- +-err_free: +- kfree(buf); +- return ERR_PTR(res); +-fail: +- pr_warn_ratelimited("overlayfs: failed to get redirect (%i)\n", res); +- goto err_free; + invalid: + pr_warn_ratelimited("overlayfs: invalid redirect (%s)\n", buf); + res = -EINVAL; +- goto err_free; ++ kfree(buf); ++ return ERR_PTR(res); + } diff --git a/queue-4.19/ovl-during-copy-up-first-copy-up-data-and-then-xattrs.patch b/queue-4.19/ovl-during-copy-up-first-copy-up-data-and-then-xattrs.patch new file mode 100644 index 00000000000..ed428c3eb66 --- /dev/null +++ b/queue-4.19/ovl-during-copy-up-first-copy-up-data-and-then-xattrs.patch @@ -0,0 +1,90 @@ +From 5f32879ea35523b9842bdbdc0065e13635caada2 Mon Sep 17 00:00:00 2001 +From: Vivek Goyal +Date: Fri, 11 Jan 2019 19:37:00 +0100 +Subject: ovl: During copy up, first copy up data and then xattrs + +From: Vivek Goyal + +commit 5f32879ea35523b9842bdbdc0065e13635caada2 upstream. + +If a file with capability set (and hence security.capability xattr) is +written kernel clears security.capability xattr. For overlay, during file +copy up if xattrs are copied up first and then data is, copied up. This +means data copy up will result in clearing of security.capability xattr +file on lower has. And this can result into surprises. If a lower file has +CAP_SETUID, then it should not be cleared over copy up (if nothing was +actually written to file). + +This also creates problems with chown logic where it first copies up file +and then tries to clear setuid bit. But by that time security.capability +xattr is already gone (due to data copy up), and caller gets -ENODATA. +This has been reported by Giuseppe here. + +https://github.com/containers/libpod/issues/2015#issuecomment-447824842 + +Fix this by copying up data first and then metadta. This is a regression +which has been introduced by my commit as part of metadata only copy up +patches. + +TODO: There will be some corner cases where a file is copied up metadata +only and later data copy up happens and that will clear security.capability +xattr. Something needs to be done about that too. + +Fixes: bd64e57586d3 ("ovl: During copy up, first copy up metadata and then data") +Cc: # v4.19+ +Reported-by: Giuseppe Scrivano +Signed-off-by: Vivek Goyal +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman + +--- + fs/overlayfs/copy_up.c | 31 ++++++++++++++++++------------- + 1 file changed, 18 insertions(+), 13 deletions(-) + +--- a/fs/overlayfs/copy_up.c ++++ b/fs/overlayfs/copy_up.c +@@ -501,6 +501,24 @@ static int ovl_copy_up_inode(struct ovl_ + { + int err; + ++ /* ++ * Copy up data first and then xattrs. Writing data after ++ * xattrs will remove security.capability xattr automatically. ++ */ ++ if (S_ISREG(c->stat.mode) && !c->metacopy) { ++ struct path upperpath, datapath; ++ ++ ovl_path_upper(c->dentry, &upperpath); ++ if (WARN_ON(upperpath.dentry != NULL)) ++ return -EIO; ++ upperpath.dentry = temp; ++ ++ ovl_path_lowerdata(c->dentry, &datapath); ++ err = ovl_copy_up_data(&datapath, &upperpath, c->stat.size); ++ if (err) ++ return err; ++ } ++ + err = ovl_copy_xattr(c->lowerpath.dentry, temp); + if (err) + return err; +@@ -517,19 +535,6 @@ static int ovl_copy_up_inode(struct ovl_ + if (err) + return err; + } +- +- if (S_ISREG(c->stat.mode) && !c->metacopy) { +- struct path upperpath, datapath; +- +- ovl_path_upper(c->dentry, &upperpath); +- BUG_ON(upperpath.dentry != NULL); +- upperpath.dentry = temp; +- +- ovl_path_lowerdata(c->dentry, &datapath); +- err = ovl_copy_up_data(&datapath, &upperpath, c->stat.size); +- if (err) +- return err; +- } + + if (c->metacopy) { + err = ovl_check_setxattr(c->dentry, temp, OVL_XATTR_METACOPY, diff --git a/queue-4.19/regulator-max77620-initialize-values-for-dt-properties.patch b/queue-4.19/regulator-max77620-initialize-values-for-dt-properties.patch new file mode 100644 index 00000000000..b2efdf7c267 --- /dev/null +++ b/queue-4.19/regulator-max77620-initialize-values-for-dt-properties.patch @@ -0,0 +1,50 @@ +From 0ab66b3c326ef8f77dae9f528118966365757c0c Mon Sep 17 00:00:00 2001 +From: Mark Zhang +Date: Thu, 10 Jan 2019 12:11:16 +0800 +Subject: regulator: max77620: Initialize values for DT properties + +From: Mark Zhang + +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 +Signed-off-by: Mark Zhang +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + * Laxman Dewangan +@@ -803,6 +803,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.19/regulator-s2mpa01-fix-step-values-for-some-ldos.patch b/queue-4.19/regulator-s2mpa01-fix-step-values-for-some-ldos.patch new file mode 100644 index 00000000000..4033dedd2d8 --- /dev/null +++ b/queue-4.19/regulator-s2mpa01-fix-step-values-for-some-ldos.patch @@ -0,0 +1,56 @@ +From 28c4f730d2a44f2591cb104091da29a38dac49fe Mon Sep 17 00:00:00 2001 +From: Stuart Menefy +Date: Tue, 12 Feb 2019 21:51:18 +0000 +Subject: regulator: s2mpa01: Fix step values for some LDOs + +From: Stuart Menefy + +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 +Reviewed-by: Krzysztof Kozlowski +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/regulator/s2mpa01.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/regulator/s2mpa01.c ++++ b/drivers/regulator/s2mpa01.c +@@ -298,13 +298,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), +@@ -315,11 +315,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.19/regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch b/queue-4.19/regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch new file mode 100644 index 00000000000..726ddeb0ed7 --- /dev/null +++ b/queue-4.19/regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch @@ -0,0 +1,46 @@ +From 56b5d4ea778c1b0989c5cdb5406d4a488144c416 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Sat, 9 Feb 2019 18:14:14 +0100 +Subject: regulator: s2mps11: Fix steps for buck7, buck8 and LDO35 + +From: Krzysztof Kozlowski + +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: +Fixes: cb74685ecb39 ("regulator: s2mps11: Add samsung s2mps11 regulator driver") +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/regulator/s2mps11.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/regulator/s2mps11.c ++++ b/drivers/regulator/s2mps11.c +@@ -363,7 +363,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), +@@ -373,8 +373,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.19/s390-setup-fix-early-warning-messages.patch b/queue-4.19/s390-setup-fix-early-warning-messages.patch new file mode 100644 index 00000000000..692a05ecbd5 --- /dev/null +++ b/queue-4.19/s390-setup-fix-early-warning-messages.patch @@ -0,0 +1,107 @@ +From 8727638426b0aea59d7f904ad8ddf483f9234f88 Mon Sep 17 00:00:00 2001 +From: Martin Schwidefsky +Date: Thu, 14 Feb 2019 15:40:56 +0100 +Subject: s390/setup: fix early warning messages + +From: Martin Schwidefsky + +commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream. + +The setup_lowcore() function creates a new prefix page for the boot CPU. +The PSW mask for the system_call, external interrupt, i/o interrupt and +the program check handler have the DAT bit set in this new prefix page. + +At the time setup_lowcore is called the system still runs without virtual +address translation, the paging_init() function creates the kernel page +table and loads the CR13 with the kernel ASCE. + +Any code between setup_lowcore() and the end of paging_init() that has +a BUG or WARN statement will create a program check that can not be +handled correctly as there is no kernel page table yet. + +To allow early WARN statements initially setup the lowcore with DAT off +and set the DAT bit only after paging_init() has completed. + +Cc: stable@vger.kernel.org +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kernel/setup.c | 32 +++++++++++++++++++++++--------- + 1 file changed, 23 insertions(+), 9 deletions(-) + +--- a/arch/s390/kernel/setup.c ++++ b/arch/s390/kernel/setup.c +@@ -303,7 +303,7 @@ early_param("vmalloc", parse_vmalloc); + + void *restart_stack __section(.data); + +-static void __init setup_lowcore(void) ++static void __init setup_lowcore_dat_off(void) + { + struct lowcore *lc; + +@@ -314,19 +314,16 @@ static void __init setup_lowcore(void) + lc = memblock_virt_alloc_low(sizeof(*lc), sizeof(*lc)); + lc->restart_psw.mask = PSW_KERNEL_BITS; + lc->restart_psw.addr = (unsigned long) restart_int_handler; +- lc->external_new_psw.mask = PSW_KERNEL_BITS | +- PSW_MASK_DAT | PSW_MASK_MCHECK; ++ lc->external_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK; + lc->external_new_psw.addr = (unsigned long) ext_int_handler; + lc->svc_new_psw.mask = PSW_KERNEL_BITS | +- PSW_MASK_DAT | PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK; ++ PSW_MASK_IO | PSW_MASK_EXT | PSW_MASK_MCHECK; + lc->svc_new_psw.addr = (unsigned long) system_call; +- lc->program_new_psw.mask = PSW_KERNEL_BITS | +- PSW_MASK_DAT | PSW_MASK_MCHECK; ++ lc->program_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK; + lc->program_new_psw.addr = (unsigned long) pgm_check_handler; + lc->mcck_new_psw.mask = PSW_KERNEL_BITS; + lc->mcck_new_psw.addr = (unsigned long) mcck_int_handler; +- lc->io_new_psw.mask = PSW_KERNEL_BITS | +- PSW_MASK_DAT | PSW_MASK_MCHECK; ++ lc->io_new_psw.mask = PSW_KERNEL_BITS | PSW_MASK_MCHECK; + lc->io_new_psw.addr = (unsigned long) io_int_handler; + lc->clock_comparator = clock_comparator_max; + lc->kernel_stack = ((unsigned long) &init_thread_union) +@@ -388,6 +385,17 @@ static void __init setup_lowcore(void) + lowcore_ptr[0] = lc; + } + ++static void __init setup_lowcore_dat_on(void) ++{ ++ struct lowcore *lc; ++ ++ lc = lowcore_ptr[0]; ++ lc->external_new_psw.mask |= PSW_MASK_DAT; ++ lc->svc_new_psw.mask |= PSW_MASK_DAT; ++ lc->program_new_psw.mask |= PSW_MASK_DAT; ++ lc->io_new_psw.mask |= PSW_MASK_DAT; ++} ++ + static struct resource code_resource = { + .name = "Kernel code", + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM, +@@ -946,7 +954,7 @@ void __init setup_arch(char **cmdline_p) + #endif + + setup_resources(); +- setup_lowcore(); ++ setup_lowcore_dat_off(); + smp_fill_possible_mask(); + cpu_detect_mhz_feature(); + cpu_init(); +@@ -959,6 +967,12 @@ void __init setup_arch(char **cmdline_p) + */ + paging_init(); + ++ /* ++ * After paging_init created the kernel page table, the new PSWs ++ * in lowcore can now run with DAT enabled. ++ */ ++ setup_lowcore_dat_on(); ++ + /* Setup default console */ + conmode_default(); + set_preferred_console(); diff --git a/queue-4.19/s390-virtio-handle-find-on-invalid-queue-gracefully.patch b/queue-4.19/s390-virtio-handle-find-on-invalid-queue-gracefully.patch new file mode 100644 index 00000000000..c43a4747eee --- /dev/null +++ b/queue-4.19/s390-virtio-handle-find-on-invalid-queue-gracefully.patch @@ -0,0 +1,44 @@ +From 3438b2c039b4bf26881786a1f3450f016d66ad11 Mon Sep 17 00:00:00 2001 +From: Halil Pasic +Date: Mon, 21 Jan 2019 13:19:43 +0100 +Subject: s390/virtio: handle find on invalid queue gracefully + +From: Halil Pasic + +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 +Signed-off-by: Cornelia Huck +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -272,6 +272,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); + } +@@ -413,7 +415,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.19/scsi-aacraid-fix-performance-issue-on-logical-drives.patch b/queue-4.19/scsi-aacraid-fix-performance-issue-on-logical-drives.patch new file mode 100644 index 00000000000..4dbefd9ea98 --- /dev/null +++ b/queue-4.19/scsi-aacraid-fix-performance-issue-on-logical-drives.patch @@ -0,0 +1,47 @@ +From 0015437cc046e5ec2b57b00ff8312b8d432eac7c Mon Sep 17 00:00:00 2001 +From: Sagar Biradar +Date: Thu, 7 Mar 2019 23:26:41 -0800 +Subject: scsi: aacraid: Fix performance issue on logical drives + +From: Sagar Biradar + +commit 0015437cc046e5ec2b57b00ff8312b8d432eac7c upstream. + +Fix performance issue where the queue depth for SmartIOC logical volumes is +set to 1, and allow the usual logical volume code to be executed + +Fixes: a052865fe287 (aacraid: Set correct Queue Depth for HBA1000 RAW disks) +Cc: stable@vger.kernel.org +Signed-off-by: Sagar Biradar +Reviewed-by: Dave Carroll +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/aacraid/linit.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/drivers/scsi/aacraid/linit.c ++++ b/drivers/scsi/aacraid/linit.c +@@ -413,13 +413,16 @@ static int aac_slave_configure(struct sc + if (chn < AAC_MAX_BUSES && tid < AAC_MAX_TARGETS && aac->sa_firmware) { + devtype = aac->hba_map[chn][tid].devtype; + +- if (devtype == AAC_DEVTYPE_NATIVE_RAW) ++ if (devtype == AAC_DEVTYPE_NATIVE_RAW) { + depth = aac->hba_map[chn][tid].qd_limit; +- else if (devtype == AAC_DEVTYPE_ARC_RAW) ++ set_timeout = 1; ++ goto common_config; ++ } ++ if (devtype == AAC_DEVTYPE_ARC_RAW) { + set_qd_dev_type = true; +- +- set_timeout = 1; +- goto common_config; ++ set_timeout = 1; ++ goto common_config; ++ } + } + + if (aac->jbod && (sdev->type == TYPE_DISK)) diff --git a/queue-4.19/scsi-qla2xxx-fix-lun-discovery-if-loop-id-is-not-assigned-yet-by-firmware.patch b/queue-4.19/scsi-qla2xxx-fix-lun-discovery-if-loop-id-is-not-assigned-yet-by-firmware.patch new file mode 100644 index 00000000000..ba2156c63ee --- /dev/null +++ b/queue-4.19/scsi-qla2xxx-fix-lun-discovery-if-loop-id-is-not-assigned-yet-by-firmware.patch @@ -0,0 +1,45 @@ +From ec322937a7f152d68755dc8316523bf6f831b48f Mon Sep 17 00:00:00 2001 +From: Himanshu Madhani +Date: Fri, 15 Feb 2019 14:37:12 -0800 +Subject: scsi: qla2xxx: Fix LUN discovery if loop id is not assigned yet by firmware + +From: Himanshu Madhani + +commit ec322937a7f152d68755dc8316523bf6f831b48f upstream. + +This patch fixes LUN discovery when loop ID is not yet assigned by the +firmware during driver load/sg_reset operations. Driver will now search for +new loop id before retrying login. + +Fixes: 48acad099074 ("scsi: qla2xxx: Fix N2N link re-connect") +Cc: stable@vger.kernel.org #4.19 +Signed-off-by: Himanshu Madhani +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/qla2xxx/qla_init.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/drivers/scsi/qla2xxx/qla_init.c ++++ b/drivers/scsi/qla2xxx/qla_init.c +@@ -643,11 +643,14 @@ static void qla24xx_handle_gnl_done_even + break; + case DSC_LS_PORT_UNAVAIL: + default: +- if (fcport->loop_id != FC_NO_LOOP_ID) +- qla2x00_clear_loop_id(fcport); +- +- fcport->loop_id = loop_id; +- fcport->fw_login_state = DSC_LS_PORT_UNAVAIL; ++ if (fcport->loop_id == FC_NO_LOOP_ID) { ++ qla2x00_find_new_loop_id(vha, fcport); ++ fcport->fw_login_state = ++ DSC_LS_PORT_UNAVAIL; ++ } ++ ql_dbg(ql_dbg_disc, vha, 0x20e5, ++ "%s %d %8phC\n", __func__, __LINE__, ++ fcport->port_name); + qla24xx_fcport_handle_login(vha, fcport); + break; + } diff --git a/queue-4.19/scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch b/queue-4.19/scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch new file mode 100644 index 00000000000..cb7c4daeefb --- /dev/null +++ b/queue-4.19/scsi-sd-optimal-i-o-size-should-be-a-multiple-of-physical-block-size.patch @@ -0,0 +1,106 @@ +From a83da8a4509d3ebfe03bb7fffce022e4d5d4764f Mon Sep 17 00:00:00 2001 +From: "Martin K. Petersen" +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 + +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: +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759 +Reported-by: Christoph Anton Mitterer +Reviewed-by: Christoph Hellwig +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/sd.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--------- + 1 file changed, 50 insertions(+), 9 deletions(-) + +--- a/drivers/scsi/sd.c ++++ b/drivers/scsi/sd.c +@@ -3066,6 +3066,55 @@ static void sd_read_security(struct scsi + sdkp->security = 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. +@@ -3144,15 +3193,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.19/scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch b/queue-4.19/scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch new file mode 100644 index 00000000000..f78a928edc7 --- /dev/null +++ b/queue-4.19/scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch @@ -0,0 +1,61 @@ +From 32e36bfbcf31452a854263e7c7f32fbefc4b44d8 Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Fri, 25 Jan 2019 10:34:56 -0800 +Subject: scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock + +From: Bart Van Assche + +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): [] __local_bh_enable_ip+0xa9/0x160 +hardirqs last disabled at (1281): [] interrupt_entry+0xb5/0xd0 +softirqs last enabled at (1278): [] lock_sock_nested+0x51/0xc0 +softirqs last disabled at (1280): [] 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); + + 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 +@@ -4045,9 +4045,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.19/scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch b/queue-4.19/scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch new file mode 100644 index 00000000000..ea2a2b6f5f0 --- /dev/null +++ b/queue-4.19/scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch @@ -0,0 +1,63 @@ +From 3722e6a52174d7c3a00e6f5efd006ca093f346c1 Mon Sep 17 00:00:00 2001 +From: Felipe Franciosi +Date: Wed, 27 Feb 2019 16:10:34 +0000 +Subject: scsi: virtio_scsi: don't send sc payload with tmfs + +From: Felipe Franciosi + +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 +Reviewed-by: Paolo Bonzini +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/virtio_scsi.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/scsi/virtio_scsi.c ++++ b/drivers/scsi/virtio_scsi.c +@@ -621,7 +621,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, +@@ -680,7 +679,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, diff --git a/queue-4.19/series b/queue-4.19/series index 63a08db3802..0c7b5610a47 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -144,3 +144,33 @@ tracing-do-not-free-iter-trace-in-fail-path-of-tracing_open_pipe.patch tracing-perf-use-strndup_user-instead-of-buggy-open-coded-version.patch xen-fix-dom0-boot-on-huge-systems.patch acpi-device_sysfs-avoid-of-modalias-creation-for-removed-device.patch +mmc-sdhci-esdhc-imx-fix-hs400-timing-issue.patch +mmc-fix-a-bug-when-max_discard-is-0.patch +netfilter-ipt_clusterip-fix-warning-unused-variable-cn.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 +clocksource-drivers-arch_timer-workaround-for-allwinner-a64-timer-instability.patch +s390-setup-fix-early-warning-messages.patch +s390-virtio-handle-find-on-invalid-queue-gracefully.patch +virtio-introduce-virtio_max_dma_size.patch +virtio-blk-consider-virtio_max_dma_size-for-maximum-segment-size.patch +scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch +scsi-aacraid-fix-performance-issue-on-logical-drives.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-qla2xxx-fix-lun-discovery-if-loop-id-is-not-assigned-yet-by-firmware.patch +fs-devpts-always-delete-dcache-dentry-s-in-dput.patch +splice-don-t-merge-into-linked-buffers.patch +ovl-during-copy-up-first-copy-up-data-and-then-xattrs.patch +ovl-do-not-lose-security.capability-xattr-over-metadata-file-copy-up.patch +m68k-add-ffreestanding-to-cflags.patch +btrfs-setup-a-nofs-context-for-memory-allocation-at-btrfs_create_tree.patch +btrfs-setup-a-nofs-context-for-memory-allocation-at-__btrfs_set_acl.patch +btrfs-drop-the-lock-on-error-in-btrfs_dev_replace_cancel.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 diff --git a/queue-4.19/spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch b/queue-4.19/spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch new file mode 100644 index 00000000000..0a0444270b2 --- /dev/null +++ b/queue-4.19/spi-pxa2xx-setup-maximum-supported-dma-transfer-length.patch @@ -0,0 +1,43 @@ +From ef070b4e4aa25bb5f8632ad196644026c11903bf Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +Date: Tue, 19 Feb 2019 23:21:28 +0300 +Subject: spi: pxa2xx: Setup maximum supported DMA transfer length + +From: Andy Shevchenko + +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 +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/spi/spi-pxa2xx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/spi/spi-pxa2xx.c ++++ b/drivers/spi/spi-pxa2xx.c +@@ -1612,6 +1612,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.19/spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch b/queue-4.19/spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch new file mode 100644 index 00000000000..a99aeea8bb9 --- /dev/null +++ b/queue-4.19/spi-ti-qspi-fix-mmap-read-when-more-than-one-cs-in-use.patch @@ -0,0 +1,48 @@ +From 673c865efbdc5fec3cc525c46d71844d42c60072 Mon Sep 17 00:00:00 2001 +From: Vignesh R +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 + +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 +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -490,8 +490,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; + } +@@ -503,7 +503,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.19/splice-don-t-merge-into-linked-buffers.patch b/queue-4.19/splice-don-t-merge-into-linked-buffers.patch new file mode 100644 index 00000000000..f686ec83c14 --- /dev/null +++ b/queue-4.19/splice-don-t-merge-into-linked-buffers.patch @@ -0,0 +1,113 @@ +From a0ce2f0aa6ad97c3d4927bf2ca54bcebdf062d55 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Wed, 23 Jan 2019 15:19:17 +0100 +Subject: splice: don't merge into linked buffers + +From: Jann Horn + +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: +Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing") +Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()") +Suggested-by: Al Viro +Signed-off-by: Jann Horn +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -234,6 +234,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, +@@ -242,6 +250,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 +@@ -1593,6 +1593,8 @@ retry: + */ + obuf->flags &= ~PIPE_BUF_FLAG_GIFT; + ++ pipe_buf_mark_unmergeable(obuf); ++ + obuf->len = len; + opipe->nrbufs++; + ibuf->offset += obuf->len; +@@ -1667,6 +1669,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; + diff --git a/queue-4.19/virtio-blk-consider-virtio_max_dma_size-for-maximum-segment-size.patch b/queue-4.19/virtio-blk-consider-virtio_max_dma_size-for-maximum-segment-size.patch new file mode 100644 index 00000000000..e852d253e57 --- /dev/null +++ b/queue-4.19/virtio-blk-consider-virtio_max_dma_size-for-maximum-segment-size.patch @@ -0,0 +1,55 @@ +From fd1068e1860e44aaaa337b516df4518d1ce98da1 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Thu, 7 Feb 2019 12:59:17 +0100 +Subject: virtio-blk: Consider virtio_max_dma_size() for maximum segment size + +From: Joerg Roedel + +commit fd1068e1860e44aaaa337b516df4518d1ce98da1 upstream. + +Segments can't be larger than the maximum DMA mapping size +supported on the platform. Take that into account when +setting the maximum segment size for a block device. + +Cc: stable@vger.kernel.org +Reviewed-by: Konrad Rzeszutek Wilk +Reviewed-by: Christoph Hellwig +Signed-off-by: Joerg Roedel +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/virtio_blk.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/drivers/block/virtio_blk.c ++++ b/drivers/block/virtio_blk.c +@@ -630,7 +630,7 @@ static int virtblk_probe(struct virtio_d + struct request_queue *q; + int err, index; + +- u32 v, blk_size, sg_elems, opt_io_size; ++ u32 v, blk_size, max_size, sg_elems, opt_io_size; + u16 min_io_size; + u8 physical_block_exp, alignment_offset; + +@@ -733,14 +733,16 @@ static int virtblk_probe(struct virtio_d + /* No real sector limit. */ + blk_queue_max_hw_sectors(q, -1U); + ++ max_size = virtio_max_dma_size(vdev); ++ + /* Host can optionally specify maximum segment size and number of + * segments. */ + err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX, + struct virtio_blk_config, size_max, &v); + if (!err) +- blk_queue_max_segment_size(q, v); +- else +- blk_queue_max_segment_size(q, -1U); ++ max_size = min(max_size, v); ++ ++ blk_queue_max_segment_size(q, max_size); + + /* Host can optionally specify the block size of the device */ + err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE, diff --git a/queue-4.19/virtio-introduce-virtio_max_dma_size.patch b/queue-4.19/virtio-introduce-virtio_max_dma_size.patch new file mode 100644 index 00000000000..fe8463a6bf6 --- /dev/null +++ b/queue-4.19/virtio-introduce-virtio_max_dma_size.patch @@ -0,0 +1,62 @@ +From e6d6dd6c875eb3c9b69bb640419405726e6e0bbe Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Thu, 7 Feb 2019 12:59:16 +0100 +Subject: virtio: Introduce virtio_max_dma_size() + +From: Joerg Roedel + +commit e6d6dd6c875eb3c9b69bb640419405726e6e0bbe upstream. + +This function returns the maximum segment size for a single +dma transaction of a virtio device. The possible limit comes +from the SWIOTLB implementation in the Linux kernel, that +has an upper limit of (currently) 256kb of contiguous +memory it can map. Other DMA-API implementations might also +have limits. + +Use the new dma_max_mapping_size() function to determine the +maximum mapping size when DMA-API is in use for virtio. + +Cc: stable@vger.kernel.org +Reviewed-by: Konrad Rzeszutek Wilk +Reviewed-by: Christoph Hellwig +Signed-off-by: Joerg Roedel +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/virtio/virtio_ring.c | 11 +++++++++++ + include/linux/virtio.h | 2 ++ + 2 files changed, 13 insertions(+) + +--- a/drivers/virtio/virtio_ring.c ++++ b/drivers/virtio/virtio_ring.c +@@ -1013,6 +1013,17 @@ struct virtqueue *__vring_new_virtqueue( + } + EXPORT_SYMBOL_GPL(__vring_new_virtqueue); + ++size_t virtio_max_dma_size(struct virtio_device *vdev) ++{ ++ size_t max_segment_size = SIZE_MAX; ++ ++ if (vring_use_dma_api(vdev)) ++ max_segment_size = dma_max_mapping_size(&vdev->dev); ++ ++ return max_segment_size; ++} ++EXPORT_SYMBOL_GPL(virtio_max_dma_size); ++ + static void *vring_alloc_queue(struct virtio_device *vdev, size_t size, + dma_addr_t *dma_handle, gfp_t flag) + { +--- a/include/linux/virtio.h ++++ b/include/linux/virtio.h +@@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_d + int virtio_device_restore(struct virtio_device *dev); + #endif + ++size_t virtio_max_dma_size(struct virtio_device *vdev); ++ + #define virtio_device_for_each_vq(vdev, vq) \ + list_for_each_entry(vq, &vdev->vqs, list) +