From: Greg Kroah-Hartman Date: Thu, 18 May 2017 07:46:47 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v3.18.54~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3f751d815dcb2c84178e38b5bdfb71c96cd66f1e;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: 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 device-dax-fix-cdev-leak.patch fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch libata-reject-passthrough-write-same-requests.patch serial-omap-fix-runtime-pm-handling-on-unbind.patch serial-omap-suspend-device-on-probe-errors.patch serial-samsung-use-right-device-for-dma-mapping-calls.patch tty-pty-fix-ldisc-flush-after-userspace-become-aware-of-the-data-already.patch --- diff --git a/queue-4.9/bluetooth-fix-user-channel-for-32bit-userspace-on-64bit-kernel.patch b/queue-4.9/bluetooth-fix-user-channel-for-32bit-userspace-on-64bit-kernel.patch new file mode 100644 index 00000000000..1d0fd9f6c4f --- /dev/null +++ b/queue-4.9/bluetooth-fix-user-channel-for-32bit-userspace-on-64bit-kernel.patch @@ -0,0 +1,35 @@ +From ab89f0bdd63a3721f7cd3f064f39fc4ac7ca14d4 Mon Sep 17 00:00:00 2001 +From: Szymon Janc +Date: Mon, 24 Apr 2017 18:25:04 -0700 +Subject: Bluetooth: Fix user channel for 32bit userspace on 64bit kernel + +From: Szymon Janc + +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 +Signed-off-by: Marko Kiiskila +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.9/bluetooth-hci_bcm-add-missing-tty-device-sanity-check.patch b/queue-4.9/bluetooth-hci_bcm-add-missing-tty-device-sanity-check.patch new file mode 100644 index 00000000000..ac09d2ebb12 --- /dev/null +++ b/queue-4.9/bluetooth-hci_bcm-add-missing-tty-device-sanity-check.patch @@ -0,0 +1,44 @@ +From 95065a61e9bf25fb85295127fba893200c2bbbd8 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 29 Mar 2017 18:15:27 +0200 +Subject: Bluetooth: hci_bcm: add missing tty-device sanity check + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.9/bluetooth-hci_intel-add-missing-tty-device-sanity-check.patch b/queue-4.9/bluetooth-hci_intel-add-missing-tty-device-sanity-check.patch new file mode 100644 index 00000000000..95ff1b10937 --- /dev/null +++ b/queue-4.9/bluetooth-hci_intel-add-missing-tty-device-sanity-check.patch @@ -0,0 +1,74 @@ +From dcb9cfaa5ea9aa0ec08aeb92582ccfe3e4c719a9 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 29 Mar 2017 18:15:28 +0200 +Subject: Bluetooth: hci_intel: add missing tty-device sanity check + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.9/device-dax-fix-cdev-leak.patch b/queue-4.9/device-dax-fix-cdev-leak.patch new file mode 100644 index 00000000000..9faa2f0c3ae --- /dev/null +++ b/queue-4.9/device-dax-fix-cdev-leak.patch @@ -0,0 +1,70 @@ +From ed01e50acdd3e4a640cf9ebd28a7e810c3ceca97 Mon Sep 17 00:00:00 2001 +From: Dan Williams +Date: Fri, 17 Mar 2017 12:48:09 -0600 +Subject: device-dax: fix cdev leak + +From: Dan Williams + +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 +Signed-off-by: Dan Williams +Signed-off-by: Logan Gunthorpe +Reviewed-by: Johannes Thumshirn +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } diff --git a/queue-4.9/fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch b/queue-4.9/fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch new file mode 100644 index 00000000000..b5dee33e664 --- /dev/null +++ b/queue-4.9/fscrypt-fix-context-consistency-check-when-key-s-unavailable.patch @@ -0,0 +1,166 @@ +From 272f98f6846277378e1758a49a49d7bf39343c02 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Fri, 7 Apr 2017 10:58:37 -0700 +Subject: fscrypt: fix context consistency check when key(s) unavailable + +From: Eric Biggers + +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 +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.9/libata-reject-passthrough-write-same-requests.patch b/queue-4.9/libata-reject-passthrough-write-same-requests.patch new file mode 100644 index 00000000000..39aab8357d8 --- /dev/null +++ b/queue-4.9/libata-reject-passthrough-write-same-requests.patch @@ -0,0 +1,41 @@ +From c6ade20f5e50e188d20b711a618b20dd1d50457e Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Tue, 25 Apr 2017 13:39:54 +0200 +Subject: libata: reject passthrough WRITE SAME requests + +From: Christoph Hellwig + +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 +Reviewed-by: Martin K. Petersen +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.9/serial-omap-fix-runtime-pm-handling-on-unbind.patch b/queue-4.9/serial-omap-fix-runtime-pm-handling-on-unbind.patch new file mode 100644 index 00000000000..4fdb79c06ac --- /dev/null +++ b/queue-4.9/serial-omap-fix-runtime-pm-handling-on-unbind.patch @@ -0,0 +1,66 @@ +From 099bd73dc17ed77aa8c98323e043613b6e8f54fc Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Mon, 10 Apr 2017 11:21:38 +0200 +Subject: serial: omap: fix runtime-pm handling on unbind + +From: Johan Hovold + +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 +... +[] (serial_omap_set_mctrl) from [] (uart_update_mctrl+0x50/0x60) +[] (uart_update_mctrl) from [] (uart_shutdown+0xbc/0x138) +[] (uart_shutdown) from [] (uart_hangup+0x94/0x190) +[] (uart_hangup) from [] (__tty_hangup+0x404/0x41c) +[] (__tty_hangup) from [] (tty_vhangup+0x1c/0x20) +[] (tty_vhangup) from [] (uart_remove_one_port+0xec/0x260) +[] (uart_remove_one_port) from [] (serial_omap_remove+0x40/0x60) +[] (serial_omap_remove) from [] (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 +Cc: Santosh Shilimkar +Signed-off-by: Johan Hovold +Acked-by: Tony Lindgren +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.9/serial-omap-suspend-device-on-probe-errors.patch b/queue-4.9/serial-omap-suspend-device-on-probe-errors.patch new file mode 100644 index 00000000000..2d68f0f5b5a --- /dev/null +++ b/queue-4.9/serial-omap-suspend-device-on-probe-errors.patch @@ -0,0 +1,38 @@ +From 77e6fe7fd2b7cba0bf2f2dc8cde51d7b9a35bf74 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Mon, 10 Apr 2017 11:21:39 +0200 +Subject: serial: omap: suspend device on probe errors + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Acked-by: Tony Lindgren +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.9/serial-samsung-use-right-device-for-dma-mapping-calls.patch b/queue-4.9/serial-samsung-use-right-device-for-dma-mapping-calls.patch new file mode 100644 index 00000000000..2c14206f11f --- /dev/null +++ b/queue-4.9/serial-samsung-use-right-device-for-dma-mapping-calls.patch @@ -0,0 +1,78 @@ +From 768d64f491a530062ddad50e016fb27125f8bd7c Mon Sep 17 00:00:00 2001 +From: Marek Szyprowski +Date: Mon, 3 Apr 2017 08:20:59 +0200 +Subject: serial: samsung: Use right device for DMA-mapping calls + +From: Marek Szyprowski + +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) +[] (unwind_backtrace) from [] (show_stack+0x20/0x24) +[] (show_stack) from [] (dump_stack+0x84/0xa0) +[] (dump_stack) from [] (__warn+0x14c/0x180) +[] (__warn) from [] (warn_slowpath_fmt+0x48/0x50) +[] (warn_slowpath_fmt) from [] (check_sync+0x520/0x9f4) +[] (check_sync) from [] (debug_dma_sync_single_for_device+0x88/0xc8) +[] (debug_dma_sync_single_for_device) from [] (s3c24xx_serial_start_tx_dma+0x100/0x2f8) +[] (s3c24xx_serial_start_tx_dma) from [] (s3c24xx_serial_tx_chars+0x198/0x33c) + +Reported-by: Seung-Woo Kim +Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions") +Signed-off-by: Marek Szyprowski +Reviewed-by: Bartlomiej Zolnierkiewicz +Reviewed-by: Krzysztof Kozlowski +Reviewed-by: Shuah Khan +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.9/series b/queue-4.9/series index dbb82e4bca3..8c7eb061eee 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -63,3 +63,13 @@ cifs-fix-oplock-break-deadlocks.patch 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 diff --git a/queue-4.9/tty-pty-fix-ldisc-flush-after-userspace-become-aware-of-the-data-already.patch b/queue-4.9/tty-pty-fix-ldisc-flush-after-userspace-become-aware-of-the-data-already.patch new file mode 100644 index 00000000000..dafc9a4a375 --- /dev/null +++ b/queue-4.9/tty-pty-fix-ldisc-flush-after-userspace-become-aware-of-the-data-already.patch @@ -0,0 +1,83 @@ +From 77dae6134440420bac334581a3ccee94cee1c054 Mon Sep 17 00:00:00 2001 +From: Wang YanQing +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 + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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;