Linux Kernel 4.9.60 Release
Posted on In Linux, Linux KernelThis post summarizes Linux Kernel new features, bugfixes and changes in Linux 4.9.60 Release. Linux 4.9.60 Release contains 24 changes, patches or new features.
In total, there are 64,224 lines of Linux source code changed/added in Linux 4.9.60 release compared to Linux 4.9 release. To view the source code of Linux 4.9.60 kernel release online, please check the linux-stable tree for Linux 4.9.60. If you would like to download the release package for Linux 4.9.60, please click: Linux 4.9.60. To download the patchset for Linux 4.9.60 release, please click: Linux 4.9.60 patch.
All changes in this Linux release are as follows.
Table of Contents
Linux 4.9.60
This change “Linux 4.9.60” (commit 06b639e) in Linux kernel is authored by Greg Kroah-Hartman <gregkh [at] linuxfoundation.org> on Thu Nov 2 09:49:15 2017 +0100.
The change “Linux 4.9.60” introduces changes as follows.
Linux 4.9.60
The commit for this change in Linux stable tree is 06b639e (patch).
ecryptfs: fix dereference of NULL user_key_payload
This change “ecryptfs: fix dereference of NULL user_key_payload” (commit 4b86c48) in Linux kernel is authored by Eric Biggers <ebiggers [at] google.com> on Mon Oct 9 12:51:27 2017 -0700.
The change “ecryptfs: fix dereference of NULL user_key_payload” introduces changes as follows.
ecryptfs: fix dereference of NULL user_key_payload
commit f66665c09ab489a11ca490d6a82df57cfc1bea3e upstream.
In eCryptfs, we failed to verify that the authentication token keys are
not revoked before dereferencing their payloads, which is problematic
because the payload of a revoked key is NULL. request_key() *does* skip
revoked keys, but there is still a window where the key can be revoked
before we acquire the key semaphore.
Fix it by updating ecryptfs_get_key_payload_data() to return
-EKEYREVOKED if the key payload is NULL. For completeness we check this
for "encrypted" keys as well as "user" keys, although encrypted keys
cannot be revoked currently.
Alternatively we could use key_validate(), but since we'll also need to
fix ecryptfs_get_key_payload_data() to validate the payload length, it
seems appropriate to just check the payload pointer.
Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
Reviewed-by: James Morris <james.l.morris@oracle.com>
Cc: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 4b86c48 (patch).
regulator: fan53555: fix I2C device ids
This change “regulator: fan53555: fix I2C device ids” (commit bdcb6c9) in Linux kernel is authored by Guillaume Tucker <guillaume.tucker [at] collabora.com> on Mon Aug 21 13:47:43 2017 +0100.
The change “regulator: fan53555: fix I2C device ids” introduces changes as follows.
regulator: fan53555: fix I2C device ids
commit fc1111b885437f374ed54aadda44d8b241ebd2a3 upstream.
The device tree nodes all correctly describe the regulators as
syr827 or syr828, but the I2C device id is currently set to the
wildcard value of syr82x in the driver. This causes udev to fail
to match the driver module with the modalias data from sysfs.
Fix this by replacing the I2C device ids with ones that match the
device tree descriptions, with syr827 and syr828. Tested on
Firefly rk3288 board. The syr82x id was not used anywhere.
Fixes: e80c47bd738b (regulator: fan53555: Export I2C module alias information)
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is bdcb6c9 (patch).
ipsec: Fix aborted xfrm policy dump crash
This change “ipsec: Fix aborted xfrm policy dump crash” (commit 543aabb) in Linux kernel is authored by Herbert Xu <herbert [at] gondor.apana.org.au> on Thu Oct 19 20:51:10 2017 +0800.
The change “ipsec: Fix aborted xfrm policy dump crash” introduces changes as follows.
ipsec: Fix aborted xfrm policy dump crash
commit 1137b5e2529a8f5ca8ee709288ecba3e68044df2 upstream.
An independent security researcher, Mohamed Ghannam, has reported
this vulnerability to Beyond Security's SecuriTeam Secure Disclosure
program.
The xfrm_dump_policy_done function expects xfrm_dump_policy to
have been called at least once or it will crash. This can be
triggered if a dump fails because the target socket's receive
buffer is full.
This patch fixes it by using the cb->start mechanism to ensure that
the initialisation is always done regardless of the buffer situation.
Fixes: 12a169e7d8f4 ("ipsec: Put dumpers on the dump list")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 543aabb (patch).
cfg80211: fix connect/disconnect edge cases
This change “cfg80211: fix connect/disconnect edge cases” (commit bb46f79) in Linux kernel is authored by Johannes Berg <johannes.berg [at] intel.com> on Tue Oct 17 21:56:20 2017 +0200.
The change “cfg80211: fix connect/disconnect edge cases” introduces changes as follows.
cfg80211: fix connect/disconnect edge cases
commit 51e13359cd5ea34acc62c90627603352956380af upstream.
If we try to connect while already connected/connecting, but
this fails, we set ssid_len=0 but leave current_bss hanging,
leading to errors.
Check all of this better, first of all ensuring that we can't
try to connect to a different SSID while connected/ing; ensure
that prev_bssid is set for re-association attempts even in the
case of the driver supporting the connect() method, and don't
reset ssid_len in the failure cases.
While at it, also reset ssid_len while disconnecting unless we
were connected and expect a disconnected event, and warn on a
successful connection without ssid_len being set.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is bb46f79 (patch).
can: kvaser_usb: Ignore CMD_FLUSH_QUEUE_REPLY messages
This change “can: kvaser_usb: Ignore CMD_FLUSH_QUEUE_REPLY messages” (commit 7e31cde) in Linux kernel is authored by Jimmy Assarsson <jimmyassarsson [at] gmail.com> on Tue Oct 24 12:23:29 2017 +0200.
The change “can: kvaser_usb: Ignore CMD_FLUSH_QUEUE_REPLY messages” introduces changes as follows.
can: kvaser_usb: Ignore CMD_FLUSH_QUEUE_REPLY messages
commit e1d2d1329a5722dbecc9c278303fcc4aa01f8790 upstream.
To avoid kernel warning "Unhandled message (68)", ignore the
CMD_FLUSH_QUEUE_REPLY message for now.
As of Leaf v2 firmware version v4.1.844 (2017-02-15), flush tx queue is
synchronous. There is a capability bit indicating whether flushing tx
queue is synchronous or asynchronous.
A proper solution would be to query the device for capabilities. If the
synchronous tx flush capability bit is set, we should wait for
CMD_FLUSH_QUEUE_REPLY message, while flushing the tx queue.
Signed-off-by: Jimmy Assarsson <jimmyassarsson@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 7e31cde (patch).
can: kvaser_usb: Correct return value in printout
This change “can: kvaser_usb: Correct return value in printout” (commit 636e798) in Linux kernel is authored by Jimmy Assarsson <jimmyassarsson [at] gmail.com> on Tue Oct 24 12:23:28 2017 +0200.
The change “can: kvaser_usb: Correct return value in printout” introduces changes as follows.
can: kvaser_usb: Correct return value in printout
commit 8f65a923e6b628e187d5e791cf49393dd5e8c2f9 upstream.
If the return value from kvaser_usb_send_simple_msg() was non-zero, the
return value from kvaser_usb_flush_queue() was printed in the kernel
warning.
Signed-off-by: Jimmy Assarsson <jimmyassarsson@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 636e798 (patch).
can: sun4i: fix loopback mode
This change “can: sun4i: fix loopback mode” (commit c4fe13b) in Linux kernel is authored by Gerhard Bertelsmann <info [at] gerhard-bertelsmann.de> on Thu Aug 17 15:59:49 2017 +0200.
The change “can: sun4i: fix loopback mode” introduces changes as follows.
can: sun4i: fix loopback mode
commit 3a379f5b36ae039dfeb6f73316e47ab1af4945df upstream.
Fix loopback mode by setting the right flag and remove presume mode.
Signed-off-by: Gerhard Bertelsmann <info@gerhard-bertelsmann.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is c4fe13b (patch).
drm/amd/powerplay: fix uninitialized variable
This change “drm/amd/powerplay: fix uninitialized variable” (commit e6b5e3b) in Linux kernel is authored by Rex Zhu <Rex.Zhu [at] amd.com> on Fri Oct 20 15:07:41 2017 +0800.
The change “drm/amd/powerplay: fix uninitialized variable” introduces changes as follows.
drm/amd/powerplay: fix uninitialized variable
commit 8b95f4f730cba02ef6febbdc4ca7e55ca045b00e upstream.
refresh_rate was not initialized when program
display gap.
this patch can fix vce ring test failed
when do S3 on Polaris10.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=103102
bug: https://bugzilla.kernel.org/show_bug.cgi?id=196615
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is e6b5e3b (patch).
scsi: sg: Re-fix off by one in sg_fill_request_table()
This change “scsi: sg: Re-fix off by one in sg_fill_request_table()” (commit 5a0dbfe) in Linux kernel is authored by Ben Hutchings <ben.hutchings [at] codethink.co.uk> on Sun Oct 15 18:16:33 2017 +0100.
The change “scsi: sg: Re-fix off by one in sg_fill_request_table()” introduces changes as follows.
scsi: sg: Re-fix off by one in sg_fill_request_table()
commit 587c3c9f286cee5c9cac38d28c8ae1875f4ec85b upstream.
Commit 109bade9c625 ("scsi: sg: use standard lists for sg_requests")
introduced an off-by-one error in sg_ioctl(), which was fixed by commit
bd46fc406b30 ("scsi: sg: off by one in sg_ioctl()").
Unfortunately commit 4759df905a47 ("scsi: sg: factor out
sg_fill_request_table()") moved that code, and reintroduced the
bug (perhaps due to a botched rebase). Fix it again.
Fixes: 4759df905a47 ("scsi: sg: factor out sg_fill_request_table()")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 5a0dbfe (patch).
scsi: zfcp: fix erp_action use-before-initialize in REC action trace
This change “scsi: zfcp: fix erp_action use-before-initialize in REC action trace” (commit 88acde8) in Linux kernel is authored by Steffen Maier <maier [at] linux.vnet.ibm.com> on Fri Oct 13 15:40:07 2017 +0200.
The change “scsi: zfcp: fix erp_action use-before-initialize in REC action trace” introduces changes as follows.
scsi: zfcp: fix erp_action use-before-initialize in REC action trace
commit ab31fd0ce65ec93828b617123792c1bb7c6dcc42 upstream.
v4.10 commit 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN
recovery") extended accessing parent pointer fields of struct
zfcp_erp_action for tracing. If an erp_action has never been enqueued
before, these parent pointer fields are uninitialized and NULL. Examples
are zfcp objects freshly added to the parent object's children list,
before enqueueing their first recovery subsequently. In
zfcp_erp_try_rport_unblock(), we iterate such list. Accessing erp_action
fields can cause a NULL pointer dereference. Since the kernel can read
from lowcore on s390, it does not immediately cause a kernel page
fault. Instead it can cause hangs on trying to acquire the wrong
erp_action->adapter->dbf->rec_lock in zfcp_dbf_rec_action_lvl()
^bogus^
while holding already other locks with IRQs disabled.
Real life example from attaching lots of LUNs in parallel on many CPUs:
crash> bt 17723
PID: 17723 TASK: ... CPU: 25 COMMAND: "zfcperp0.0.1800"
LOWCORE INFO:
-psw : 0x0404300180000000 0x000000000038e424
-function : _raw_spin_lock_wait_flags at 38e424
...
#0 [fdde8fc90] zfcp_dbf_rec_action_lvl at 3e0004e9862 [zfcp]
#1 [fdde8fce8] zfcp_erp_try_rport_unblock at 3e0004dfddc [zfcp]
#2 [fdde8fd38] zfcp_erp_strategy at 3e0004e0234 [zfcp]
#3 [fdde8fda8] zfcp_erp_thread at 3e0004e0a12 [zfcp]
#4 [fdde8fe60] kthread at 173550
#5 [fdde8feb8] kernel_thread_starter at 10add2
zfcp_adapter
zfcp_port
zfcp_unit <address>, 0x404040d600000000
scsi_device NULL, returning early!
zfcp_scsi_dev.status = 0x40000000
0x40000000 ZFCP_STATUS_COMMON_RUNNING
crash> zfcp_unit <address>
struct zfcp_unit {
erp_action = {
adapter = 0x0,
port = 0x0,
unit = 0x0,
},
}
zfcp_erp_action is always fully embedded into its container object. Such
container object is never moved in its object tree (only add or delete).
Hence, erp_action parent pointers can never change.
To fix the issue, initialize the erp_action parent pointers before
adding the erp_action container to any list and thus before it becomes
accessible from outside of its initializing function.
In order to also close the time window between zfcp_erp_setup_act()
memsetting the entire erp_action to zero and setting the parent pointers
again, drop the memset and instead explicitly initialize individually
all erp_action fields except for parent pointers. To be extra careful
not to introduce any other unintended side effect, even keep zeroing the
erp_action fields for list and timer. Also double-check with
WARN_ON_ONCE that erp_action parent pointers never change, so we get to
know when we would deviate from previous behavior.
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 88acde8 (patch).
assoc_array: Fix a buggy node-splitting case
This change “assoc_array: Fix a buggy node-splitting case” (commit 67bcc5e) in Linux kernel is authored by David Howells <dhowells [at] redhat.com> on Wed Oct 11 23:32:27 2017 +0100.
The change “assoc_array: Fix a buggy node-splitting case” introduces changes as follows.
assoc_array: Fix a buggy node-splitting case
commit ea6789980fdaa610d7eb63602c746bf6ec70cd2b upstream.
This fixes CVE-2017-12193.
Fix a case in the assoc_array implementation in which a new leaf is
added that needs to go into a node that happens to be full, where the
existing leaves in that node cluster together at that level to the
exclusion of new leaf.
What needs to happen is that the existing leaves get moved out to a new
node, N1, at level + 1 and the existing node needs replacing with one,
N0, that has pointers to the new leaf and to N1.
The code that tries to do this gets this wrong in two ways:
(1) The pointer that should've pointed from N0 to N1 is set to point
recursively to N0 instead.
(2) The backpointer from N0 needs to be set correctly in the case N0 is
either the root node or reached through a shortcut.
Fix this by removing this path and using the split_node path instead,
which achieves the same end, but in a more general way (thanks to Eric
Biggers for spotting the redundancy).
The problem manifests itself as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: assoc_array_apply_edit+0x59/0xe5
Fixes: 3cb989501c26 ("Add a generic associative array implementation.")
Reported-and-tested-by: WU Fan <u3536072@connect.hku.hk>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 67bcc5e (patch).
Input: gtco – fix potential out-of-bound access
This change “Input: gtco – fix potential out-of-bound access” (commit 52f65e3) in Linux kernel is authored by Dmitry Torokhov <dmitry.torokhov [at] gmail.com> on Mon Oct 23 16:46:00 2017 -0700.
The change “Input: gtco – fix potential out-of-bound access” introduces changes as follows.
Input: gtco - fix potential out-of-bound access
commit a50829479f58416a013a4ccca791336af3c584c7 upstream.
parse_hid_report_descriptor() has a while (i < length) loop, which
only guarantees that there's at least 1 byte in the buffer, but the
loop body can read multiple bytes which causes out-of-bounds access.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 52f65e3 (patch).
Input: elan_i2c – add ELAN0611 to the ACPI table
This change “Input: elan_i2c – add ELAN0611 to the ACPI table” (commit 9460dd3) in Linux kernel is authored by Kai-Heng Feng <kai.heng.feng [at] canonical.com> on Tue Oct 24 11:08:18 2017 -0700.
The change “Input: elan_i2c – add ELAN0611 to the ACPI table” introduces changes as follows.
Input: elan_i2c - add ELAN0611 to the ACPI table
commit 57a95b41869b8f0d1949c24df2a9dac1ca7082ee upstream.
ELAN0611 touchpad uses elan_i2c as its driver. It can be found
on Lenovo ideapad 320-15IKB.
So add it to ACPI table to enable the touchpad.
[Ido Adiv <idoad123@gmail.com> reports that the same ACPI ID is used for
Elan touchpad in ideapad 520].
BugLink: https://bugs.launchpad.net/bugs/1723736
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 9460dd3 (patch).
xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()
This change “xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()” (commit d431d9f) in Linux kernel is authored by Juergen Gross <jgross [at] suse.com> on Wed Oct 25 17:08:07 2017 +0200.
The change “xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()” introduces changes as follows.
xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()
commit 298d275d4d9bea3524ff4bc76678c140611d8a8d upstream.
In case gntdev_mmap() succeeds only partially in mapping grant pages
it will leave some vital information uninitialized needed later for
cleanup. This will lead to an out of bounds array access when unmapping
the already mapped pages.
So just initialize the data needed for unmapping the pages a little bit
earlier.
Reported-by: Arthur Borsboom <arthurborsboom@gmail.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is d431d9f (patch).
fuse: fix READDIRPLUS skipping an entry
This change “fuse: fix READDIRPLUS skipping an entry” (commit 8783885) in Linux kernel is authored by Miklos Szeredi <mszeredi [at] redhat.com> on Wed Oct 25 16:34:27 2017 +0200.
The change “fuse: fix READDIRPLUS skipping an entry” introduces changes as follows.
fuse: fix READDIRPLUS skipping an entry
commit c6cdd51404b7ac12dd95173ddfc548c59ecf037f upstream.
Marios Titas running a Haskell program noticed a problem with fuse's
readdirplus: when it is interrupted by a signal, it skips one directory
entry.
The reason is that fuse erronously updates ctx->pos after a failed
dir_emit().
The issue originates from the patch adding readdirplus support.
Reported-by: Jakob Unterwurzacher <jakobunt@gmail.com>
Tested-by: Marios Titas <redneb@gmx.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: 0b05b18381ee ("fuse: implement NFS-like readdirplus support")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 8783885 (patch).
spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path
This change “spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path” (commit d8e5f2f) in Linux kernel is authored by Florian Fainelli <f.fainelli [at] gmail.com> on Wed Oct 11 14:59:22 2017 -0700.
The change “spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path” introduces changes as follows.
spi: bcm-qspi: Fix use after free in bcm_qspi_probe() in error path
commit c0368e4db4a3e8a3dce40f3f621c06e14c560d79 upstream.
There was an inversion in how the error path in bcm_qspi_probe() is done
which would make us trip over a KASAN use-after-free report. Turns out
that qspi->dev_ids does not get allocated until later in the probe
process. Fix this by introducing a new lable: qspi_resource_err which
takes care of cleaning up the SPI master instance.
Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is d8e5f2f (patch).
spi: uapi: spidev: add missing ioctl header
This change “spi: uapi: spidev: add missing ioctl header” (commit 1dfea1e) in Linux kernel is authored by Baruch Siach <baruch [at] tkos.co.il> on Sun Sep 10 20:29:45 2017 +0300.
The change “spi: uapi: spidev: add missing ioctl header” introduces changes as follows.
spi: uapi: spidev: add missing ioctl header
commit a2b4a79b88b24c49d98d45a06a014ffd22ada1a4 upstream.
The SPI_IOC_MESSAGE() macro references _IOC_SIZEBITS. Add linux/ioctl.h
to make sure this macro is defined. This fixes the following build
failure of lcdproc with the musl libc:
In file included from .../sysroot/usr/include/sys/ioctl.h:7:0,
from hd44780-spi.c:31:
hd44780-spi.c: In function 'spi_transfer':
hd44780-spi.c:89:24: error: '_IOC_SIZEBITS' undeclared (first use in this function)
status = ioctl(p->fd, SPI_IOC_MESSAGE(1), &xfer);
^
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 1dfea1e (patch).
KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM
This change “KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM” (commit 474cb9e) in Linux kernel is authored by Greg Kurz <groug [at] kaod.org> on Thu Sep 14 23:56:25 2017 +0200.
The change “KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM” introduces changes as follows.
KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM
commit ac64115a66c18c01745bbd3c47a36b124e5fd8c0 upstream.
The following program causes a kernel oops:
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/kvm.h>
main()
{
int fd = open("/dev/kvm", O_RDWR);
ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM);
}
This happens because when using the global KVM fd with
KVM_CHECK_EXTENSION, kvm_vm_ioctl_check_extension() gets
called with a NULL kvm argument, which gets dereferenced
in is_kvmppc_hv_enabled(). Spotted while reading the code.
Let's use the hv_enabled fallback variable, like everywhere
else in this function.
Fixes: 23528bb21ee2 ("KVM: PPC: Introduce KVM_CAP_PPC_HTM")
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 474cb9e (patch).
usb: xhci: Handle error condition in xhci_stop_device()
This change “usb: xhci: Handle error condition in xhci_stop_device()” (commit 659b04a) in Linux kernel is authored by Mayank Rana <mrana [at] codeaurora.org> on Fri Oct 6 17:45:30 2017 +0300.
The change “usb: xhci: Handle error condition in xhci_stop_device()” introduces changes as follows.
usb: xhci: Handle error condition in xhci_stop_device()
commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd upstream.
xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.
Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 659b04a (patch).
ceph: unlock dangling spinlock in try_flush_caps()
This change “ceph: unlock dangling spinlock in try_flush_caps()” (commit a703da4) in Linux kernel is authored by Jeff Layton <jlayton [at] redhat.com> on Thu Oct 19 08:52:58 2017 -0400.
The change “ceph: unlock dangling spinlock in try_flush_caps()” introduces changes as follows.
ceph: unlock dangling spinlock in try_flush_caps()
commit 6c2838fbdedb9b72a81c931d49e56b229b6cdbca upstream.
sparse warns:
fs/ceph/caps.c:2042:9: warning: context imbalance in 'try_flush_caps' - wrong count at exit
We need to exit this function with the lock unlocked, but a couple of
cases leave it locked.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: "Yan, Zheng" <zyan@redhat.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is a703da4 (patch).
ALSA: hda – fix headset mic problem for Dell machines with alc236
This change “ALSA: hda – fix headset mic problem for Dell machines with alc236” (commit 41f804d) in Linux kernel is authored by Hui Wang <hui.wang [at] canonical.com> on Tue Oct 24 16:53:34 2017 +0800.
The change “ALSA: hda – fix headset mic problem for Dell machines with alc236” introduces changes as follows.
ALSA: hda - fix headset mic problem for Dell machines with alc236
commit f265788c336979090ac80b9ae173aa817c4fe40d upstream.
We have several Dell laptops which use the codec alc236, the headset
mic can't work on these machines. Following the commit 736f20a70, we
add the pin cfg table to make the headset mic work.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 41f804d (patch).
ALSA: hda/realtek – Add support for ALC236/ALC3204
This change “ALSA: hda/realtek – Add support for ALC236/ALC3204” (commit 61ae3fb) in Linux kernel is authored by Kailang Yang <kailang [at] realtek.com> on Fri Oct 20 15:06:34 2017 +0800.
The change “ALSA: hda/realtek – Add support for ALC236/ALC3204” introduces changes as follows.
ALSA: hda/realtek - Add support for ALC236/ALC3204
commit 736f20a7060857ff569e9e9586ae6c1204a73e07 upstream.
Add support for ALC236/ALC3204.
Add headset mode support for ALC236/ALC3204.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit for this change in Linux stable tree is 61ae3fb (patch).
workqueue: replace pool->manager_arb mutex with a flag
This change “workqueue: replace pool->manager_arb mutex with a flag” (commit 43a980a) in Linux kernel is authored by Tejun Heo <tj [at] kernel.org> on Mon Oct 9 08:04:13 2017 -0700.
The change “workqueue: replace pool->manager_arb mutex with a flag” introduces changes as follows.
workqueue: replace pool->manager_arb mutex with a flag
commit 692b48258dda7c302e777d7d5f4217244478f1f6 upstream.
Josef reported a HARDIRQ-safe -> HARDIRQ-unsafe lock order detected by
lockdep:
[ 1270.472259] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 1270.472783] 4.14.0-rc1-xfstests-12888-g76833e8 #110 Not tainted
[ 1270.473240] -----------------------------------------------------
[ 1270.473710] kworker/u5:2/5157 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 1270.474239] (&(&lock->wait_lock)->rlock){+.+.}, at: [<ffffffff8da253d2>] __mutex_unlock_slowpath+0xa2/0x280
[ 1270.474994]
[ 1270.474994] and this task is already holding:
[ 1270.475440] (&pool->lock/1){-.-.}, at: [<ffffffff8d2992f6>] worker_thread+0x366/0x3c0
[ 1270.476046] which would create a new lock dependency:
[ 1270.476436] (&pool->lock/1){-.-.} -> (&(&lock->wait_lock)->rlock){+.+.}
[ 1270.476949]
[ 1270.476949] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 1270.477553] (&pool->lock/1){-.-.}
...
[ 1270.488900] to a HARDIRQ-irq-unsafe lock:
[ 1270.489327] (&(&lock->wait_lock)->rlock){+.+.}
...
[ 1270.494735] Possible interrupt unsafe locking scenario:
[ 1270.494735]
[ 1270.495250] CPU0 CPU1
[ 1270.495600] ---- ----
[ 1270.495947] lock(&(&lock->wait_lock)->rlock);
[ 1270.496295] local_irq_disable();
[ 1270.496753] lock(&pool->lock/1);
[ 1270.497205] lock(&(&lock->wait_lock)->rlock);
[ 1270.497744] <Interrupt>
[ 1270.497948] lock(&pool->lock/1);
, which will cause a irq inversion deadlock if the above lock scenario
happens.
The root cause of this safe -> unsafe lock order is the
mutex_unlock(pool->manager_arb) in manage_workers() with pool->lock
held.
Unlocking mutex while holding an irq spinlock was never safe and this
problem has been around forever but it never got noticed because the
only time the mutex is usually trylocked while holding irqlock making
actual failures very unlikely and lockdep annotation missed the
condition until the recent b9c16a0e1f73 ("locking/mutex: Fix
lockdep_assert_held() fail").
Using mutex for pool->manager_arb has always been a bit of stretch.
It primarily is an mechanism to arbitrate managership between workers
which can easily be done with a pool flag. The only reason it became
a mutex is that pool destruction path wants to exclude parallel
managing operations.
This patch replaces the mutex with a new pool flag POOL_MANAGER_ACTIVE
and make the destruction path wait for the current manager on a wait
queue.
v2: Drop unnecessary flag clearing before pool destruction as
suggested by Boqun.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>The commit for this change in Linux stable tree is 43a980a (patch).
