--- /dev/null
+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
+@@ -3015,11 +3015,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;
--- /dev/null
+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
+@@ -59,7 +59,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
--- /dev/null
+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 struct regulator_desc regulators[
+ 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 struct regulator_desc regulators[
+ 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),
--- /dev/null
+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
+@@ -369,7 +369,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),
+@@ -379,8 +379,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),
+ };
--- /dev/null
+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
+@@ -4198,9 +4198,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);
--- /dev/null
+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
+@@ -653,7 +653,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 = VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET,
+@@ -728,7 +727,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,
tmpfs-fix-link-accounting-when-a-tmpfile-is-linked-i.patch
net-set-static-variable-an-initial-value-in-atl2_pro.patch
cifs-fix-read-after-write-for-files-with-read-caching.patch
+regulator-s2mps11-fix-steps-for-buck7-buck8-and-ldo35.patch
+regulator-s2mpa01-fix-step-values-for-some-ldos.patch
+scsi-virtio_scsi-don-t-send-sc-payload-with-tmfs.patch
+scsi-target-iscsi-avoid-iscsit_release_commands_from_conn-deadlock.patch
+m68k-add-ffreestanding-to-cflags.patch
+btrfs-fix-corruption-reading-shared-and-compressed-extents-after-hole-punching.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
