]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.10-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 30 Jul 2015 19:41:33 +0000 (12:41 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 30 Jul 2015 19:41:33 +0000 (12:41 -0700)
added patches:
vtpm-set-virtual-device-before-passing-to-ibmvtpm_reset_crq.patch
xfs-fix-remote-symlinks-on-v5-crc-filesystems.patch

queue-3.10/series
queue-3.10/vtpm-set-virtual-device-before-passing-to-ibmvtpm_reset_crq.patch [new file with mode: 0644]
queue-3.10/xfs-fix-remote-symlinks-on-v5-crc-filesystems.patch [new file with mode: 0644]

index 1ee83bfde97fbadba3de7bce2cf77f03d19991d5..232494c6629bb14cb9522862e254ba85c8cc606f 100644 (file)
@@ -53,3 +53,5 @@ drm-qxl-do-not-cause-spice-server-to-clean-our-objects.patch
 drm-radeon-take-the-mode_config-mutex-when-dealing-with-hpds-v2.patch
 drm-radeon-don-t-flush-the-gart-tlb-if-rdev-gart.ptr-null.patch
 drm-add-a-check-for-x-y-in-drm_mode_setcrtc.patch
+xfs-fix-remote-symlinks-on-v5-crc-filesystems.patch
+vtpm-set-virtual-device-before-passing-to-ibmvtpm_reset_crq.patch
diff --git a/queue-3.10/vtpm-set-virtual-device-before-passing-to-ibmvtpm_reset_crq.patch b/queue-3.10/vtpm-set-virtual-device-before-passing-to-ibmvtpm_reset_crq.patch
new file mode 100644 (file)
index 0000000..07bfe13
--- /dev/null
@@ -0,0 +1,45 @@
+From 9d75f08946e8485109458ccf16f714697c207f41 Mon Sep 17 00:00:00 2001
+From: "Hon Ching \\(Vicky\\) Lo" <honclo@linux.vnet.ibm.com>
+Date: Fri, 22 May 2015 13:23:02 -0400
+Subject: vTPM: set virtual device before passing to ibmvtpm_reset_crq
+
+From: "Hon Ching \\(Vicky\\) Lo" <honclo@linux.vnet.ibm.com>
+
+commit 9d75f08946e8485109458ccf16f714697c207f41 upstream.
+
+tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
+set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
+the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.
+
+Signed-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
+Signed-off-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
+Reviewed-by: Ashley Lai <ashley@ahsleylai.com>
+Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
+Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/tpm_ibmvtpm.c |    5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/char/tpm/tpm_ibmvtpm.c
++++ b/drivers/char/tpm/tpm_ibmvtpm.c
+@@ -618,6 +618,9 @@ static int tpm_ibmvtpm_probe(struct vio_
+               goto cleanup;
+       }
++      ibmvtpm->dev = dev;
++      ibmvtpm->vdev = vio_dev;
++
+       crq_q = &ibmvtpm->crq_queue;
+       crq_q->crq_addr = (struct ibmvtpm_crq *)get_zeroed_page(GFP_KERNEL);
+       if (!crq_q->crq_addr) {
+@@ -662,8 +665,6 @@ static int tpm_ibmvtpm_probe(struct vio_
+       crq_q->index = 0;
+-      ibmvtpm->dev = dev;
+-      ibmvtpm->vdev = vio_dev;
+       TPM_VPRIV(chip) = (void *)ibmvtpm;
+       spin_lock_init(&ibmvtpm->rtce_lock);
diff --git a/queue-3.10/xfs-fix-remote-symlinks-on-v5-crc-filesystems.patch b/queue-3.10/xfs-fix-remote-symlinks-on-v5-crc-filesystems.patch
new file mode 100644 (file)
index 0000000..f5293fe
--- /dev/null
@@ -0,0 +1,49 @@
+From 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 Mon Sep 17 00:00:00 2001
+From: Eric Sandeen <sandeen@redhat.com>
+Date: Mon, 22 Jun 2015 09:42:48 +1000
+Subject: xfs: fix remote symlinks on V5/CRC filesystems
+
+From: Eric Sandeen <sandeen@redhat.com>
+
+commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream.
+
+If we create a CRC filesystem, mount it, and create a symlink with
+a path long enough that it can't live in the inode, we get a very
+strange result upon remount:
+
+# ls -l mnt
+total 4
+lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM
+
+XSLM is the V5 symlink block header magic (which happens to be
+followed by a NUL, so the string looks terminated).
+
+xfs_readlink_bmap() advanced cur_chunk by the size of the header
+for CRC filesystems, but never actually used that pointer; it
+kept reading from bp->b_addr, which is the start of the block,
+rather than the start of the symlink data after the header.
+
+Looks like this problem goes back to v3.10.
+
+Fixing this gets us reading the proper link target, again.
+
+Signed-off-by: Eric Sandeen <sandeen@redhat.com>
+Reviewed-by: Dave Chinner <dchinner@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_symlink.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/xfs/xfs_symlink.c
++++ b/fs/xfs/xfs_symlink.c
+@@ -272,7 +272,7 @@ xfs_readlink_bmap(
+                       cur_chunk += sizeof(struct xfs_dsymlink_hdr);
+               }
+-              memcpy(link + offset, bp->b_addr, byte_cnt);
++              memcpy(link + offset, cur_chunk, byte_cnt);
+               pathlen -= byte_cnt;
+               offset += byte_cnt;