--- /dev/null
+From ab89f0bdd63a3721f7cd3f064f39fc4ac7ca14d4 Mon Sep 17 00:00:00 2001
+From: Szymon Janc <szymon.janc@codecoup.pl>
+Date: Mon, 24 Apr 2017 18:25:04 -0700
+Subject: Bluetooth: Fix user channel for 32bit userspace on 64bit kernel
+
+From: Szymon Janc <szymon.janc@codecoup.pl>
+
+commit ab89f0bdd63a3721f7cd3f064f39fc4ac7ca14d4 upstream.
+
+Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
+defined as 0x80000000. This results in sendmsg failure if used from 32bit
+userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
+in flags check in hci_sock_sendmsg.
+
+Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
+Signed-off-by: Marko Kiiskila <marko@runtime.io>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/hci_sock.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/hci_sock.c
++++ b/net/bluetooth/hci_sock.c
+@@ -1680,7 +1680,8 @@ static int hci_sock_sendmsg(struct socke
+ if (msg->msg_flags & MSG_OOB)
+ return -EOPNOTSUPP;
+
+- if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_NOSIGNAL|MSG_ERRQUEUE))
++ if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_NOSIGNAL|MSG_ERRQUEUE|
++ MSG_CMSG_COMPAT))
+ return -EINVAL;
+
+ if (len < 4 || len > HCI_MAX_FRAME_SIZE)
--- /dev/null
+From 95065a61e9bf25fb85295127fba893200c2bbbd8 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 29 Mar 2017 18:15:27 +0200
+Subject: Bluetooth: hci_bcm: add missing tty-device sanity check
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 95065a61e9bf25fb85295127fba893200c2bbbd8 upstream.
+
+Make sure to check the tty-device pointer before looking up the sibling
+platform device to avoid dereferencing a NULL-pointer when the tty is
+one end of a Unix98 pty.
+
+Fixes: 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices")
+Cc: Frederic Danis <frederic.danis@linux.intel.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/hci_bcm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/bluetooth/hci_bcm.c
++++ b/drivers/bluetooth/hci_bcm.c
+@@ -287,6 +287,9 @@ static int bcm_open(struct hci_uart *hu)
+
+ hu->priv = bcm;
+
++ if (!hu->tty->dev)
++ goto out;
++
+ mutex_lock(&bcm_device_lock);
+ list_for_each(p, &bcm_device_list) {
+ struct bcm_device *dev = list_entry(p, struct bcm_device, list);
+@@ -307,7 +310,7 @@ static int bcm_open(struct hci_uart *hu)
+ }
+
+ mutex_unlock(&bcm_device_lock);
+-
++out:
+ return 0;
+ }
+
--- /dev/null
+From dcb9cfaa5ea9aa0ec08aeb92582ccfe3e4c719a9 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Wed, 29 Mar 2017 18:15:28 +0200
+Subject: Bluetooth: hci_intel: add missing tty-device sanity check
+
+From: Johan Hovold <johan@kernel.org>
+
+commit dcb9cfaa5ea9aa0ec08aeb92582ccfe3e4c719a9 upstream.
+
+Make sure to check the tty-device pointer before looking up the sibling
+platform device to avoid dereferencing a NULL-pointer when the tty is
+one end of a Unix98 pty.
+
+Fixes: 74cdad37cd24 ("Bluetooth: hci_intel: Add runtime PM support")
+Fixes: 1ab1f239bf17 ("Bluetooth: hci_intel: Add support for platform driver")
+Cc: Loic Poulain <loic.poulain@intel.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/hci_intel.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/drivers/bluetooth/hci_intel.c
++++ b/drivers/bluetooth/hci_intel.c
+@@ -307,6 +307,9 @@ static int intel_set_power(struct hci_ua
+ struct list_head *p;
+ int err = -ENODEV;
+
++ if (!hu->tty->dev)
++ return err;
++
+ mutex_lock(&intel_device_list_lock);
+
+ list_for_each(p, &intel_device_list) {
+@@ -379,6 +382,9 @@ static void intel_busy_work(struct work_
+ struct intel_data *intel = container_of(work, struct intel_data,
+ busy_work);
+
++ if (!intel->hu->tty->dev)
++ return;
++
+ /* Link is busy, delay the suspend */
+ mutex_lock(&intel_device_list_lock);
+ list_for_each(p, &intel_device_list) {
+@@ -889,6 +895,8 @@ done:
+ list_for_each(p, &intel_device_list) {
+ struct intel_device *dev = list_entry(p, struct intel_device,
+ list);
++ if (!hu->tty->dev)
++ break;
+ if (hu->tty->dev->parent == dev->pdev->dev.parent) {
+ if (device_may_wakeup(&dev->pdev->dev)) {
+ set_bit(STATE_LPM_ENABLED, &intel->flags);
+@@ -1056,6 +1064,9 @@ static int intel_enqueue(struct hci_uart
+
+ BT_DBG("hu %p skb %p", hu, skb);
+
++ if (!hu->tty->dev)
++ goto out_enqueue;
++
+ /* Be sure our controller is resumed and potential LPM transaction
+ * completed before enqueuing any packet.
+ */
+@@ -1072,7 +1083,7 @@ static int intel_enqueue(struct hci_uart
+ }
+ }
+ mutex_unlock(&intel_device_list_lock);
+-
++out_enqueue:
+ skb_queue_tail(&intel->txq, skb);
+
+ return 0;
--- /dev/null
+From ed01e50acdd3e4a640cf9ebd28a7e810c3ceca97 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Fri, 17 Mar 2017 12:48:09 -0600
+Subject: device-dax: fix cdev leak
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit ed01e50acdd3e4a640cf9ebd28a7e810c3ceca97 upstream.
+
+If device_add() fails, cleanup the cdev. Otherwise, we leak a kobj_map()
+with a stale device number.
+
+As Jason points out, there is a small possibility that userspace has
+opened and mapped the device in the time between cdev_add() and the
+device_add() failure. We need a new kill_dax_dev() helper to invalidate
+any established mappings.
+
+Fixes: ba09c01d2fa8 ("dax: convert to the cdev api")
+Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dax/dax.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/drivers/dax/dax.c
++++ b/drivers/dax/dax.c
+@@ -553,13 +553,10 @@ static void dax_dev_release(struct devic
+ kfree(dax_dev);
+ }
+
+-static void unregister_dax_dev(void *dev)
++static void kill_dax_dev(struct dax_dev *dax_dev)
+ {
+- struct dax_dev *dax_dev = to_dax_dev(dev);
+ struct cdev *cdev = &dax_dev->cdev;
+
+- dev_dbg(dev, "%s\n", __func__);
+-
+ /*
+ * Note, rcu is not protecting the liveness of dax_dev, rcu is
+ * ensuring that any fault handlers that might have seen
+@@ -571,6 +568,15 @@ static void unregister_dax_dev(void *dev
+ synchronize_srcu(&dax_srcu);
+ unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
+ cdev_del(cdev);
++}
++
++static void unregister_dax_dev(void *dev)
++{
++ struct dax_dev *dax_dev = to_dax_dev(dev);
++
++ dev_dbg(dev, "%s\n", __func__);
++
++ kill_dax_dev(dax_dev);
+ device_unregister(dev);
+ }
+
+@@ -647,6 +653,7 @@ struct dax_dev *devm_create_dax_dev(stru
+ dev_set_name(dev, "dax%d.%d", dax_region->id, dax_dev->id);
+ rc = device_add(dev);
+ if (rc) {
++ kill_dax_dev(dax_dev);
+ put_device(dev);
+ return ERR_PTR(rc);
+ }
--- /dev/null
+From 272f98f6846277378e1758a49a49d7bf39343c02 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 7 Apr 2017 10:58:37 -0700
+Subject: fscrypt: fix context consistency check when key(s) unavailable
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 272f98f6846277378e1758a49a49d7bf39343c02 upstream.
+
+To mitigate some types of offline attacks, filesystem encryption is
+designed to enforce that all files in an encrypted directory tree use
+the same encryption policy (i.e. the same encryption context excluding
+the nonce). However, the fscrypt_has_permitted_context() function which
+enforces this relies on comparing struct fscrypt_info's, which are only
+available when we have the encryption keys. This can cause two
+incorrect behaviors:
+
+1. If we have the parent directory's key but not the child's key, or
+ vice versa, then fscrypt_has_permitted_context() returned false,
+ causing applications to see EPERM or ENOKEY. This is incorrect if
+ the encryption contexts are in fact consistent. Although we'd
+ normally have either both keys or neither key in that case since the
+ master_key_descriptors would be the same, this is not guaranteed
+ because keys can be added or removed from keyrings at any time.
+
+2. If we have neither the parent's key nor the child's key, then
+ fscrypt_has_permitted_context() returned true, causing applications
+ to see no error (or else an error for some other reason). This is
+ incorrect if the encryption contexts are in fact inconsistent, since
+ in that case we should deny access.
+
+To fix this, retrieve and compare the fscrypt_contexts if we are unable
+to set up both fscrypt_infos.
+
+While this slightly hurts performance when accessing an encrypted
+directory tree without the key, this isn't a case we really need to be
+optimizing for; access *with* the key is much more important.
+Furthermore, the performance hit is barely noticeable given that we are
+already retrieving the fscrypt_context and doing two keyring searches in
+fscrypt_get_encryption_info(). If we ever actually wanted to optimize
+this case we might start by caching the fscrypt_contexts.
+
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/crypto/policy.c | 87 +++++++++++++++++++++++++++++++++++++++++------------
+ 1 file changed, 68 insertions(+), 19 deletions(-)
+
+--- a/fs/crypto/policy.c
++++ b/fs/crypto/policy.c
+@@ -161,27 +161,61 @@ int fscrypt_get_policy(struct inode *ino
+ }
+ EXPORT_SYMBOL(fscrypt_get_policy);
+
++/**
++ * fscrypt_has_permitted_context() - is a file's encryption policy permitted
++ * within its directory?
++ *
++ * @parent: inode for parent directory
++ * @child: inode for file being looked up, opened, or linked into @parent
++ *
++ * Filesystems must call this before permitting access to an inode in a
++ * situation where the parent directory is encrypted (either before allowing
++ * ->lookup() to succeed, or for a regular file before allowing it to be opened)
++ * and before any operation that involves linking an inode into an encrypted
++ * directory, including link, rename, and cross rename. It enforces the
++ * constraint that within a given encrypted directory tree, all files use the
++ * same encryption policy. The pre-access check is needed to detect potentially
++ * malicious offline violations of this constraint, while the link and rename
++ * checks are needed to prevent online violations of this constraint.
++ *
++ * Return: 1 if permitted, 0 if forbidden. If forbidden, the caller must fail
++ * the filesystem operation with EPERM.
++ */
+ int fscrypt_has_permitted_context(struct inode *parent, struct inode *child)
+ {
+- struct fscrypt_info *parent_ci, *child_ci;
++ const struct fscrypt_operations *cops = parent->i_sb->s_cop;
++ const struct fscrypt_info *parent_ci, *child_ci;
++ struct fscrypt_context parent_ctx, child_ctx;
+ int res;
+
+- if ((parent == NULL) || (child == NULL)) {
+- printk(KERN_ERR "parent %p child %p\n", parent, child);
+- BUG_ON(1);
+- }
+-
+ /* No restrictions on file types which are never encrypted */
+ if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
+ !S_ISLNK(child->i_mode))
+ return 1;
+
+- /* no restrictions if the parent directory is not encrypted */
+- if (!parent->i_sb->s_cop->is_encrypted(parent))
++ /* No restrictions if the parent directory is unencrypted */
++ if (!cops->is_encrypted(parent))
+ return 1;
+- /* if the child directory is not encrypted, this is always a problem */
+- if (!parent->i_sb->s_cop->is_encrypted(child))
++
++ /* Encrypted directories must not contain unencrypted files */
++ if (!cops->is_encrypted(child))
+ return 0;
++
++ /*
++ * Both parent and child are encrypted, so verify they use the same
++ * encryption policy. Compare the fscrypt_info structs if the keys are
++ * available, otherwise retrieve and compare the fscrypt_contexts.
++ *
++ * Note that the fscrypt_context retrieval will be required frequently
++ * when accessing an encrypted directory tree without the key.
++ * Performance-wise this is not a big deal because we already don't
++ * really optimize for file access without the key (to the extent that
++ * such access is even possible), given that any attempted access
++ * already causes a fscrypt_context retrieval and keyring search.
++ *
++ * In any case, if an unexpected error occurs, fall back to "forbidden".
++ */
++
+ res = fscrypt_get_encryption_info(parent);
+ if (res)
+ return 0;
+@@ -190,17 +224,32 @@ int fscrypt_has_permitted_context(struct
+ return 0;
+ parent_ci = parent->i_crypt_info;
+ child_ci = child->i_crypt_info;
+- if (!parent_ci && !child_ci)
+- return 1;
+- if (!parent_ci || !child_ci)
++
++ if (parent_ci && child_ci) {
++ return memcmp(parent_ci->ci_master_key, child_ci->ci_master_key,
++ FS_KEY_DESCRIPTOR_SIZE) == 0 &&
++ (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
++ (parent_ci->ci_filename_mode ==
++ child_ci->ci_filename_mode) &&
++ (parent_ci->ci_flags == child_ci->ci_flags);
++ }
++
++ res = cops->get_context(parent, &parent_ctx, sizeof(parent_ctx));
++ if (res != sizeof(parent_ctx))
++ return 0;
++
++ res = cops->get_context(child, &child_ctx, sizeof(child_ctx));
++ if (res != sizeof(child_ctx))
+ return 0;
+
+- return (memcmp(parent_ci->ci_master_key,
+- child_ci->ci_master_key,
+- FS_KEY_DESCRIPTOR_SIZE) == 0 &&
+- (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
+- (parent_ci->ci_filename_mode == child_ci->ci_filename_mode) &&
+- (parent_ci->ci_flags == child_ci->ci_flags));
++ return memcmp(parent_ctx.master_key_descriptor,
++ child_ctx.master_key_descriptor,
++ FS_KEY_DESCRIPTOR_SIZE) == 0 &&
++ (parent_ctx.contents_encryption_mode ==
++ child_ctx.contents_encryption_mode) &&
++ (parent_ctx.filenames_encryption_mode ==
++ child_ctx.filenames_encryption_mode) &&
++ (parent_ctx.flags == child_ctx.flags);
+ }
+ EXPORT_SYMBOL(fscrypt_has_permitted_context);
+
--- /dev/null
+From c6ade20f5e50e188d20b711a618b20dd1d50457e Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Tue, 25 Apr 2017 13:39:54 +0200
+Subject: libata: reject passthrough WRITE SAME requests
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit c6ade20f5e50e188d20b711a618b20dd1d50457e upstream.
+
+The WRITE SAME to TRIM translation rewrites the DATA OUT buffer. While
+the SCSI code accomodates for this by passing a read-writable buffer
+userspace applications don't cater for this behavior. In fact it can
+be used to rewrite e.g. a readonly file through mmap and should be
+considered as a security fix.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-scsi.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -3405,6 +3405,14 @@ static unsigned int ata_scsi_write_same_
+ if (unlikely(!dev->dma_mode))
+ goto invalid_opcode;
+
++ /*
++ * We only allow sending this command through the block layer,
++ * as it modifies the DATA OUT buffer, which would corrupt user
++ * memory for SG_IO commands.
++ */
++ if (unlikely(blk_rq_is_passthrough(scmd->request)))
++ goto invalid_opcode;
++
+ if (unlikely(scmd->cmd_len < 16)) {
+ fp = 15;
+ goto invalid_fld;
--- /dev/null
+From 099bd73dc17ed77aa8c98323e043613b6e8f54fc Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 10 Apr 2017 11:21:38 +0200
+Subject: serial: omap: fix runtime-pm handling on unbind
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 099bd73dc17ed77aa8c98323e043613b6e8f54fc upstream.
+
+An unbalanced and misplaced synchronous put was used to suspend the
+device on driver unbind, something which with a likewise misplaced
+pm_runtime_disable leads to external aborts when an open port is being
+removed.
+
+Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa024010
+...
+[<c046e760>] (serial_omap_set_mctrl) from [<c046a064>] (uart_update_mctrl+0x50/0x60)
+[<c046a064>] (uart_update_mctrl) from [<c046a400>] (uart_shutdown+0xbc/0x138)
+[<c046a400>] (uart_shutdown) from [<c046bd2c>] (uart_hangup+0x94/0x190)
+[<c046bd2c>] (uart_hangup) from [<c045b760>] (__tty_hangup+0x404/0x41c)
+[<c045b760>] (__tty_hangup) from [<c045b794>] (tty_vhangup+0x1c/0x20)
+[<c045b794>] (tty_vhangup) from [<c046ccc8>] (uart_remove_one_port+0xec/0x260)
+[<c046ccc8>] (uart_remove_one_port) from [<c046ef4c>] (serial_omap_remove+0x40/0x60)
+[<c046ef4c>] (serial_omap_remove) from [<c04845e8>] (platform_drv_remove+0x34/0x4c)
+
+Fix this up by resuming the device before deregistering the port and by
+suspending and disabling runtime pm only after the port has been
+removed.
+
+Also make sure to disable autosuspend before disabling runtime pm so
+that the usage count is balanced and device actually suspended before
+returning.
+
+Note that due to a negative autosuspend delay being set in probe, the
+unbalanced put would actually suspend the device on first driver unbind,
+while rebinding and again unbinding would result in a negative
+power.usage_count.
+
+Fixes: 7e9c8e7dbf3b ("serial: omap: make sure to suspend device before remove")
+Cc: Felipe Balbi <balbi@kernel.org>
+Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/omap-serial.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/omap-serial.c
++++ b/drivers/tty/serial/omap-serial.c
+@@ -1725,9 +1725,13 @@ static int serial_omap_remove(struct pla
+ {
+ struct uart_omap_port *up = platform_get_drvdata(dev);
+
++ pm_runtime_get_sync(up->dev);
++
++ uart_remove_one_port(&serial_omap_reg, &up->port);
++
++ pm_runtime_dont_use_autosuspend(up->dev);
+ pm_runtime_put_sync(up->dev);
+ pm_runtime_disable(up->dev);
+- uart_remove_one_port(&serial_omap_reg, &up->port);
+ pm_qos_remove_request(&up->pm_qos_request);
+ device_init_wakeup(&dev->dev, false);
+
--- /dev/null
+From 77e6fe7fd2b7cba0bf2f2dc8cde51d7b9a35bf74 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 10 Apr 2017 11:21:39 +0200
+Subject: serial: omap: suspend device on probe errors
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 77e6fe7fd2b7cba0bf2f2dc8cde51d7b9a35bf74 upstream.
+
+Make sure to actually suspend the device before returning after a failed
+(or deferred) probe.
+
+Note that autosuspend must be disabled before runtime pm is disabled in
+order to balance the usage count due to a negative autosuspend delay as
+well as to make the final put suspend the device synchronously.
+
+Fixes: 388bc2622680 ("omap-serial: Fix the error handling in the omap_serial probe")
+Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/omap-serial.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/omap-serial.c
++++ b/drivers/tty/serial/omap-serial.c
+@@ -1712,7 +1712,8 @@ static int serial_omap_probe(struct plat
+ return 0;
+
+ err_add_port:
+- pm_runtime_put(&pdev->dev);
++ pm_runtime_dont_use_autosuspend(&pdev->dev);
++ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ pm_qos_remove_request(&up->pm_qos_request);
+ device_init_wakeup(up->dev, false);
--- /dev/null
+From 768d64f491a530062ddad50e016fb27125f8bd7c Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Mon, 3 Apr 2017 08:20:59 +0200
+Subject: serial: samsung: Use right device for DMA-mapping calls
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+commit 768d64f491a530062ddad50e016fb27125f8bd7c upstream.
+
+Driver should provide its own struct device for all DMA-mapping calls instead
+of extracting device pointer from DMA engine channel. Although this is harmless
+from the driver operation perspective on ARM architecture, it is always good
+to use the DMA mapping API in a proper way. This patch fixes following DMA API
+debug warning:
+
+WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1241 check_sync+0x520/0x9f4
+samsung-uart 12c20000.serial: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000006df0f580] [size=64 bytes]
+Modules linked in:
+CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00137-g07ca963 #51
+Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
+[<c011aaa4>] (unwind_backtrace) from [<c01127c0>] (show_stack+0x20/0x24)
+[<c01127c0>] (show_stack) from [<c06ba5d8>] (dump_stack+0x84/0xa0)
+[<c06ba5d8>] (dump_stack) from [<c0139528>] (__warn+0x14c/0x180)
+[<c0139528>] (__warn) from [<c01395a4>] (warn_slowpath_fmt+0x48/0x50)
+[<c01395a4>] (warn_slowpath_fmt) from [<c0729058>] (check_sync+0x520/0x9f4)
+[<c0729058>] (check_sync) from [<c072967c>] (debug_dma_sync_single_for_device+0x88/0xc8)
+[<c072967c>] (debug_dma_sync_single_for_device) from [<c0803c10>] (s3c24xx_serial_start_tx_dma+0x100/0x2f8)
+[<c0803c10>] (s3c24xx_serial_start_tx_dma) from [<c0804338>] (s3c24xx_serial_tx_chars+0x198/0x33c)
+
+Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
+Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions")
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/samsung.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/drivers/tty/serial/samsung.c
++++ b/drivers/tty/serial/samsung.c
+@@ -906,14 +906,13 @@ static int s3c24xx_serial_request_dma(st
+ return -ENOMEM;
+ }
+
+- dma->rx_addr = dma_map_single(dma->rx_chan->device->dev, dma->rx_buf,
++ dma->rx_addr = dma_map_single(p->port.dev, dma->rx_buf,
+ dma->rx_size, DMA_FROM_DEVICE);
+
+ spin_lock_irqsave(&p->port.lock, flags);
+
+ /* TX buffer */
+- dma->tx_addr = dma_map_single(dma->tx_chan->device->dev,
+- p->port.state->xmit.buf,
++ dma->tx_addr = dma_map_single(p->port.dev, p->port.state->xmit.buf,
+ UART_XMIT_SIZE, DMA_TO_DEVICE);
+
+ spin_unlock_irqrestore(&p->port.lock, flags);
+@@ -927,7 +926,7 @@ static void s3c24xx_serial_release_dma(s
+
+ if (dma->rx_chan) {
+ dmaengine_terminate_all(dma->rx_chan);
+- dma_unmap_single(dma->rx_chan->device->dev, dma->rx_addr,
++ dma_unmap_single(p->port.dev, dma->rx_addr,
+ dma->rx_size, DMA_FROM_DEVICE);
+ kfree(dma->rx_buf);
+ dma_release_channel(dma->rx_chan);
+@@ -936,7 +935,7 @@ static void s3c24xx_serial_release_dma(s
+
+ if (dma->tx_chan) {
+ dmaengine_terminate_all(dma->tx_chan);
+- dma_unmap_single(dma->tx_chan->device->dev, dma->tx_addr,
++ dma_unmap_single(p->port.dev, dma->tx_addr,
+ UART_XMIT_SIZE, DMA_TO_DEVICE);
+ dma_release_channel(dma->tx_chan);
+ dma->tx_chan = NULL;
cifs-fix-cifs_ioc_get_mnt_info-oops.patch
cifs-add-misssing-sfm-mapping-for-doublequote.patch
padata-free-correct-variable.patch
+device-dax-fix-cdev-leak.patch
+fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch
+serial-samsung-use-right-device-for-dma-mapping-calls.patch
+serial-omap-fix-runtime-pm-handling-on-unbind.patch
+serial-omap-suspend-device-on-probe-errors.patch
+tty-pty-fix-ldisc-flush-after-userspace-become-aware-of-the-data-already.patch
+bluetooth-fix-user-channel-for-32bit-userspace-on-64bit-kernel.patch
+bluetooth-hci_bcm-add-missing-tty-device-sanity-check.patch
+bluetooth-hci_intel-add-missing-tty-device-sanity-check.patch
+libata-reject-passthrough-write-same-requests.patch
--- /dev/null
+From 77dae6134440420bac334581a3ccee94cee1c054 Mon Sep 17 00:00:00 2001
+From: Wang YanQing <udknight@gmail.com>
+Date: Wed, 22 Feb 2017 19:37:08 +0800
+Subject: tty: pty: Fix ldisc flush after userspace become aware of the data already
+
+From: Wang YanQing <udknight@gmail.com>
+
+commit 77dae6134440420bac334581a3ccee94cee1c054 upstream.
+
+While using emacs, cat or others' commands in konsole with recent
+kernels, I have met many times that CTRL-C freeze konsole. After
+konsole freeze I can't type anything, then I have to open a new one,
+it is very annoying.
+
+See bug report:
+https://bugs.kde.org/show_bug.cgi?id=175283
+
+The platform in that bug report is Solaris, but now the pty in linux
+has the same problem or the same behavior as Solaris :)
+
+It has high possibility to trigger the problem follow steps below:
+Note: In my test, BigFile is a text file whose size is bigger than 1G
+1:open konsole
+1:cat BigFile
+2:CTRL-C
+
+After some digging, I find out the reason is that commit 1d1d14da12e7
+("pty: Fix buffer flush deadlock") changes the behavior of pty_flush_buffer.
+
+Thread A Thread B
+-------- --------
+1:n_tty_poll return POLLIN
+ 2:CTRL-C trigger pty_flush_buffer
+ tty_buffer_flush
+ n_tty_flush_buffer
+3:attempt to check count of chars:
+ ioctl(fd, TIOCINQ, &available)
+ available is equal to 0
+
+4:read(fd, buffer, avaiable)
+ return 0
+
+5:konsole close fd
+
+Yes, I know we could use the same patch included in the BUG report as
+a workaround for linux platform too. But I think the data in ldisc is
+belong to application of another side, we shouldn't clear it when we
+want to flush write buffer of this side in pty_flush_buffer. So I think
+it is better to disable ldisc flush in pty_flush_buffer, because its new
+hehavior bring no benefit except that it mess up the behavior between
+POLLIN, and TIOCINQ or FIONREAD.
+
+Also I find no flush_buffer function in others' tty driver has the
+same behavior as current pty_flush_buffer.
+
+Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock")
+Signed-off-by: Wang YanQing <udknight@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/pty.c | 7 +------
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+--- a/drivers/tty/pty.c
++++ b/drivers/tty/pty.c
+@@ -216,16 +216,11 @@ static int pty_signal(struct tty_struct
+ static void pty_flush_buffer(struct tty_struct *tty)
+ {
+ struct tty_struct *to = tty->link;
+- struct tty_ldisc *ld;
+
+ if (!to)
+ return;
+
+- ld = tty_ldisc_ref(to);
+- tty_buffer_flush(to, ld);
+- if (ld)
+- tty_ldisc_deref(ld);
+-
++ tty_buffer_flush(to, NULL);
+ if (to->packet) {
+ spin_lock_irq(&tty->ctrl_lock);
+ tty->ctrl_status |= TIOCPKT_FLUSHWRITE;
projects / thirdparty / kernel / stable-queue.git / commitdiff
