4.4.98-stable review
Subsystems (3)
Greg Kroah-Hartman
maintainercover 4.4.98-stable review
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.98-rc1
Colin Ian King <[email protected]>
PKCS#7: fix unitialized boolean 'want'
Borislav Petkov <[email protected]>
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
Richard Schütz <[email protected]>
can: c_can: don't indicate triple sampling support for D_CAN
Gerhard Bertelsmann <[email protected]>
can: sun4i: handle overrun in RX FIFO
Ilya Dryomov <[email protected]>
rbd: use GFP_NOIO for parent stat and data requests
Sinclair Yeh <[email protected]>
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
Kai-Heng Feng <[email protected]>
Input: elan_i2c - add ELAN060C to the ACPI table
Oswald Buddenhagen <[email protected]>
MIPS: AR7: Ensure that serial ports are properly set up
Jonas Gorski <[email protected]>
MIPS: AR7: Defer registration of GPIO
Luis R. Rodriguez <[email protected]>
tools: firmware: check for distro fallback udev cancel rule
Luis R. Rodriguez <[email protected]>
selftests: firmware: send expected errors to /dev/null
Brian Norris <[email protected]>
selftests: firmware: add empty string and async tests
Brian Norris <[email protected]>
test: firmware_class: report errors properly on failure
Matt Redfearn <[email protected]>
MIPS: SMP: Fix deadlock & online race
Matija Glavinic Pecotic <[email protected]>
MIPS: Fix race on setting and getting cpu_online_mask
Matt Redfearn <[email protected]>
MIPS: SMP: Use a completion event to signal CPU up
Paul Burton <[email protected]>
MIPS: Fix CM region target definitions
Gustavo A. R. Silva <[email protected]>
MIPS: microMIPS: Fix incorrect mask in insn_table_MM
Takashi Iwai <[email protected]>
ALSA: seq: Avoid invalid lockdep class warning
Takashi Iwai <[email protected]>
ALSA: seq: Fix OSS sysex delivery in OSS emulation
Mark Rutland <[email protected]>
ARM: 8720/1: ensure dump_instr() checks addr_limit
Eric Biggers <[email protected]>
KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]
Andrey Ryabinin <[email protected]>
crypto: x86/sha1-mb - fix panic due to unaligned access
Li Bin <[email protected]>
workqueue: Fix NULL pointer dereference
Peter Zijlstra <[email protected]>
x86/uaccess, sched/preempt: Verify access_ok() context
Carlo Caione <[email protected]>
platform/x86: hp-wmi: Do not shadow error values
Carlo Caione <[email protected]>
platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state
Eric Biggers <[email protected]>
KEYS: trusted: fix writing past end of buffer in trusted_read()
Eric Biggers <[email protected]>
KEYS: trusted: sanitize all key material
Enrico Mioso <[email protected]>
cdc_ncm: Set NTB format again after altsetting switch for Huawei devices
Carlo Caione <[email protected]>
platform/x86: hp-wmi: Fix detection for dock and tablet mode
Vivien Didelot <[email protected]>
net: dsa: select NET_SWITCHDEV
Julian Wiedmann <[email protected]>
s390/qeth: issue STARTLAN as first IPA command
Feras Daoud <[email protected]>
IB/ipoib: Change list_del to list_del_init in the tx object
Akinobu Mita <[email protected]>
Input: mpr121 - set missing event capability
Akinobu Mita <[email protected]>
Input: mpr121 - handle multiple bits change of status register
Gilad Ben-Yossef <[email protected]>
IPsec: do not ignore crypto err in ah4 input
Liping Zhang <[email protected]>
netfilter: nft_meta: deal with PACKET_LOOPBACK in netdev family
William wu <[email protected]>
usb: hcd: initialize hcd->flags to 0 when rm hcd
Laurent Pinchart <[email protected]>
serial: sh-sci: Fix register offsets for the IRDA serial port
Volodymyr Bendiuga <[email protected]>
phy: increase size of MII_BUS_ID_SIZE and bus_id
David Lechner <[email protected]>
dt-bindings: Add vendor prefix for LEGO
David Lechner <[email protected]>
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Alison Schofield <[email protected]>
iio: trigger: free trigger resource correctly
Li Zhong <[email protected]>
crypto: vmx - disable preemption to enable vsx in aes_ctr.c
Tony Lindgren <[email protected]>
ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
Valentin Longchamp <[email protected]>
powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
Nate Watterson <[email protected]>
iommu/arm-smmu-v3: Clear prior settings when updating STEs
Li Zhong <[email protected]>
KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter
Noralf Trønnes <[email protected]>
drm: drm_minor_register(): Clean up debugfs on failure
Harninder Rai <[email protected]>
dt-bindings: clockgen: Add compatible string for LS1012A
Patrick Bruenn <[email protected]>
ARM: dts: imx53-qsb-common: fix FEC pinmux config
Juergen Gross <[email protected]>
xen/netback: set default upper limit of tx/rx queues to 8
Jason Gunthorpe <[email protected]>
PCI: mvebu: Handle changes to the bridge windows while enabled
Maciej W. Rozycki <[email protected]>
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
Lars-Peter Clausen <[email protected]>
adv7604: Initialize drive strength to default when using DT
-------------
Diffstat:
Documentation/devicetree/bindings/arm/davinci.txt | 4 + .../devicetree/bindings/clock/qoriq-clock.txt | 1 + .../devicetree/bindings/vendor-prefixes.txt | 1 + Makefile | 4 +- arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++-- arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/kernel/traps.c | 28 ++++-- arch/mips/ar7/platform.c | 5 + arch/mips/ar7/prom.c | 2 - arch/mips/include/asm/mips-cm.h | 4 +- arch/mips/kernel/process.c | 4 +- arch/mips/kernel/smp.c | 29 ++++-- arch/mips/mm/uasm-micromips.c | 2 +- arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 + arch/powerpc/kvm/book3s_hv_rm_xics.c | 5 +- arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 - arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 12 +-- arch/x86/include/asm/uaccess.h | 14 ++- arch/x86/oprofile/op_model_ppro.c | 4 +- crypto/asymmetric_keys/pkcs7_parser.c | 2 +- drivers/block/rbd.c | 4 +- drivers/crypto/vmx/aes_ctr.c | 6 ++ drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/iio/trigger/iio-trig-interrupt.c | 8 +- drivers/iio/trigger/iio-trig-sysfs.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- drivers/input/keyboard/mpr121_touchkey.c | 24 +++-- drivers/input/mouse/elan_i2c_core.c | 1 + drivers/iommu/arm-smmu-v3.c | 10 +- drivers/media/i2c/adv7604.c | 3 + drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - drivers/net/can/sun4i_can.c | 12 ++- drivers/net/usb/cdc_ncm.c | 28 ++++++ drivers/net/usb/huawei_cdc_ncm.c | 6 ++ drivers/net/xen-netback/netback.c | 6 +- drivers/pci/host/pci-mvebu.c | 101 ++++++++++++--------- drivers/platform/x86/hp-wmi.c | 60 +++++++----- drivers/s390/net/qeth_core.h | 1 - drivers/s390/net/qeth_core_main.c | 21 ++++- drivers/s390/net/qeth_l2_main.c | 15 --- drivers/s390/net/qeth_l3_main.c | 15 --- drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 +- drivers/tty/serial/sh-sci.c | 17 ++-- drivers/usb/core/hcd.c | 1 + drivers/video/fbdev/pmag-ba-fb.c | 2 +- include/linux/phy.h | 8 +- include/linux/preempt.h | 21 +++-- include/linux/usb/cdc_ncm.h | 1 + include/sound/seq_kernel.h | 3 +- kernel/workqueue_internal.h | 3 +- lib/asn1_decoder.c | 4 +- lib/test_firmware.c | 11 ++- net/dsa/Kconfig | 5 +- net/ipv4/ah4.c | 3 + net/netfilter/nft_meta.c | 28 +++++- security/keys/trusted.c | 71 +++++++-------- sound/core/seq/oss/seq_oss_midi.c | 4 +- sound/core/seq/oss/seq_oss_readq.c | 29 ++++++ sound/core/seq/oss/seq_oss_readq.h | 2 + tools/testing/selftests/firmware/fw_filesystem.sh | 10 +- tools/testing/selftests/firmware/fw_userhelper.sh | 28 +++++- 63 files changed, 468 insertions(+), 265 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 2/56 video: fbdev: pmag-ba-fb: Remove bad `__init annotation
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Maciej W. Rozycki" <[email protected]>
[ Upstream commit 879e5a0df626f39cbb3c61bb90373e56d67012c4 ]
Fix:
WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor() The function pmagbafb_probe()
references the function __init pmagbafb_erase_cursor().
This is often because pmagbafb_probe lacks a __init
annotation or the annotation of pmagbafb_erase_cursor is wrong.
-- a fallout from a missed update from commit 9625b51350cc ("VIDEO:
PMAG-BA: Fix section mismatch") and then commit 48c68c4f1b54 ("Drivers:
video: remove __dev* attributes.")
--- drivers/video/fbdev/pmag-ba-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/fbdev/pmag-ba-fb.c +1 -1
@@ -129,7 +129,7 @@ static struct fb_ops pmagbafb_ops = {/* * Turn the hardware cursor off. */ -static void __init pmagbafb_erase_cursor (struct fb_info *info) +static void pmagbafb_erase_cursor (struct fb_info *info) {struct pmagbafb_par *par = info->par;
Greg Kroah-Hartman
maintainerPATCH 3/56 PCI: mvebu: Handle changes to the bridge windows while enabled
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gunthorpe <[email protected]>
[ Upstream commit d9bf28e2650fe3eeefed7e34841aea07d10c6543 ]
The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like this:
mvebu_mbus: cannot add window '4:e8', conflicts with another window
mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22
For me this is happening during a hotplug cycle. The PCI core is not changing the values, just writing them twice while active.
The patch addresses the general case of any change to an active window, but not atomically. The code is slightly refactored so io and mem can share more of the window logic.
--- drivers/pci/host/pci-mvebu.c | 101 +++++++++++++++++++++++++------------------ 1 file changed, 60 insertions(+), 41 deletions(-)
drivers/pci/host/pci-mvebu.c +60 -41
@@ -131,6 +131,12 @@ struct mvebu_pcie {int nports; }; +struct mvebu_pcie_window { +phys_addr_t base; +phys_addr_t remap; +size_t size; +}; +/* Structure representing one PCIe interface */ struct mvebu_pcie_port {char *name;
@@ -148,10 +154,8 @@ struct mvebu_pcie_port {struct mvebu_sw_pci_bridge bridge;struct device_node *dn;struct mvebu_pcie *pcie; -phys_addr_t memwin_base; -size_t memwin_size; -phys_addr_t iowin_base; -size_t iowin_size; +struct mvebu_pcie_window memwin; +struct mvebu_pcie_window iowin;u32 saved_pcie_stat; };
@@ -377,23 +381,45 @@ static void mvebu_pcie_add_windows(struc } } +static void mvebu_pcie_set_window (struct mvebu_pcie_port *port, +unsigned int target,unsigned int attribute, +const struct mvebu_pcie_window *desired, +struct mvebu_pcie_window *cur) +{ +if (desired->base == cur->base && desired->remap == cur->remap && + desired->size == cur->size) +return ; + +if (cur->size !=0 ) { +mvebu_pcie_del_windows (port, cur->base, cur->size); + cur->size =0 ; + cur->base =0 ; + +/* +* If something tries to change the window while it is enabled +* the change will not be done atomically. That would be +* difficult to do in the general case. +*/ + } + +if (desired->size ==0 ) +return ; + +mvebu_pcie_add_windows (port, target, attribute, desired->base, + desired->size, desired->remap); + *cur = *desired; +} +static void mvebu_pcie_handle_iobase_change (struct mvebu_pcie_port *port) { -phys_addr_t iobase; +struct mvebu_pcie_window desired = {};/* Are the new iobase/iolimit values invalid? */ if (port->bridge.iolimit < port->bridge.iobase || port->bridge.iolimitupper < port->bridge.iobaseupper || !(port->bridge.command &PCI_COMMAND_IO )) { - -/* If a window was configured, remove it */ -if (port->iowin_base) { -mvebu_pcie_del_windows (port, port->iowin_base, - port->iowin_size); - port->iowin_base =0 ; - port->iowin_size =0 ; - } - +mvebu_pcie_set_window (port, port->io_target, port->io_attr, + &desired, &port->iowin);return ; }
@@ -410,32 +436,27 @@ static void mvebu_pcie_handle_iobase_cha* specifications. iobase is the bus address, port->iowin_base * is the CPU address. */ - iobase = ((port->bridge.iobase &0xF0 ) <<8 ) | - (port->bridge.iobaseupper <<16 ); - port->iowin_base = port->pcie->io.start + iobase; - port->iowin_size = ((0xFFF | ((port->bridge.iolimit &0xF0 ) <<8 ) | - (port->bridge.iolimitupper <<16 )) - - iobase) +1 ; - -mvebu_pcie_add_windows (port, port->io_target, port->io_attr, - port->iowin_base, port->iowin_size, - iobase); + desired.remap = ((port->bridge.iobase &0xF0 ) <<8 ) | + (port->bridge.iobaseupper <<16 ); + desired.base = port->pcie->io.start + desired.remap; + desired.size = ((0xFFF | ((port->bridge.iolimit &0xF0 ) <<8 ) | + (port->bridge.iolimitupper <<16 )) - + desired.remap) + +1 ; + +mvebu_pcie_set_window (port, port->io_target, port->io_attr, &desired, + &port->iowin); }static void mvebu_pcie_handle_membase_change (struct mvebu_pcie_port *port) { +struct mvebu_pcie_window desired = {.remap =MVEBU_MBUS_NO_REMAP }; +/* Are the new membase/memlimit values invalid? */ if (port->bridge.memlimit < port->bridge.membase || !(port->bridge.command &PCI_COMMAND_MEMORY )) { - -/* If a window was configured, remove it */ -if (port->memwin_base) { -mvebu_pcie_del_windows (port, port->memwin_base, - port->memwin_size); - port->memwin_base =0 ; - port->memwin_size =0 ; - } - +mvebu_pcie_set_window (port, port->mem_target, port->mem_attr, + &desired, &port->memwin);return ; }
@@ -445,14 +466,12 @@ static void mvebu_pcie_handle_membase_ch* window to setup, according to the PCI-to-PCI bridge * specifications. */ - port->memwin_base = ((port->bridge.membase &0xFFF0 ) <<16 ); - port->memwin_size = - (((port->bridge.memlimit &0xFFF0 ) <<16 ) |0xFFFFF ) - - port->memwin_base +1 ; - -mvebu_pcie_add_windows (port, port->mem_target, port->mem_attr, - port->memwin_base, port->memwin_size, -MVEBU_MBUS_NO_REMAP ); + desired.base = ((port->bridge.membase &0xFFF0 ) <<16 ); + desired.size = (((port->bridge.memlimit &0xFFF0 ) <<16 ) |0xFFFFF ) - + desired.base +1 ; + +mvebu_pcie_set_window (port, port->mem_target, port->mem_attr, &desired, + &port->memwin); }/*
Greg Kroah-Hartman
maintainerPATCH 4/56 xen/netback: set default upper limit of tx/rx queues to 8
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
[ Upstream commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ]
The default for the maximum number of tx/rx queues of one interface is the number of cpus of the system today. As each queue pair reserves 512 grant pages this default consumes a ridiculous number of grants for large guests.
Limit the queue number to 8 as default. This value can be modified via a module parameter if required.
--- drivers/net/xen-netback/netback.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/xen-netback/netback.c +4 -2
@@ -67,6 +67,7 @@ module_param(rx_drain_timeout_msecs, uinunsigned int rx_stall_timeout_msecs =60000 ;module_param (rx_stall_timeout_msecs, uint,0444 ); +#define MAX_QUEUES_DEFAULT 8unsigned int xenvif_max_queues;module_param_named (max_queues, xenvif_max_queues, uint,0644 ); MODULE_PARM_DESC(max_queues,
@@ -2157,11 +2158,12 @@ static int __init netback_init(void)if (!xen_domain ())return -ENODEV ; -/* Allow as many queues as there are CPUs if user has not +/* Allow as many queues as there are CPUs but max. 8 if user has not * specified a value. */ if (xenvif_max_queues ==0 ) - xenvif_max_queues =num_online_cpus (); + xenvif_max_queues = min_t(unsigned int, MAX_QUEUES_DEFAULT, +num_online_cpus ());if (fatal_skb_slots <XEN_NETBK_LEGACY_SLOTS_MAX ) { pr_info("fatal_skb_slots too small (%d), bump it to XEN_NETBK_LEGACY_SLOTS_MAX (%d)\n",
Greg Kroah-Hartman
maintainerPATCH 5/56 ARM: dts: imx53-qsb-common: fix FEC pinmux config
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Bruenn <[email protected]>
[ Upstream commit 8b649e426336d7d4800ff9c82858328f4215ba01 ]
The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c
All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too.
--- arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
arch/arm/boot/dts/imx53-qsb-common.dtsi +10 -10
@@ -215,16 +215,16 @@ pinctrl_fec: fecgrp { fsl,pins = < - MX53_PAD_FEC_MDC__FEC_MDC 0x80000000 - MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000 - MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000 - MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000 - MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000 - MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000 - MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000 - MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000 - MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000 - MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000 + MX53_PAD_FEC_MDC__FEC_MDC 0x4 + MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc + MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180 + MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180 + MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180 + MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180 + MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180 + MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4 + MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4 + MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4 >; };
Re: [PATCH 4.4 05/56] ARM: dts: imx53-qsb-common: fix FEC pinmux config
Quoted 9 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Bruenn <[email protected]>
[ Upstream commit
8b649e426336d7d4800ff9c82858328f4215ba01]
Quoted 7 lines
The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c
All pins were configured asNO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too.
[...]
Presumably u-boot will reuse the *upstream* device tree files, which implies this doesn't need to be fixed on stable branches.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
RE: [PATCH 4.4 05/56] ARM: dts: imx53-qsb-common: fix FEC pinmux config
Quoted 18 lines
From: Ben Hutchings [mailto:[email protected]]
Sent: Dienstag, 14. November 2017 16:45Quoted 9 lines
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Bruenn <[email protected]>
[ Upstream commit
8b649e426336d7d4800ff9c82858328f4215ba01]Quoted 7 lines
The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c
All pins were configured asNO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too.
Quoted 6 lines
[...]
Presumably u-boot will reuse the *upstream* device tree files, which implies this doesn't need to be fixed on stable branches.
Ben.
I think Ben made a good point. It might be dangerous to change the pinmux configuration for an Ethernet controller in stable kernels, just in case anyone out there uses a hardware and bootloader with different muxing. Shawn might be able to tell, if that is even possible.
In case there is at least a chance someone is using a different configuration, I wouldn't backport this commit to any stable branch.
Regards,
Patrick
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 05/56] ARM: dts: imx53-qsb-common: fix FEC pinmux config
Quoted 23 lines · Patrick Br�nn
Quoted 23 lines
From: Ben Hutchings [mailto:[email protected]]
Sent: Dienstag, 14. November 2017 16:45Quoted 9 lines
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Bruenn <[email protected]>
[ Upstream commit
8b649e426336d7d4800ff9c82858328f4215ba01]Quoted 7 lines
The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c
All pins were configured asNO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us.
But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too.[...]
Presumably u-boot will reuse the *upstream* device tree files, which implies this doesn't need to be fixed on stable branches.
Quoted 7 lines
Quoted 1 line
Ben.
I think Ben made a good point. It might be dangerous to change the pinmux configuration for an Ethernet controller in stable kernels, just in case anyone out there uses a hardware and bootloader with different muxing. Shawn might be able to tell, if that is even possible.
In case there is at least a chance someone is using a different configuration, I wouldn't backport this commit to any stable branch.
Ok, thanks, now dropped from the 4.4-stable queue.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 6/56 dt-bindings: clockgen: Add compatible string for LS1012A
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harninder Rai <[email protected]>
[ Upstream commit 73447f68d7b2bc1df870da88b0e21d2bc1afc025 ]
--- Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/clock/qoriq-clock.txt +1 -0
@@ -31,6 +31,7 @@ Required properties: * "fsl,t4240-clockgen" * "fsl,b4420-clockgen" * "fsl,b4860-clockgen" + * "fsl,ls1012a-clockgen" * "fsl,ls1021a-clockgen" Chassis-version clock strings include: * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
Re: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 23 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harninder Rai <[email protected]>
[ Upstream commit
73447f68d7b2bc1df870da88b0e21d2bc1afc025]Signed-off-by Harninder Rai <[email protected]>Signed-off-by Bhaskar Upadhaya <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Shawn Guo <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 +1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/clock/qoriq-clock.txt Required properties: · line 34
Quoted 4 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt +1
-0@@ -31,6 +31,7 @@ Required properties: * "fsl,t4240-clockgen" * "fsl,b4420-clockgen" * "fsl,b4860-clockgen" + * "fsl,ls1012a-clockgen"
This isn't supported or used anywhere in 4.4, so it makes sense to document it.
Ben.
Quoted 6 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt +0
-0* "fsl,ls1021a-clockgen"Chassis-version clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 21 lines · Ben Hutchings
Quoted 20 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me know.
------------------
From: Harninder Rai <[email protected]>
[ Upstream commit
73447f68d7b2bc1df870da88b0e21d2bc1afc025]Signed-off-by Harninder Rai <[email protected]>Signed-off-by Bhaskar Upadhaya <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Shawn Guo <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�Documentation/devicetree/bindings/clock/qoriq-clock.txt |����1 + �1 file changed, 1 insertion(+)
Quoted 10 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt Required properties: · line 34
Quoted 7 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt +0
-0@@ -31,6 +31,7 @@ Required properties:� * "fsl,t4240-clockgen"
� * "fsl,b4420-clockgen"
� * "fsl,b4860-clockgen"Documentation/devicetree/bindings/clock/qoriq-clock.txt +1
-0+ * "fsl,ls1012a-clockgen"This isn't supported or used anywhere in 4.4, so it makes sense to document it.
It "does" or "does not" make sense? Should I drop this patch?
confused,
greg k-h
Re: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 34 lines · Greg Kroah-Hartman
Quoted 22 lines · Ben Hutchings
Quoted 21 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me
know.------------------
From: Harninder Rai <[email protected]>
[ Upstream commit
73447f68d7b2bc1df870da88b0e21d2bc1afc025]Signed-off-by Harninder Rai <[email protected]>Signed-off-by Bhaskar Upadhaya <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Shawn Guo <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 +1 file changed, 1 insertion(+)Quoted 10 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt Required properties: · line 34
Quoted 7 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt +1
-0@@ -31,6 +31,7 @@ Required properties: * "fsl,t4240-clockgen" * "fsl,b4420-clockgen" * "fsl,b4860-clockgen" + * "fsl,ls1012a-clockgen"This isn't supported or used anywhere in 4.4, so it makes sense to document it.
Quoted 1 line
It "does" or "does not" make sense? Should I drop this patch?
Sorry, it does not make sense to document it so please drop this.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 35 lines · Ben Hutchings
Quoted 34 lines · Greg Kroah-Hartman
Quoted 32 lines · Ben Hutchings
Quoted 27 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me
know.------------------
From: Harninder Rai <[email protected]>
[ Upstream commit
73447f68d7b2bc1df870da88b0e21d2bc1afc025]Signed-off-by Harninder Rai <[email protected]>Signed-off-by Bhaskar Upadhaya <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Shawn Guo <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�Documentation/devicetree/bindings/clock/qoriq-clock.txt |����1 + �1 file changed, 1 insertion(+)Documentation/devicetree/bindings/clock/qoriq-clock.txt +0
-0@@ -31,6 +31,7 @@ Required properties:� * "fsl,t4240-clockgen"
� * "fsl,b4420-clockgen"
� * "fsl,b4860-clockgen"Documentation/devicetree/bindings/clock/qoriq-clock.txt Required properties: · line 34
Quoted 1 line
Documentation/devicetree/bindings/clock/qoriq-clock.txt +1
-0+ * "fsl,ls1012a-clockgen"This isn't supported or used anywhere in 4.4, so it makes sense to document it.
Quoted 3 lines
Quoted 1 line
It "does" or "does not" make sense?��Should I drop this patch?
Sorry, it does not make sense to document it so please drop this.
Now dropped, thanks.
greg k-h
RE: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
In reply to Greg Kroah-Hartman-----Original Message-----
From: Greg Kroah-Hartman [mailto:[email protected]]
Sent: Wednesday, November 15, 2017 8:46 PM
To: Ben Hutchings <[email protected]>
Cc: [email protected]; [email protected]; Harninder Rai <[email protected]>; Bhaskar Upadhaya <[email protected]>; Rob Herring <[email protected]>; Shawn Guo <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 21 lines · Ben Hutchings
Quoted 20 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harninder Rai <[email protected]>
[ Upstream commit
73447f68d7b2bc1df870da88b0e21d2bc1afc025]Signed-off-by Harninder Rai <[email protected]>Signed-off-by Bhaskar Upadhaya <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Shawn Guo <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 +1 file changed, 1 insertion(+)
Quoted 10 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt Required properties: · line 34
Quoted 7 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt +1
-0@@ -31,6 +31,7 @@ Required properties: * "fsl,t4240-clockgen" * "fsl,b4420-clockgen" * "fsl,b4860-clockgen" + * "fsl,ls1012a-clockgen"This isn't supported or used anywhere in 4.4, so it makes sense to document it.
It "does" or "does not" make sense? Should I drop this patch? [Bhaskar]
Hi Greg,
"fsl,ls1012a-clockgen" is getting used in the file drivers/clk/clk-qoriq.c(kernel v4.14) as below.
{
.compat = "fsl,ls1012a-clockgen",
.cmux_groups = {
&ls1012a_cmux
},
.cmux_to_group = {
0, -1
},
.pll_mask = 0x03,
},confused,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 44 lines · Bhaskar Upadhaya
-----Original Message-----
From: Greg Kroah-Hartman [mailto:[email protected]]
Sent: Wednesday, November 15, 2017 8:46 PM
To: Ben Hutchings <[email protected]>
Cc: [email protected]; [email protected]; Harninder Rai <[email protected]>; Bhaskar Upadhaya <[email protected]>; Rob Herring <[email protected]>; Shawn Guo <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012AQuoted 21 lines · Ben Hutchings
Quoted 20 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me know.
------------------
From: Harninder Rai <[email protected]>
[ Upstream commit
73447f68d7b2bc1df870da88b0e21d2bc1afc025]Signed-off-by Harninder Rai <[email protected]>Signed-off-by Bhaskar Upadhaya <[email protected]>Acked-by Rob Herring <[email protected]>Signed-off-by Shawn Guo <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�Documentation/devicetree/bindings/clock/qoriq-clock.txt |����1 + �1 file changed, 1 insertion(+)Quoted 10 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt Required properties: · line 34
Quoted 7 lines
Documentation/devicetree/bindings/clock/qoriq-clock.txt +0
-0@@ -31,6 +31,7 @@ Required properties:� * "fsl,t4240-clockgen"
� * "fsl,b4420-clockgen"
� * "fsl,b4860-clockgen"Documentation/devicetree/bindings/clock/qoriq-clock.txt +1
-0+ * "fsl,ls1012a-clockgen"This isn't supported or used anywhere in 4.4, so it makes sense to document it.
It "does" or "does not" make sense? Should I drop this patch? [Bhaskar]
Quoted 12 lines
Hi Greg,
"fsl,ls1012a-clockgen" is getting used in the file drivers/clk/clk-qoriq.c(kernel v4.14) as below.
{
.compat = "fsl,ls1012a-clockgen",
.cmux_groups = {
&ls1012a_cmux
},
.cmux_to_group = {
0, -1
},
.pll_mask = 0x03,
},4.14 is great, but this is the 4.4-stable queue :)
thanks,
greg k-h
RE: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 13 lines
Quoted 1 line
"fsl,ls1012a-clockgen" is getting used in the file
drivers/clk/clk-
qoriq.c(kernel v4.14)as below.Quoted 10 lines
{ .compat = "fsl,ls1012a-clockgen", .cmux_groups = { &ls1012a_cmux }, .cmux_to_group = { 0, -1 }, .pll_mask = 0x03, },
Quoted 1 line
4.14 is great, but this is the 4.4-stable queue :)
Will it make to 4.14 stable queue sometime in future? Sorry if my question is too basic
Quoted 4 lines
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 13 lines · Harninder Rai
Quoted 13 lines
Quoted 1 line
"fsl,ls1012a-clockgen" is getting used in the file
drivers/clk/clk-
qoriq.c(kernel v4.14)as below.Quoted 10 lines
{ .compat = "fsl,ls1012a-clockgen", .cmux_groups = { &ls1012a_cmux }, .cmux_to_group = { 0, -1 }, .pll_mask = 0x03, },
Quoted 2 lines
Quoted 1 line
4.14 is great, but this is the 4.4-stable queue :)
Will it make to 4.14 stable queue sometime in future?
Does it need to be there?
Quoted 1 line
Sorry if my question is too basic
No, not at all, if you want a patch in a specific stable tree, just email the git commit id to [email protected] and let me know what tree(s) it should be applied to.
thanks,
greg k-h
RE: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 10 lines
Quoted 2 lines
Quoted 1 line
4.14 is great, but this is the 4.4-stable queue :)
Will it make to 4.14 stable queue sometime in future?
Does it need to be there?
Quoted 1 line
Sorry if my question is too basic
No, not at all, if you want a patch in a specific stable tree, just email the git commit id to [email protected] and let me know what
tree(s) it should be applied to.
Thanks Greg. Will revert back in a day or two
Quoted 4 lines
thanks,
greg k-h
RE: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
In reply to Greg Kroah-HartmanQuoted 4 lines
No, not at all, if you want a patch in a specific stable tree, just email the git commit id to [email protected] and let me know what
tree(s) it should be applied to.
You can drop this patch. Thanks Greg
Quoted 4 lines
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 06/56] dt-bindings: clockgen: Add compatible string for LS1012A
Quoted 6 lines · Harninder Rai
Quoted 4 lines
No, not at all, if you want a patch in a specific stable tree, just email the git commit id to [email protected] and let me know what
tree(s) it should be applied to.You can drop this patch. Thanks Greg
I think I already did :)
Greg Kroah-Hartman
maintainerPATCH 8/56 KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Zhong <[email protected]>
[ Upstream commit 37451bc95dee0e666927d6ffdda302dbbaaae6fa ]
Some counters are added in Commit 6e0365b78273 ("KVM: PPC: Book3S HV:
Add ICP real mode counters"), to provide some performance statistics to determine whether further optimizing is needed for real mode functions.
The n_reject counter counts how many times ICP rejects an irq because of priority in real mode. The redelivery of an lsi that is still asserted after eoi doesn't fall into this category, so the increasement there is removed.
Also, it needs to be increased in icp_rm_deliver_irq() if it rejects another one.
--- arch/powerpc/kvm/book3s_hv_rm_xics.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
arch/powerpc/kvm/book3s_hv_rm_xics.c +2 -3
@@ -280,6 +280,7 @@ static void icp_rm_deliver_irq(struct kv*/ if (reject && reject !=XICS_IPI ) {arch_spin_unlock (&ics->lock); + icp->n_reject++; new_irq = reject; goto again; }
@@ -611,10 +612,8 @@ int kvmppc_rm_h_eoi(struct kvm_vcpu *vcp state = &ics->irq_state[src];/* Still asserted, resend it */ -if (state->asserted) { - icp->n_reject++; +if (state->asserted)icp_rm_deliver_irq (xics, icp, irq); - }if (!hlist_empty (&vcpu->kvm->irq_ack_notifier_list)) { icp->rm_action |=XICS_RM_NOTIFY_EOI ;
Greg Kroah-Hartman
maintainerPATCH 9/56 iommu/arm-smmu-v3: Clear prior settings when updating STEs
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nate Watterson <[email protected]>
[ Upstream commit 810871c57011eb3e89e6768932757f169d666cd2 ]
To prevent corruption of the stage-1 context pointer field when updating STEs, rebuild the entire containing dword instead of clearing individual fields.
--- drivers/iommu/arm-smmu-v3.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
drivers/iommu/arm-smmu-v3.c +2 -8
@@ -1033,13 +1033,8 @@ static void arm_smmu_write_strtab_ent(st } } -/* Nuke the existing Config, as we're going to rewrite it */ - val &= ~(STRTAB_STE_0_CFG_MASK <<STRTAB_STE_0_CFG_SHIFT ); - -if (ste->valid) - val |=STRTAB_STE_0_V ; -else - val &= ~STRTAB_STE_0_V ; +/* Nuke the existing STE_0 value, as we're going to rewrite it */ + val = ste->valid ?STRTAB_STE_0_V :0 ;if (ste->bypass) { val |= disable_bypass ? STRTAB_STE_0_CFG_ABORT
@@ -1068,7 +1063,6 @@ static void arm_smmu_write_strtab_ent(st val |= (ste->s1_cfg->cdptr_dma &STRTAB_STE_0_S1CTXPTR_MASK <<STRTAB_STE_0_S1CTXPTR_SHIFT ) |STRTAB_STE_0_CFG_S1_TRANS ; - }if (ste->s2_cfg) {
Greg Kroah-Hartman
maintainerPATCH 10/56 powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Valentin Longchamp <[email protected]>
[ Upstream commit a674c7d470bb47e82f4eb1fa944eadeac2f6bbaf ]
It is not implemented on the kmcoge4 hardware and if not disabled it leads to error messages with the corenet32_smp_defconfig.
--- arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 ++++ 1 file changed, 4 insertions(+)
arch/powerpc/boot/dts/fsl/kmcoge4.dts +4 -0
@@ -83,6 +83,10 @@ }; }; + sdhc@114000 { + status = "disabled"; + }; + i2c@119000 { status = "disabled"; };
Greg Kroah-Hartman
maintainerPATCH 11/56 ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <[email protected]>
[ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ]
We have more than four uarts on some SoCs and that can cause noise with errors while booting.
--- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+)
arch/arm/configs/omap2plus_defconfig +1 -0
@@ -221,6 +221,7 @@ CONFIG_SERIO=m CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 +CONFIG_SERIAL_8250_RUNTIME_UARTS=6 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y
Greg Kroah-Hartman
maintainerPATCH 12/56 crypto: vmx - disable preemption to enable vsx in aes_ctr.c
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Zhong <[email protected]>
[ Upstream commit 7dede913fc2ab9c0d3bff3a49e26fa9e858b0c13 ]
Some preemptible check warnings were reported from enable_kernel_vsx(). This patch disables preemption in aes_ctr.c before enabling vsx, and they are now consistent with other files in the same directory.
--- drivers/crypto/vmx/aes_ctr.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/crypto/vmx/aes_ctr.c +6 -0
@@ -80,11 +80,13 @@ static int p8_aes_ctr_setkey(struct crypint ret;struct p8_aes_ctr_ctx *ctx =crypto_tfm_ctx (tfm); +preempt_disable ();pagefault_disable ();enable_kernel_altivec ();enable_kernel_vsx (); ret =aes_p8_set_encrypt_key (key, keylen *8 , &ctx->enc_key);pagefault_enable (); +preempt_enable (); ret +=crypto_blkcipher_setkey (ctx->fallback, key, keylen);return ret;
@@ -99,11 +101,13 @@ static void p8_aes_ctr_final(struct p8_au8 *dst = walk->dst.virt.addr;unsigned int nbytes = walk->nbytes; +preempt_disable ();pagefault_disable ();enable_kernel_altivec ();enable_kernel_vsx ();aes_p8_encrypt (ctrblk, keystream, &ctx->enc_key);pagefault_enable (); +preempt_enable ();crypto_xor (keystream, src, nbytes);memcpy (dst, keystream, nbytes);
@@ -132,6 +136,7 @@ static int p8_aes_ctr_crypt(struct blkciblkcipher_walk_init (&walk, dst, src, nbytes); ret =blkcipher_walk_virt_block (desc, &walk,AES_BLOCK_SIZE );while ((nbytes = walk.nbytes) >=AES_BLOCK_SIZE ) { +preempt_disable ();pagefault_disable ();enable_kernel_altivec ();enable_kernel_vsx ();
@@ -143,6 +148,7 @@ static int p8_aes_ctr_crypt(struct blkci &ctx->enc_key, walk.iv);pagefault_enable (); +preempt_enable ();/* We need to update IV mostly for last bytes/round */ inc = (nbytes &AES_BLOCK_MASK ) /AES_BLOCK_SIZE ;
Greg Kroah-Hartman
maintainerPATCH 13/56 iio: trigger: free trigger resource correctly
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alison Schofield <[email protected]>
[ Upstream commit 10e840dfb0b7fc345082dd9e5fff3c1c02e7690e ]
These stand-alone trigger drivers were using iio_trigger_put() where they should have been using iio_trigger_free(). The iio_trigger_put() adds a module_put which is bad since they never did a module_get.
In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra module_put() occurs on an error path in the probe routine (probably rare).
In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare).
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.
--- drivers/iio/trigger/iio-trig-interrupt.c | 8 ++++---- drivers/iio/trigger/iio-trig-sysfs.c | 2 +- drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-)
drivers/iio/trigger/iio-trig-interrupt.c +4 -4
@@ -58,7 +58,7 @@ static int iio_interrupt_trigger_probe(s trig_info =kzalloc (sizeof (*trig_info),GFP_KERNEL );if (!trig_info) { ret = -ENOMEM ; - goto error_put_trigger; + goto error_free_trigger; }iio_trigger_set_drvdata (trig, trig_info); trig_info->irq = irq;
@@ -83,8 +83,8 @@ error_release_irq:free_irq (irq, trig); error_free_trig_info:kfree (trig_info); -error_put_trigger: -iio_trigger_put (trig); +error_free_trigger: +iio_trigger_free (trig); error_ret:return ret; }
@@ -99,7 +99,7 @@ static int iio_interrupt_trigger_remove(iio_trigger_unregister (trig);free_irq (trig_info->irq, trig);kfree (trig_info); -iio_trigger_put (trig); +iio_trigger_free (trig);return 0 ; }
drivers/iio/trigger/iio-trig-sysfs.c +1 -1
@@ -174,7 +174,7 @@ static int iio_sysfs_trigger_probe(int ireturn 0 ; out2: -iio_trigger_put (t->trig); +iio_trigger_free (t->trig); free_t:kfree (t); out1:
drivers/staging/iio/trigger/iio-trig-bfin-timer.c +2 -2
@@ -259,7 +259,7 @@ out_free_irq: out1:iio_trigger_unregister (st->trig); out: -iio_trigger_put (st->trig); +iio_trigger_free (st->trig);return ret; }
@@ -272,7 +272,7 @@ static int iio_bfin_tmr_trigger_remove(speripheral_free (st->t->pin);free_irq (st->irq, st);iio_trigger_unregister (st->trig); -iio_trigger_put (st->trig); +iio_trigger_free (st->trig);return 0 ; }
Re: [PATCH 4.4 13/56] iio: trigger: free trigger resource correctly
Quoted 19 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alison Schofield <[email protected]>
[ Upstream commit
10e840dfb0b7fc345082dd9e5fff3c1c02e7690e]These stand-alone trigger drivers were using
iio_trigger_put()where they should have been using iio_trigger_free(). Theiio_trigger_put()adds amodule_putwhich is bad since they never did amodule_get.In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra
module_put()occurs on an error path in the probe routine (probably rare).
Quoted 7 lines
In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare).
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.
In 4.4 the iio-trig-periodic-rtc seems to have the same bug (it has been removed upstream). Would it make sense to fix it in 4.4?
Ben.
Quoted 75 lines
Signed-off-by Alison Schofield <[email protected]>Signed-off-by Jonathan Cameron <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
drivers/iio/trigger/iio-trig-interrupt.c | 8 ++++---- drivers/iio/trigger/iio-trig-sysfs.c | 2 +-drivers/staging/iio/trigger/iio-trig-bfin-timer.c| 4 ++--3 files changed, 7 insertions(+), 7 deletions(-)drivers/iio/trigger/iio-trig-interrupt.c +1
-1@@ -58,7 +58,7 @@ static int iio_interrupt_trigger_probe(s trig_info = kzalloc(sizeof(*trig_info), GFP_KERNEL); if (!trig_info) { ret = -ENOMEM; - goto error_put_trigger; + goto error_free_trigger; } iio_trigger_set_drvdata(trig, trig_info); trig_info->irq = irq;@@ -83,8 +83,8 @@ error_release_irq: free_irq(irq, trig);error_free_trig_info:
kfree(trig_info);drivers/iio/trigger/iio-trig-interrupt.c +2
-2-error_put_trigger: -iio_trigger_put (trig); +error_free_trigger: +iio_trigger_free (trig);error_ret:
return ret;
}drivers/iio/trigger/iio-trig-interrupt.c +1
-1@@ -99,7 +99,7 @@ static int iio_interrupt_trigger_remove( iio_trigger_unregister(trig); free_irq(trig_info->irq, trig); kfree(trig_info); -iio_trigger_put (trig); +iio_trigger_free (trig);
return 0;
}drivers/iio/trigger/iio-trig-sysfs.c +0
-0@@ -174,7 +174,7 @@ static int iio_sysfs_trigger_probe(int i return 0;
out2:drivers/iio/trigger/iio-trig-sysfs.c +1
-1-iio_trigger_put (t->trig); +iio_trigger_free (t->trig);free_t:
kfree(t);
out1:drivers/staging/iio/trigger/iio-trig-bfin-timer.c +0
-0@@ -259,7 +259,7 @@ out_free_irq:out1:
iio_trigger_unregister(st->trig);
out:drivers/staging/iio/trigger/iio-trig-bfin-timer.c +1
-1-iio_trigger_put (st->trig); +iio_trigger_free (st->trig);return ret;
}drivers/staging/iio/trigger/iio-trig-bfin-timer.c +1
-1@@ -272,7 +272,7 @@ static int iio_bfin_tmr_trigger_remove(s peripheral_free(st->t->pin); free_irq(st->irq, st); iio_trigger_unregister(st->trig); -iio_trigger_put (st->trig); +iio_trigger_free (st->trig);
return 0;
}
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 13/56] iio: trigger: free trigger resource correctly
Quoted 25 lines · Ben Hutchings
Quoted 24 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me know.
------------------
From: Alison Schofield <[email protected]>
[ Upstream commit
10e840dfb0b7fc345082dd9e5fff3c1c02e7690e]These stand-alone trigger drivers were using
iio_trigger_put()where they should have been using iio_trigger_free().��Theiio_trigger_put()adds amodule_putwhich is bad since they never did amodule_get.In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra
module_put()occurs on an error path in the probe routine (probably rare).In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd.��It occurs on the probe error path and on the remove path (not so rare).
Quoted 5 lines
Quoted 2 lines
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.In 4.4 the iio-trig-periodic-rtc seems to have the same bug (it has been removed upstream). Would it make sense to fix it in 4.4?
Probably, or if it has been removed for a good reason, we can always remove it in 4.4 :)
thanks,
greg k-h
Re: [PATCH 4.4 13/56] iio: trigger: free trigger resource correctly
Quoted 26 lines · On Wed, 15 Nov 2017 17:11:35 +0100 Greg Kroah-Hartman…
Quoted 25 lines · Ben Hutchings
Quoted 24 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alison Schofield <[email protected]>
[ Upstream commit
10e840dfb0b7fc345082dd9e5fff3c1c02e7690e]These stand-alone trigger drivers were using
iio_trigger_put()where they should have been using iio_trigger_free(). Theiio_trigger_put()adds amodule_putwhich is bad since they never did amodule_get.In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra
module_put()occurs on an error path in the probe routine (probably rare).In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare).
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.In 4.4 the iio-trig-periodic-rtc seems to have the same bug (it has been removed upstream). Would it make sense to fix it in 4.4?
Probably, or if it has been removed for a good reason, we can always remove it in 4.4 :)
It was removed after the introduction of the high resolution timer trigger as in recent times periodic rtcs have all been emulated anyway (as high resolution timers). Unfortunately the hrt trigger wasn't present in 4.4 so simply dropping the periodic rtc trigger 'might' leave people unable to do what they want.
So best bet would be to fix this periodic rtc trigger as Ben suggested.
Jonathan
Quoted 4 lines
thanks,
greg k-h
Greg Kroah-Hartman
maintainerPATCH 14/56 dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Lechner <[email protected]>
[ Upstream commit 21078ab174c99885ca83a5c32db0d33b1617745e ]
This adds the board level device tree specification for LEGO MINDSTORMS EV3
--- Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/devicetree/bindings/arm/davinci.txt +4 -0
@@ -9,6 +9,10 @@ EnBW AM1808 based CMC board Required root node properties: - compatible = "enbw,cmc", "ti,da850; +LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: + - compatible = "lego,ev3", "ti,da850"; + Generic DaVinci Boards ----------------------
Re: [PATCH 4.4 14/56] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Quoted 5 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
Quoted 7 lines
From: David Lechner <[email protected]>
[ Upstream commit
21078ab174c99885ca83a5c32db0d33b1617745e]This adds the board level device tree specification for LEGO MINDSTORMS EV3
Nothing uses or implements this in 4.4.
Ben.
Quoted 25 lines
Acked-by Rob Herring <[email protected]>Signed-off-by David Lechner <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++1 file changed, 4 insertions(+)Documentation/devicetree/bindings/arm/davinci.txt +0
-0@@ -9,6 +9,10 @@ EnBW AM1808 based CMC boardRequired root node properties:
- compatible = "enbw,cmc", "ti,da850;Documentation/devicetree/bindings/arm/davinci.txt +4
-0+LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: + - compatible = "lego,ev3", "ti,da850"; +Generic DaVinci Boards
----------------------
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 14/56] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Quoted 9 lines · Ben Hutchings
Quoted 8 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me know.
------------------
From: David Lechner <[email protected]>
Quoted 6 lines
Quoted 4 lines
[ Upstream commit
21078ab174c99885ca83a5c32db0d33b1617745e]This adds the board level device tree specification for LEGO MINDSTORMS EV3
Nothing uses or implements this in 4.4.
Really?
Quoted 12 lines
Ben.
Quoted 9 lines
Acked-by Rob Herring <[email protected]>Signed-off-by David Lechner <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�Documentation/devicetree/bindings/arm/davinci.txt |����4 ++++ �1 file changed, 4 insertions(+)
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt EnBW AM1808 based CMC board
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt +0
-0@@ -9,6 +9,10 @@ EnBW AM1808 based CMC board�Required root node properties:
�����- compatible = "enbw,cmc", "ti,da850; �Documentation/devicetree/bindings/arm/davinci.txt +3
-0+LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: +����- compatible = "lego,ev3", "ti,da850";
I see lots of "ti,da850" dt stuff used in 4.4. As this hardware was released on 3.2 or so, shouldn't this all be well-used by now?
thanks,
greg k-h
Re: [PATCH 4.4 14/56] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Quoted 32 lines · Greg Kroah-Hartman
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me
know.------------------
From: David Lechner <[email protected]>
Quoted 6 lines
Quoted 4 lines
[ Upstream commit
21078ab174c99885ca83a5c32db0d33b1617745e]This adds the board level device tree specification for LEGO MINDSTORMS EV3
Nothing uses or implements this in 4.4.
Really?
Quoted 12 lines
Ben.
Quoted 9 lines
Acked-by Rob Herring <[email protected]>Signed-off-by David Lechner <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++1 file changed, 4 insertions(+)
Quoted 12 lines
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt EnBW AM1808 based CMC board · line 14
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt +0
-0@@ -9,6 +9,10 @@ EnBW AM1808 based CMC boardRequired root node properties:
- compatible = "enbw,cmc", "ti,da850;Documentation/devicetree/bindings/arm/davinci.txt +3
-0+LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: + - compatible = "lego,ev3", "ti,da850";I see lots of "ti,da850" dt stuff used in 4.4. As this hardware was released on 3.2 or so, shouldn't this all be well-used by now?
"ti,da850" is used but "lego,ev3" is not.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 14/56] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Quoted 46 lines · Ben Hutchings
Quoted 32 lines · Greg Kroah-Hartman
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me
know.------------------
From: David Lechner <[email protected]>
Quoted 6 lines
Quoted 4 lines
[ Upstream commit
21078ab174c99885ca83a5c32db0d33b1617745e]This adds the board level device tree specification for LEGO MINDSTORMS EV3
Nothing uses or implements this in 4.4.
Really?
Quoted 12 lines
Ben.
Quoted 9 lines
Acked-by Rob Herring <[email protected]>Signed-off-by David Lechner <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�Documentation/devicetree/bindings/arm/davinci.txt |����4 ++++ �1 file changed, 4 insertions(+)Quoted 12 lines
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt EnBW AM1808 based CMC board
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt +0
-0@@ -9,6 +9,10 @@ EnBW AM1808 based CMC board�Required root node properties:
�����- compatible = "enbw,cmc", "ti,da850; �Documentation/devicetree/bindings/arm/davinci.txt +3
-0+LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: +����- compatible = "lego,ev3", "ti,da850";I see lots of "ti,da850" dt stuff used in 4.4.��As this hardware was released on 3.2 or so, shouldn't this all be well-used by now?
Quoted 1 line
"ti,da850" is used but "lego,ev3" is not.
Ugh, same for 4.9-stable as well.
Sasha, can you send me a 'revert' patch for this, I applied it there already :(
I'll go drop this from the 4.4 queue, thanks again Ben for your great review.
greg k-h
Re: [PATCH 4.4 14/56] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
Quoted 49 lines · Greg Kroah-Hartman
Quoted 46 lines · Ben Hutchings
Quoted 32 lines · Greg Kroah-Hartman
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me
know.------------------
From: David Lechner <[email protected]>
Quoted 6 lines
Quoted 4 lines
[ Upstream commit
21078ab174c99885ca83a5c32db0d33b1617745e]This adds the board level device tree specification for LEGO MINDSTORMS EV3
Nothing uses or implements this in 4.4.
Really?
Quoted 12 lines
Ben.
Quoted 9 lines
Acked-by Rob Herring <[email protected]>Signed-off-by David Lechner <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Signed-off-by Sasha Levin <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++1 file changed, 4 insertions(+)Quoted 12 lines
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt EnBW AM1808 based CMC board · line 14
Quoted 9 lines
Documentation/devicetree/bindings/arm/davinci.txt +0
-0@@ -9,6 +9,10 @@ EnBW AM1808 based CMC boardRequired root node properties:
- compatible = "enbw,cmc", "ti,da850;Documentation/devicetree/bindings/arm/davinci.txt +3
-0+LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: + - compatible = "lego,ev3", "ti,da850";I see lots of "ti,da850" dt stuff used in 4.4. As this hardware was released on 3.2 or so, shouldn't this all be well-used by now?
Quoted 1 line
"ti,da850" is used but "lego,ev3" is not.
Quoted 7 lines
Ugh, same for 4.9-stable as well.
Sasha, can you send me a 'revert' patch for this, I applied it there already :(
I'll go drop this from the 4.4 queue, thanks again Ben for your great review.
Sure. I'll also stop sending dt commits until I have a better story for their selection process.
Thanks Ben!
Signature · 2 lines
Thanks, Sasha
Greg Kroah-Hartman
maintainerPATCH 15/56 dt-bindings: Add vendor prefix for LEGO
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Lechner <[email protected]>
[ Upstream commit 7dcc31e2e68a386a29070384b51683ece80982bf ]
Add a vendor prefix for LEGO Systems A/S
--- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/vendor-prefixes.txt +1 -0
@@ -126,6 +126,7 @@ keymile Keymile GmbH kinetic Kinetic Technologies lacie LaCie lantiq Lantiq Semiconductor +lego LEGO Systems A/S lenovo Lenovo Group Ltd. lg LG Corporation linux Linux-specific binding
Greg Kroah-Hartman
maintainerPATCH 17/56 serial: sh-sci: Fix register offsets for the IRDA serial port
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <[email protected]>
[ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ]
Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the registers offset in the driver and the platform data regshift value.
--- arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 - drivers/tty/serial/sh-sci.c | 17 ++++++++--------- 2 files changed, 8 insertions(+), 10 deletions(-)
arch/sh/kernel/cpu/sh3/setup-sh770x.c +0 -1
@@ -165,7 +165,6 @@ static struct plat_sci_port scif2_platfo .scscr = SCSCR_TE | SCSCR_RE, .type = PORT_IRDA, .ops = &sh770x_sci_port_ops, - .regshift = 1, };static struct resource scif2_resources[] = {
drivers/tty/serial/sh-sci.c +8 -9
@@ -163,18 +163,17 @@ static const struct plat_sci_reg sci_reg }, /* - * Common definitions for legacy IrDA ports, dependent on - * regshift value. + * Common definitions for legacy IrDA ports. */ [SCIx_IRDA_REGTYPE] = { [SCSMR] = { 0x00, 8 }, - [SCBRR] = { 0x01, 8 }, - [SCSCR] = { 0x02, 8 }, - [SCxTDR] = { 0x03, 8 }, - [SCxSR] = { 0x04, 8 }, - [SCxRDR] = { 0x05, 8 }, - [SCFCR] = { 0x06, 8 }, - [SCFDR] = { 0x07, 16 }, + [SCBRR] = { 0x02, 8 }, + [SCSCR] = { 0x04, 8 }, + [SCxTDR] = { 0x06, 8 }, + [SCxSR] = { 0x08, 16 }, + [SCxRDR] = { 0x0a, 8 }, + [SCFCR] = { 0x0c, 8 }, + [SCFDR] = { 0x0e, 16 }, [SCTFDR] = sci_reg_invalid, [SCRFDR] = sci_reg_invalid, [SCSPTR] = sci_reg_invalid,
Greg Kroah-Hartman
maintainerPATCH 18/56 usb: hcd: initialize hcd->flags to 0 when rm hcd
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: William wu <[email protected]>
[ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ]
On some platforms(e.g. rk3399 board), we can call hcd_add/remove consecutively without calling usb_put_hcd/usb_create_hcd in between, so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get the below error on next hcd_add.
[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up [173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller [173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6 [173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. [173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003 [173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [173.297222] usb usb6: Product: xHCI Host Controller [173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd [173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto [173.298680] hub 6-0:1.0: USB hub found [173.298749] hub 6-0:1.0: 1 port detected [173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected [173.395418] hub 5-0:1.0: activate --> -19 [173.603447] irq 228: nobody cared (try booting with the "irqpoll" option) [173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9 [173.603513] Hardware name: Google Kevin (DT) [173.603531] Call trace: [173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160 [173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28 [173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0 [173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8 [173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c [173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c [173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c [173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124 [173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44 [173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc [173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188 ... [173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8 [173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc [173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94 [173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc [173.604607] [<0000000000b16000>] 0xb16000 [173.604622] handlers: [173.604648] [<ffffffc000642084>] usb_hcd_irq [173.604673] Disabling IRQ #228
--- drivers/usb/core/hcd.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/core/hcd.c +1 -0
@@ -2997,6 +2997,7 @@ void usb_remove_hcd(struct usb_hcd *hcd) }usb_put_invalidate_rhdev (hcd); + hcd->flags =0 ; }EXPORT_SYMBOL_GPL (usb_remove_hcd);
Greg Kroah-Hartman
maintainerPATCH 19/56 netfilter: nft_meta: deal with PACKET_LOOPBACK in netdev family
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liping Zhang <[email protected]>
[ Upstream commit f169fd695b192dd7b23aff8e69d25a1bc881bbfa ]
After adding the following nft rule, then ping 224.0.0.1:
# nft add rule netdev t c pkttype host counter
The warning complain message will be printed out again and again:
WARNING: CPU: 0 PID: 10182 at net/netfilter/nft_meta.c:163 \
nft_meta_get_eval+0x3fe/0x460 [nft_meta]
[...]
Call Trace:
<IRQ>
dump_stack+0x85/0xc2
__warn+0xcb/0xf0
warn_slowpath_null+0x1d/0x20
nft_meta_get_eval+0x3fe/0x460 [nft_meta]
nft_do_chain+0xff/0x5e0 [nf_tables]So we should deal with PACKET_LOOPBACK in netdev family too. For ipv4, convert it to PACKET_BROADCAST/MULTICAST according to the destination address's type; For ipv6, convert it to PACKET_MULTICAST directly.
--- net/netfilter/nft_meta.c | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-)
net/netfilter/nft_meta.c +27 -1
@@ -151,8 +151,34 @@ void nft_meta_get_eval(const struct nft_else *dest =PACKET_BROADCAST ;break ; +case NFPROTO_NETDEV : +switch (skb->protocol) { +case htons (ETH_P_IP ): { +int noff =skb_network_offset (skb); +struct iphdr *iph, _iph; + + iph =skb_header_pointer (skb, noff, +sizeof (_iph), &_iph); +if (!iph) + goto err; + +if (ipv4_is_multicast (iph->daddr)) + *dest =PACKET_MULTICAST ; +else + *dest =PACKET_BROADCAST ; + +break ; + } +case htons (ETH_P_IPV6 ): + *dest =PACKET_MULTICAST ; +break ; +default : +WARN_ON_ONCE (1 ); + goto err; + } +break ;default : -WARN_ON (1 ); +WARN_ON_ONCE (1 ); goto err; }break ;
Greg Kroah-Hartman
maintainerPATCH 20/56 IPsec: do not ignore crypto err in ah4 input
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gilad Ben-Yossef <[email protected]>
[ Upstream commit ebd89a2d0675f1325c2be5b7576fd8cb7e8defd0 ]
ah4 input processing uses the asynchronous hash crypto API which supplies an error code as part of the operation completion but the error code was being ignored.
Treat a crypto API error indication as a verification failure.
While a crypto API reported error would almost certainly result in a memcpy of the digest failing anyway and thus the security risk seems minor, performing a memory compare on what might be uninitialized memory is wrong.
--- net/ipv4/ah4.c | 3 +++ 1 file changed, 3 insertions(+)
net/ipv4/ah4.c +3 -0
@@ -270,6 +270,9 @@ static void ah_input_done(struct crypto_int ihl =ip_hdrlen (skb);int ah_hlen = (ah->hdrlen +2 ) <<2 ; +if (err) + goto out; + work_iph =AH_SKB_CB (skb)->tmp; auth_data =ah_tmp_auth (work_iph, ihl); icv =ah_tmp_icv (ahp->ahash, auth_data, ahp->icv_trunc_len);
Greg Kroah-Hartman
maintainerPATCH 21/56 Input: mpr121 - handle multiple bits change of status register
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <[email protected]>
[ Upstream commit 08fea55e37f58371bffc5336a59e55d1f155955a ]
This driver reports input events on their interrupts which are triggered by the sensor's status register changes. But only single bit change is reported in the interrupt handler. So if there are multiple bits are changed at almost the same time, other press or release events are ignored.
This fixes it by detecting all changed bits in the status register.
--- drivers/input/keyboard/mpr121_touchkey.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-)
drivers/input/keyboard/mpr121_touchkey.c +14 -9
@@ -87,7 +87,8 @@ static irqreturn_t mpr_touchkey_interrupstruct mpr121_touchkey *mpr121 = dev_id;struct i2c_client *client = mpr121->client;struct input_dev *input = mpr121->input_dev; -unsigned int key_num, key_val, pressed; +unsigned long bit_changed; +unsigned int key_num;int reg; reg =i2c_smbus_read_byte_data (client,ELE_TOUCH_STATUS_1_ADDR );
@@ -105,18 +106,22 @@ static irqreturn_t mpr_touchkey_interrup reg &=TOUCH_STATUS_MASK ;/* use old press bit to figure out which bit changed */ - key_num =ffs (reg ^ mpr121->statusbits) -1 ; - pressed = reg & (1 << key_num); + bit_changed = reg ^ mpr121->statusbits; mpr121->statusbits = reg; +for_each_set_bit (key_num, &bit_changed, mpr121->keycount) { +unsigned int key_val, pressed; - key_val = mpr121->keycodes[key_num]; + pressed = reg &BIT (key_num); + key_val = mpr121->keycodes[key_num]; -input_event (input,EV_MSC ,MSC_SCAN , key_num); -input_report_key (input, key_val, pressed); -input_sync (input); +input_event (input,EV_MSC ,MSC_SCAN , key_num); +input_report_key (input, key_val, pressed); + +dev_dbg (&client->dev,"key %d %d %s\n" , key_num, key_val, + pressed ?"pressed" :"released" ); -dev_dbg (&client->dev,"key %d %d %s\n" , key_num, key_val, - pressed ?"pressed" :"released" ); + } +input_sync (input); out:return IRQ_HANDLED ;
Greg Kroah-Hartman
maintainerPATCH 22/56 Input: mpr121 - set missing event capability
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akinobu Mita <[email protected]>
[ Upstream commit 9723ddc8fe0d76ce41fe0dc16afb241ec7d0a29d ]
This driver reports misc scan input events on the sensor's status register changes. But the event capability for them was not set in the device initialization, so these events were ignored.
This change adds the missing event capability.
--- drivers/input/keyboard/mpr121_touchkey.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/keyboard/mpr121_touchkey.c +1 -0
@@ -236,6 +236,7 @@ static int mpr_touchkey_probe(struct i2c input_dev->id.bustype =BUS_I2C ; input_dev->dev.parent = &client->dev; input_dev->evbit[0 ] =BIT_MASK (EV_KEY ) |BIT_MASK (EV_REP ); +input_set_capability (input_dev,EV_MSC ,MSC_SCAN ); input_dev->keycode = mpr121->keycodes; input_dev->keycodesize =sizeof (mpr121->keycodes[0 ]);
Greg Kroah-Hartman
maintainerPATCH 23/56 IB/ipoib: Change list_del to list_del_init in the tx object
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feras Daoud <[email protected]>
[ Upstream commit 27d41d29c7f093f6f77843624fbb080c1b4a8b9c ]
Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function belong to different work queues, they can run in parallel.
In this case if ipoib_cm_tx_reap calls list_del and release the lock, ipoib_cm_tx_start may acquire it and call list_del_init on the already deleted object.
Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem.
--- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/ulp/ipoib/ipoib_cm.c +1 -1
@@ -1373,7 +1373,7 @@ static void ipoib_cm_tx_reap(struct workwhile (!list_empty (&priv->cm.reap_list)) { p =list_entry (priv->cm.reap_list.next,typeof (*p), list); -list_del (&p->list); +list_del_init (&p->list);spin_unlock_irqrestore (&priv->lock, flags);netif_tx_unlock_bh (dev);ipoib_cm_tx_destroy (p);
Greg Kroah-Hartman
maintainerPATCH 24/56 s390/qeth: issue STARTLAN as first IPA command
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julian Wiedmann <[email protected]>
[ Upstream commit 1034051045d125579ab1e8fcd5a724eeb0e70149 ]
STARTLAN needs to be the first IPA command after MPC initialization completes.
So move the qeth_send_startlan() call from the layer disciplines into the core path, right after the MPC handshake.
While at it, replace the magic LAN OFFLINE return code with the existing enum.
--- drivers/s390/net/qeth_core.h | 1 - drivers/s390/net/qeth_core_main.c | 21 +++++++++++++++++---- drivers/s390/net/qeth_l2_main.c | 15 --------------- drivers/s390/net/qeth_l3_main.c | 15 --------------- 4 files changed, 17 insertions(+), 35 deletions(-)
drivers/s390/net/qeth_core.h +0 -1
@@ -909,7 +909,6 @@ void qeth_clear_thread_running_bit(strucint qeth_core_hardsetup_card (struct qeth_card *);void qeth_print_status_message (struct qeth_card *);int qeth_init_qdio_queues (struct qeth_card *); -int qeth_send_startlan (struct qeth_card *); int qeth_send_ipa_cmd(struct qeth_card *, struct qeth_cmd_buffer *, int (*reply_cb) (struct qeth_card *, struct qeth_reply *, unsigned long),
drivers/s390/net/qeth_core_main.c +17 -4
@@ -2955,7 +2955,7 @@ int qeth_send_ipa_cmd(struct qeth_card * }EXPORT_SYMBOL_GPL (qeth_send_ipa_cmd); -int qeth_send_startlan (struct qeth_card *card) +static int qeth_send_startlan (struct qeth_card *card) {int rc;struct qeth_cmd_buffer *iob;
@@ -2968,7 +2968,6 @@ int qeth_send_startlan(struct qeth_card rc =qeth_send_ipa_cmd (card, iob,NULL ,NULL );return rc; } -EXPORT_SYMBOL_GPL (qeth_send_startlan);static int qeth_default_setadapterparms_cb (struct qeth_card *card,struct qeth_reply *reply,unsigned long data)
@@ -5080,6 +5079,20 @@ retriable: goto out; } + rc =qeth_send_startlan (card); +if (rc) { +QETH_DBF_TEXT_ (SETUP ,2 ,"6err%d" , rc); +if (rc ==IPA_RC_LAN_OFFLINE ) { +dev_warn (&card->gdev->dev, +"The LAN is offline\n" ); + card->lan_online =0 ; + }else { + rc = -ENODEV ; + goto out; + } + }else + card->lan_online =1 ; + card->options.ipa4.supported_funcs =0 ; card->options.ipa6.supported_funcs =0 ; card->options.adp.supported_funcs =0 ;
@@ -5091,14 +5104,14 @@ retriable:if (qeth_is_supported (card,IPA_SETADAPTERPARMS )) { rc =qeth_query_setadapterparms (card);if (rc <0 ) { -QETH_DBF_TEXT_ (SETUP ,2 ,"6err%d" , rc); +QETH_DBF_TEXT_ (SETUP ,2 ,"7err%d" , rc); goto out; } }if (qeth_adp_supported (card,IPA_SETADP_SET_DIAG_ASSIST )) { rc =qeth_query_setdiagass (card);if (rc <0 ) { -QETH_DBF_TEXT_ (SETUP ,2 ,"7err%d" , rc); +QETH_DBF_TEXT_ (SETUP ,2 ,"8err%d" , rc); goto out; } }
drivers/s390/net/qeth_l2_main.c +0 -15
@@ -1203,21 +1203,6 @@ static int __qeth_l2_set_online(struct c/* softsetup */ QETH_DBF_TEXT (SETUP ,2 ,"softsetp" ); - rc =qeth_send_startlan (card); -if (rc) { -QETH_DBF_TEXT_ (SETUP ,2 ,"1err%d" , rc); -if (rc ==0xe080 ) { -dev_warn (&card->gdev->dev, -"The LAN is offline\n" ); - card->lan_online =0 ; - goto contin; - } - rc = -ENODEV ; - goto out_remove; - }else - card->lan_online =1 ; - -contin:if ((card->info.type ==QETH_CARD_TYPE_OSD ) || (card->info.type ==QETH_CARD_TYPE_OSX )) {if (qeth_l2_start_ipassists (card))
drivers/s390/net/qeth_l3_main.c +0 -15
@@ -3298,21 +3298,6 @@ static int __qeth_l3_set_online(struct c/* softsetup */ QETH_DBF_TEXT (SETUP ,2 ,"softsetp" ); - rc =qeth_send_startlan (card); -if (rc) { -QETH_DBF_TEXT_ (SETUP ,2 ,"1err%d" , rc); -if (rc ==0xe080 ) { -dev_warn (&card->gdev->dev, -"The LAN is offline\n" ); - card->lan_online =0 ; - goto contin; - } - rc = -ENODEV ; - goto out_remove; - }else - card->lan_online =1 ; - -contin: rc =qeth_l3_setadapter_parms (card);if (rc)QETH_DBF_TEXT_ (SETUP ,2 ,"2err%04x" , rc);
Greg Kroah-Hartman
maintainerPATCH 25/56 net: dsa: select NET_SWITCHDEV
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vivien Didelot <[email protected]>
[ Upstream commit 3a89eaa65db68bf53bf92dedc60084f810e1779a ]
The support for DSA Ethernet switch chips depends on TCP/IP networking, thus explicit that HAVE_NET_DSA depends on INET.
DSA uses SWITCHDEV, thus select it instead of depending on it.
--- net/dsa/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
net/dsa/Kconfig +3 -2
@@ -1,12 +1,13 @@ config HAVE_NET_DSA def_bool y - depends on NETDEVICES && !S390 + depends on INET && NETDEVICES && !S390 # Drivers must select NET_DSA and the appropriate tagging format config NET_DSA tristate "Distributed Switch Architecture" - depends on HAVE_NET_DSA && NET_SWITCHDEV + depends on HAVE_NET_DSA + select NET_SWITCHDEV select PHYLIB ---help--- Say Y if you want to enable support for the hardware switches supported
Greg Kroah-Hartman
maintainerPATCH 28/56 KEYS: trusted: sanitize all key material
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit ee618b4619b72527aaed765f0f0b74072b281159 upstream.
As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths.
--- security/keys/trusted.c | 50 +++++++++++++++++++++--------------------------- 1 file changed, 22 insertions(+), 28 deletions(-)
security/keys/trusted.c +22 -28
@@ -69,7 +69,7 @@ static int TSS_sha1(const unsigned char } ret =crypto_shash_digest (&sdesc->shash, data, datalen, digest); -kfree (sdesc); +kzfree (sdesc);return ret; }
@@ -113,7 +113,7 @@ static int TSS_rawhmac(unsigned char *diif (!ret) ret =crypto_shash_final (&sdesc->shash, digest); out: -kfree (sdesc); +kzfree (sdesc);return ret; }
@@ -164,7 +164,7 @@ static int TSS_authhmac(unsigned char *d paramdigest,TPM_NONCE_SIZE , h1, TPM_NONCE_SIZE, h2, 1, &c, 0, 0); out: -kfree (sdesc); +kzfree (sdesc);return ret; }
@@ -245,7 +245,7 @@ static int TSS_checkhmac1(unsigned charif (memcmp (testhmac, authdata,SHA1_DIGEST_SIZE )) ret = -EINVAL ; out: -kfree (sdesc); +kzfree (sdesc);return ret; }
@@ -346,7 +346,7 @@ static int TSS_checkhmac2(unsigned charif (memcmp (testhmac2, authdata2,SHA1_DIGEST_SIZE )) ret = -EINVAL ; out: -kfree (sdesc); +kzfree (sdesc);return ret; }
@@ -563,7 +563,7 @@ static int tpm_seal(struct tpm_buf *tb, *bloblen = storedsize; } out: -kfree (td); +kzfree (td);return ret; }
@@ -677,7 +677,7 @@ static int key_seal(struct trusted_key_pif (ret <0 )pr_info ("trusted_key: srkseal failed (%d)\n" , ret); -kfree (tb); +kzfree (tb);return ret; }
@@ -702,7 +702,7 @@ static int key_unseal(struct trusted_key/* pull migratable flag out of sealed key */ p->migratable = p->key[--p->key_len]; -kfree (tb); +kzfree (tb);return ret; }
@@ -984,12 +984,12 @@ static int trusted_instantiate(struct keif (!ret && options->pcrlock) ret =pcrlock (options->pcrlock); out: -kfree (datablob); -kfree (options); +kzfree (datablob); +kzfree (options);if (!ret)rcu_assign_keypointer (key, payload);else -kfree (payload); +kzfree (payload);return ret; }
@@ -998,8 +998,7 @@ static void trusted_rcu_free(struct rcu_struct trusted_key_payload *p; p = container_of(rcu, struct trusted_key_payload, rcu); -memset (p->key,0 , p->key_len); -kfree (p); +kzfree (p); }/*
@@ -1041,13 +1040,13 @@ static int trusted_update(struct key *ke ret =datablob_parse (datablob, new_p, new_o);if (ret != Opt_update) { ret = -EINVAL ; -kfree (new_p); +kzfree (new_p); goto out; }if (!new_o->keyhandle) { ret = -EINVAL ; -kfree (new_p); +kzfree (new_p); goto out; }
@@ -1061,22 +1060,22 @@ static int trusted_update(struct key *ke ret =key_seal (new_p, new_o);if (ret <0 ) {pr_info ("trusted_key: key_seal failed (%d)\n" , ret); -kfree (new_p); +kzfree (new_p); goto out; }if (new_o->pcrlock) { ret =pcrlock (new_o->pcrlock);if (ret <0 ) {pr_info ("trusted_key: pcrlock failed (%d)\n" , ret); -kfree (new_p); +kzfree (new_p); goto out; } }rcu_assign_keypointer (key, new_p);call_rcu (&p->rcu, trusted_rcu_free); out: -kfree (datablob); -kfree (new_o); +kzfree (datablob); +kzfree (new_o);return ret; }
@@ -1105,24 +1104,19 @@ static long trusted_read(const struct kefor (i =0 ; i < p->blob_len; i++) bufp =hex_byte_pack (bufp, p->blob[i]);if ((copy_to_user (buffer, ascii_buf,2 * p->blob_len)) !=0 ) { -kfree (ascii_buf); +kzfree (ascii_buf);return -EFAULT ; } -kfree (ascii_buf); +kzfree (ascii_buf);return 2 * p->blob_len; }/* -* trusted_destroy - before freeing the key, clear the decrypted data +* trusted_destroy - clear and free the key's payload */ static void trusted_destroy (struct key *key) { -struct trusted_key_payload *p = key->payload.data[0 ]; - -if (!p) -return ; -memset (p->key,0 , p->key_len); -kfree (key->payload.data[0 ]); +kzfree (key->payload.data[0 ]); }struct key_type key_type_trusted = {
Greg Kroah-Hartman
maintainerPATCH 29/56 KEYS: trusted: fix writing past end of buffer in trusted_read()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream.
When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read().
We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type.
--- security/keys/trusted.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-)
security/keys/trusted.c +12 -11
@@ -1094,20 +1094,21 @@ static long trusted_read(const struct ke p =rcu_dereference_key (key);if (!p)return -EINVAL ; -if (!buffer || buflen <=0 ) -return 2 * p->blob_len; - ascii_buf =kmalloc (2 * p->blob_len,GFP_KERNEL ); -if (!ascii_buf) -return -ENOMEM ; - bufp = ascii_buf; -for (i =0 ; i < p->blob_len; i++) - bufp =hex_byte_pack (bufp, p->blob[i]); -if ((copy_to_user (buffer, ascii_buf,2 * p->blob_len)) !=0 ) { +if (buffer && buflen >=2 * p->blob_len) { + ascii_buf =kmalloc (2 * p->blob_len,GFP_KERNEL ); +if (!ascii_buf) +return -ENOMEM ; + + bufp = ascii_buf; +for (i =0 ; i < p->blob_len; i++) + bufp =hex_byte_pack (bufp, p->blob[i]); +if (copy_to_user (buffer, ascii_buf,2 * p->blob_len) !=0 ) { +kzfree (ascii_buf); +return -EFAULT ; + }kzfree (ascii_buf); -return -EFAULT ; } -kzfree (ascii_buf);return 2 * p->blob_len; }
Greg Kroah-Hartman
maintainerPATCH 32/56 x86/uaccess, sched/preempt: Verify access_ok() context
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit 7c4788950ba5922fde976d80b72baf46f14dee8d upstream.
I recently encountered wreckage because access_ok() was used where it should not be, add an explicit WARN when access_ok() is used wrongly.
--- arch/x86/include/asm/uaccess.h | 14 ++++++++++++-- include/linux/preempt.h | 21 +++++++++++++-------- 2 files changed, 25 insertions(+), 10 deletions(-)
arch/x86/include/asm/uaccess.h +12 -2
@@ -7,6 +7,7 @@#include <linux/compiler.h> #include <linux/thread_info.h> #include <linux/string.h> +#include <linux/preempt.h> #include <asm/asm.h> #include <asm/page.h> #include <asm/smap.h>
@@ -66,6 +67,12 @@ static inline bool __chk_range_not_ok(un__chk_range_not_ok ((unsigned long __force )(addr), size, limit); \ }) +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP +# define WARN_ON_IN_IRQ () WARN_ON_ONCE(!in_task()) +#else +# define WARN_ON_IN_IRQ () +#endif +/** * access_ok: - Checks if a user space pointer is valid * @type: Type of access: %VERIFY_READ or %VERIFY_WRITE. Note that
@@ -86,8 +93,11 @@ static inline bool __chk_range_not_ok(un* checks that the pointer is in the user space range - after calling * this function, memory access functions may still return -EFAULT. */ -#define access_ok (type, addr, size) \ - likely(!__range_not_ok(addr, size, user_addr_max())) +#define access_ok (type, addr, size) \ +({ \ + WARN_ON_IN_IRQ(); \ + likely(!__range_not_ok(addr, size, user_addr_max())); \ +})/* * The exception table consists of pairs of addresses relative to the
include/linux/preempt.h +13 -8
@@ -65,19 +65,24 @@/* * Are we doing bottom half or hardware interrupt processing? -* Are we in a softirq context? Interrupt context? -* in_softirq - Are we currently processing softirq or have bh disabled? -* in_serving_softirq - Are we currently processing softirq? +* +* in_irq() - We're in (hard) IRQ context +* in_softirq() - We have BH disabled, or are processing softirqs +* in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled +* in_serving_softirq() - We're in softirq context +* in_nmi() - We're in NMI context +* in_task() - We're in task context +* +* Note: due to the BH disabled confusion: in_softirq(),in_interrupt() really +* should not be used in new code. */ #define in_irq () (hardirq_count())#define in_softirq () (softirq_count())#define in_interrupt () (irq_count())#define in_serving_softirq () (softirq_count() & SOFTIRQ_OFFSET) - -/* -* Are we in NMI context? -*/ -#define in_nmi () (preempt_count() & NMI_MASK) +#define in_nmi () (preempt_count() & NMI_MASK) +#define in_task () (!(preempt_count() & \ + (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET)))/* * The preempt_count offset after preempt_disable();
Greg Kroah-Hartman
maintainerPATCH 33/56 workqueue: Fix NULL pointer dereference
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Bin <[email protected]>
commit cef572ad9bd7f85035ba8272e5352040e8be0152 upstream.
When queue_work() is used in irq (not in task context), there is a potential case that trigger NULL pointer dereference.
----------------------------------------------------------------worker_thread()
|-spin_lock_irq()
|-process_one_work()
|-worker->current_pwq = pwq |-spin_unlock_irq() |-worker->current_func(work) |-spin_lock_irq()
|-worker->current_pwq = NULL
|-spin_unlock_irq()
//interrupt here |-irq_handler |-__queue_work() //assuming that the wq is draining |-is_chained_work(wq) |-current_wq_worker() //Here, 'current' is the interrupted worker! |-current->current_pwq is NULL here!
|-schedule()
----------------------------------------------------------------
Avoid it by checking for task context in current_wq_worker(), and if not in task context, we shouldn't use the 'current' to check the condition.
--- kernel/workqueue_internal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/workqueue_internal.h +2 -1
@@ -9,6 +9,7 @@#include <linux/workqueue.h> #include <linux/kthread.h> +#include <linux/preempt.h> struct worker_pool ;
@@ -59,7 +60,7 @@ struct worker {*/ static inline struct worker *current_wq_worker (void ) { -if (current->flags &PF_WQ_WORKER ) +if (in_task () && (current->flags &PF_WQ_WORKER ))return kthread_data (current);return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 34/56 crypto: x86/sha1-mb - fix panic due to unaligned access
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Ryabinin <[email protected]>
commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream.
struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault.
Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements.
--- arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S +6 -6
@@ -174,8 +174,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C}
@@ -195,8 +195,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2
@@ -260,8 +260,8 @@ ENTRY(sha1_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C}
Greg Kroah-Hartman
maintainerPATCH 35/56 KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <[email protected]>
commit 624f5ab8720b3371367327a822c267699c1823b8 upstream.
syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y:
keyctl add pkcs7_test desc '' @s
The bug is that if the data buffer is empty, an integer underflow occurs in the following check:
if (unlikely(dp >= datalen - 1))
goto data_overrun_error;
This results in the NULL data pointer being dereferenced.
Fix it by checking for 'datalen - dp < 2' instead.
Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread.
The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not.
The bug report was:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233
PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014
task: ffff9b6b3798c040 task.stack: ffff9b6b37970000
RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233
RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c
RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0
RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0
Call Trace:
pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139
verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216
pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63
key_create_or_update+0x180/0x530 security/keys/key.c:855
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4585c9
RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8
RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9
RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000
RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae
R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000
Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff
RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78
CR2: 0000000000000000--- lib/asn1_decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
lib/asn1_decoder.c +2 -2
@@ -227,7 +227,7 @@ next_op: hdr =2 ;/* Extract a tag from the data */ -if (unlikely (dp >= datalen -1 )) +if (unlikely (datalen - dp <2 )) goto data_overrun_error; tag = data[dp++];if (unlikely ((tag &0x1f ) ==ASN1_LONG_TAG ))
@@ -273,7 +273,7 @@ next_op:int n = len -0x80 ;if (unlikely (n >2 )) goto length_too_long; -if (unlikely (dp >= datalen - n)) +if (unlikely (n > datalen - dp)) goto data_overrun_error; hdr += n;for (len =0 ; n >0 ; n--) {
Greg Kroah-Hartman
maintainerPATCH 36/56 ARM: 8720/1: ensure dump_instr() checks addr_limit
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.
When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address.
Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory.
So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this.
--- arch/arm/kernel/traps.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-)
arch/arm/kernel/traps.c +18 -10
@@ -132,30 +132,26 @@ static void dump_mem(const char *lvl, coset_fs (fs); } -static void dump_instr (const char *lvl,struct pt_regs *regs) +static void __dump_instr (const char *lvl,struct pt_regs *regs) {unsigned long addr =instruction_pointer (regs);const int thumb =thumb_mode (regs);const int width = thumb ?4 :8 ; -mm_segment_t fs;char str[sizeof ("00000000 " ) *5 +2 +1 ], *p = str;int i;/* -* We need to switch to kernel mode so that we can use __get_user -* to safely read from kernel space. Note that we now dump the -* code first, just in case the backtrace kills us. +* Note that we now dump the code first, just in case the backtrace +* kills us. */ - fs =get_fs (); -set_fs (KERNEL_DS );for (i =-4 ; i <1 + !!thumb; i++) {unsigned int val, bad;if (thumb) - bad =__get_user (val, &((u16 *)addr)[i]); + bad =get_user (val, &((u16 *)addr)[i]);else - bad =__get_user (val, &((u32 *)addr)[i]); + bad =get_user (val, &((u32 *)addr)[i]);if (!bad) p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ",
@@ -166,8 +162,20 @@ static void dump_instr(const char *lvl, } }printk ("%sCode: %s\n" , lvl, str); +} -set_fs (fs); +static void dump_instr (const char *lvl,struct pt_regs *regs) +{ +mm_segment_t fs; + +if (!user_mode (regs)) { + fs =get_fs (); +set_fs (KERNEL_DS ); +__dump_instr (lvl, regs); +set_fs (fs); + }else { +__dump_instr (lvl, regs); + } }#ifdef CONFIG_ARM_UNWIND
Greg Kroah-Hartman
maintainerPATCH 37/56 ALSA: seq: Fix OSS sysex delivery in OSS emulation
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream.
The SYSEX event delivery in OSS sequencer emulation assumed that the event is encoded in the variable-length data with the straight buffering. This was the normal behavior in the past, but during the development, the chained buffers were introduced for carrying more data, while the OSS code was left intact. As a result, when a SYSEX event with the chained buffer data is passed to OSS sequencer port, it may end up with the wrong memory access, as if it were having a too large buffer.
This patch addresses the bug, by applying the buffer data expansion by the generic snd_seq_dump_var_event() helper function.
--- sound/core/seq/oss/seq_oss_midi.c | 4 +--- sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++++++++++++++++++++++ sound/core/seq/oss/seq_oss_readq.h | 2 ++ 3 files changed, 32 insertions(+), 3 deletions(-)
sound/core/seq/oss/seq_oss_midi.c +1 -3
@@ -612,9 +612,7 @@ send_midi_event(struct seq_oss_devinfo *if (!dp->timer->running) len =snd_seq_oss_timer_start (dp->timer);if (ev->type ==SNDRV_SEQ_EVENT_SYSEX ) { -if ((ev->flags &SNDRV_SEQ_EVENT_LENGTH_MASK ) ==SNDRV_SEQ_EVENT_LENGTH_VARIABLE ) -snd_seq_oss_readq_puts (dp->readq, mdev->seq_device, - ev->data.ext.ptr, ev->data.ext.len); +snd_seq_oss_readq_sysex (dp->readq, mdev->seq_device, ev); }else { len =snd_midi_event_decode (mdev->coder, msg,sizeof (msg), ev);if (len >0 )
sound/core/seq/oss/seq_oss_readq.c +29 -0
@@ -118,6 +118,35 @@ snd_seq_oss_readq_puts(struct seq_oss_re }/* +* put MIDI sysex bytes; the event buffer may be chained, thus it has +* to be expanded via snd_seq_dump_var_event(). +*/ +struct readq_sysex_ctx { +struct seq_oss_readq *readq; +int dev; +}; + +static int readq_dump_sysex (void *ptr,void *buf,int count) +{ +struct readq_sysex_ctx *ctx = ptr; + +return snd_seq_oss_readq_puts (ctx->readq, ctx->dev, buf, count); +} + +int snd_seq_oss_readq_sysex (struct seq_oss_readq *q,int dev, +struct snd_seq_event *ev) +{ +struct readq_sysex_ctx ctx = { + .readq = q, + .dev = dev + }; + +if ((ev->flags &SNDRV_SEQ_EVENT_LENGTH_MASK ) !=SNDRV_SEQ_EVENT_LENGTH_VARIABLE ) +return 0 ; +return snd_seq_dump_var_event (ev, readq_dump_sysex, &ctx); +} + +/* * copy an event to input queue: * return zero if enqueued */
sound/core/seq/oss/seq_oss_readq.h +2 -0
@@ -44,6 +44,8 @@ void snd_seq_oss_readq_delete(struct seqvoid snd_seq_oss_readq_clear (struct seq_oss_readq *readq);unsigned int snd_seq_oss_readq_poll (struct seq_oss_readq *readq,struct file *file,poll_table *wait);int snd_seq_oss_readq_puts (struct seq_oss_readq *readq,int dev,unsigned char *data,int len); +int snd_seq_oss_readq_sysex (struct seq_oss_readq *q,int dev, +struct snd_seq_event *ev);int snd_seq_oss_readq_put_event (struct seq_oss_readq *readq,union evrec *ev);int snd_seq_oss_readq_put_timestamp (struct seq_oss_readq *readq,unsigned long curt,int seq_mode);int snd_seq_oss_readq_pick (struct seq_oss_readq *q,union evrec *rec);
Greg Kroah-Hartman
maintainerPATCH 38/56 ALSA: seq: Avoid invalid lockdep class warning
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream.
The recent fix for adding rwsem nesting annotation was using the given "hop" argument as the lock subclass key. Although the idea itself works, it may trigger a kernel warning like:
BUG: looking up invalid subclass: 8 ....
since the lockdep has a smaller number of subclasses (8) than we currently allow for the hops there (10).
The current definition is merely a sanity check for avoiding the too deep delivery paths, and the 8 hops are already enough. So, as a quick fix, just follow the max hops as same as the max lockdep subclasses.
--- include/sound/seq_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
include/sound/seq_kernel.h +2 -1
@@ -49,7 +49,8 @@ typedef union snd_seq_timestamp snd_seq_#define SNDRV_SEQ_DEFAULT_CLIENT_EVENTS 200/* max delivery path length */ -#define SNDRV_SEQ_MAX_HOPS 10 +/* NOTE: this shouldn't be greater than MAX_LOCKDEP_SUBCLASSES */ +#define SNDRV_SEQ_MAX_HOPS 8/* max size of event size */ #define SNDRV_SEQ_MAX_EVENT_LEN 0x3fffffff
Greg Kroah-Hartman
maintainerPATCH 39/56 MIPS: microMIPS: Fix incorrect mask in insn_table_MM
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit 77238e76b9156d28d86c1e31c00ed2960df0e4de upstream.
It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS".
This issue was detected with the help of Coccinelle.
Patchwork: https://patchwork.linux-mips.org/patch/17551/
--- arch/mips/mm/uasm-micromips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/mm/uasm-micromips.c +1 -1
@@ -75,7 +75,7 @@ static struct insn insn_table_MM[] = { { insn_jr, M(mm_pool32a_op, 0, 0, 0, mm_jalr_op, mm_pool32axf_op), RS }, { insn_lb, M(mm_lb32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ld, 0, 0 }, - { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RS | RS | SIMM }, + { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ll, M(mm_pool32c_op, 0, 0, (mm_ll_func << 1), 0, 0), RS | RT | SIMM }, { insn_lld, 0, 0 }, { insn_lui, M(mm_pool32i_op, mm_lui_op, 0, 0, 0, 0), RS | SIMM },
Greg Kroah-Hartman
maintainerPATCH 40/56 MIPS: Fix CM region target definitions
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 6a6cba1d945a7511cdfaf338526871195e420762 upstream.
The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon.
Fix this by changing our macros to match the documentated target values.
The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle.
Patchwork: https://patchwork.linux-mips.org/patch/17562/
--- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/mips/include/asm/mips-cm.h +2 -2
@@ -238,8 +238,8 @@ BUILD_CM_Cx_R_(tcid_8_priority, 0x80)#define CM_GCR_BASE_GCRBASE_MSK (_ULCAST_(0x1ffff) << 15)#define CM_GCR_BASE_CMDEFTGT_SHF 0#define CM_GCR_BASE_CMDEFTGT_MSK (_ULCAST_(0x3) << 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1#define CM_GCR_BASE_CMDEFTGT_IOCU0 2#define CM_GCR_BASE_CMDEFTGT_IOCU1 3
Greg Kroah-Hartman
maintainerPATCH 41/56 MIPS: SMP: Use a completion event to signal CPU up
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <[email protected]>
commit a00eeede507c975087b7b8df8cf2c9f88ba285de upstream.
If a secondary CPU failed to start, for any reason, the CPU requesting the secondary to start would get stuck in the loop waiting for the secondary to be present in the cpu_callin_map.
Rather than that, use a completion event to signal that the secondary CPU has started and is waiting to synchronise counters.
Since the CPU presence will no longer be marked in cpu_callin_map, remove the redundant test from arch_cpu_idle_dead().
Patchwork: https://patchwork.linux-mips.org/patch/14502/
--- arch/mips/kernel/process.c | 4 +--- arch/mips/kernel/smp.c | 15 +++++++++------ 2 files changed, 10 insertions(+), 9 deletions(-)
arch/mips/kernel/process.c +1 -3
@@ -49,9 +49,7 @@#ifdef CONFIG_HOTPLUG_CPU void arch_cpu_idle_dead (void ) { -/* What the heck is this check doing ? */ -if (!cpumask_test_cpu (smp_processor_id (), &cpu_callin_map)) -play_dead (); +play_dead (); }#endif
arch/mips/kernel/smp.c +9 -6
@@ -64,6 +64,8 @@ EXPORT_SYMBOL(cpu_sibling_map);cpumask_t cpu_core_map[NR_CPUS ]__read_mostly ;EXPORT_SYMBOL (cpu_core_map); +static DECLARE_COMPLETION (cpu_running); +/* * A logcal cpu mask containing only one VPE per core to * reduce the number of IPIs on large MT systems.
@@ -174,7 +176,7 @@ asmlinkage void start_secondary(void)cpumask_set_cpu (cpu, &cpu_coherent_mask);notify_cpu_starting (cpu); -cpumask_set_cpu (cpu, &cpu_callin_map); +complete (&cpu_running);synchronise_count_slave (cpu);set_cpu_online (cpu, true);
@@ -242,7 +244,6 @@ void smp_prepare_boot_cpu(void) {set_cpu_possible (0 , true);set_cpu_online (0 , true); -cpumask_set_cpu (0 , &cpu_callin_map); }int __cpu_up (unsigned int cpu,struct task_struct *tidle)
@@ -250,11 +251,13 @@ int __cpu_up(unsigned int cpu, struct ta mp_ops->boot_secondary (cpu, tidle);/* -* Trust is futile. We should really have timeouts ... +* We must check for timeout here, as the CPU will not be marked +* online until the counters are synchronised. */ -while (!cpumask_test_cpu (cpu, &cpu_callin_map)) { -udelay (100 ); -schedule (); +if (!wait_for_completion_timeout (&cpu_running, +msecs_to_jiffies (1000 ))) { +pr_crit ("CPU%u: failed to start\n" , cpu); +return -EIO ; }synchronise_count_master (cpu);
Greg Kroah-Hartman
maintainerPATCH 42/56 MIPS: Fix race on setting and getting cpu_online_mask
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matija Glavinic Pecotic <[email protected]>
commit 6f542ebeaee0ee552a902ce3892220fc22c7ec8e upstream.
While testing cpu hoptlug (cpu down and up in loops) on kernel 4.4, it was observed that occasionally check for cpu online will fail in kernel/cpu.c, _cpu_up:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/cpu.c?h=v4.4.79#n485
518 /* Arch-specific enabling code. */
519 ret = __cpu_up(cpu, idle);
520
521 if (ret != 0)
522 goto out_notify;
523 BUG_ON(!cpu_online(cpu));
Reason is race between start_secondary and _cpu_up. cpu_callin_map is set before cpu_online_mask. In __cpu_up, cpu_callin_map is waited for, but cpu online mask is not, resulting in race in which secondary processor started and set cpu_callin_map, but not yet set the online mask,resulting in above BUG being hit.
Upstream differs in the area. cpu_online check is in bringup_wait_for_ap, which is after cpu reached AP_ONLINE_IDLE,where secondary passed its start function. Nonetheless, fix makes start_secondary safe and not depending on other locks throughout the code. It protects as well against cpu_online checks put in between sometimes in the future.
Fix this by moving completion after all flags are set.
Patchwork: https://patchwork.linux-mips.org/patch/16925/
--- arch/mips/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/mips/kernel/smp.c +3 -3
@@ -176,9 +176,6 @@ asmlinkage void start_secondary(void)cpumask_set_cpu (cpu, &cpu_coherent_mask);notify_cpu_starting (cpu); -complete (&cpu_running); -synchronise_count_slave (cpu); -set_cpu_online (cpu, true);set_cpu_sibling_map (cpu);
@@ -186,6 +183,9 @@ asmlinkage void start_secondary(void)calculate_cpu_foreign_map (); +complete (&cpu_running); +synchronise_count_slave (cpu); +/* * irq will be enabled in ->smp_finish(), enabling it too early * is dangerous.
Greg Kroah-Hartman
maintainerPATCH 43/56 MIPS: SMP: Fix deadlock & online race
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Redfearn <[email protected]>
commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream.
Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP:
Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock.
The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation.
As noted in the commit message, upstream differs in this area. Commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing.
To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised.
This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up").
Patchwork: https://patchwork.linux-mips.org/patch/17376/
--- arch/mips/kernel/smp.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
arch/mips/kernel/smp.c +16 -6
@@ -64,6 +64,7 @@ EXPORT_SYMBOL(cpu_sibling_map);cpumask_t cpu_core_map[NR_CPUS ]__read_mostly ;EXPORT_SYMBOL (cpu_core_map); +static DECLARE_COMPLETION (cpu_starting);static DECLARE_COMPLETION (cpu_running);/*
@@ -176,6 +177,12 @@ asmlinkage void start_secondary(void)cpumask_set_cpu (cpu, &cpu_coherent_mask);notify_cpu_starting (cpu); +/* Notify boot CPU that we're starting & ready to sync counters */ +complete (&cpu_starting); + +synchronise_count_slave (cpu); + +/* The CPU is running and counters synchronised, now mark it online */ set_cpu_online (cpu, true);set_cpu_sibling_map (cpu);
@@ -183,8 +190,11 @@ asmlinkage void start_secondary(void)calculate_cpu_foreign_map (); +/* +* Notify boot CPU that we're up & online and it can safely return +* from __cpu_up +*/ complete (&cpu_running); -synchronise_count_slave (cpu);/* * irq will be enabled in ->smp_finish(), enabling it too early
@@ -250,17 +260,17 @@ int __cpu_up(unsigned int cpu, struct ta { mp_ops->boot_secondary (cpu, tidle); -/* -* We must check for timeout here, as the CPU will not be marked -* online until the counters are synchronised. -*/ -if (!wait_for_completion_timeout (&cpu_running, +/* Wait for CPU to start and be ready to sync counters */ +if (!wait_for_completion_timeout (&cpu_starting,msecs_to_jiffies (1000 ))) {pr_crit ("CPU%u: failed to start\n" , cpu);return -EIO ; }synchronise_count_master (cpu); + +/* Wait for CPU to finish startup & mark itself online before return */ +wait_for_completion (&cpu_running);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 44/56 test: firmware_class: report errors properly on failure
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 47e0bbb7fa985a0f1b5794a8653fae4f8f49de77 upstream.
request_firmware() failures currently won't get reported at all (the error code is discarded). What's more, we get confusing messages, like:
# echo -n notafile > /sys/devices/virtual/misc/test_firmware/trigger_request
[ 8280.311856] test_firmware: loading 'notafile'
[ 8280.317042] test_firmware: load of 'notafile' failed: -2
[ 8280.322445] test_firmware: loaded: 0
# echo $?
0Report the failures via write() errors, and don't say we "loaded" anything.
--- lib/test_firmware.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
lib/test_firmware.c +8 -3
@@ -65,14 +65,19 @@ static ssize_t trigger_request_store(strrelease_firmware (test_firmware); test_firmware =NULL ; rc =request_firmware (&test_firmware, name, dev); -if (rc) +if (rc) {pr_info ("load of '%s' failed: %d\n" , name, rc); -pr_info ("loaded: %zu\n" , test_firmware ? test_firmware->size :0 ); + goto out; + } +pr_info ("loaded: %zu\n" , test_firmware->size); + rc = count; + +out:mutex_unlock (&test_fw_mutex);kfree (name); -return count; +return rc; }static DEVICE_ATTR_WO (trigger_request);
Greg Kroah-Hartman
maintainerPATCH 45/56 selftests: firmware: add empty string and async tests
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 1b1fe542b6f010cf6bc7e1c92805e1c0e133e007 upstream.
Now that we've added a 'trigger_async_request' knob to test the request_firmware_nowait() API, let's use it. Also add tests for the empty ("") string, since there have been a couple errors in that handling already.
Since we now have real ways that the sysfs write might fail, let's add the appropriate check on the 'echo' lines too.
--- tools/testing/selftests/firmware/fw_filesystem.sh | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
tools/testing/selftests/firmware/fw_filesystem.sh +9 -1
@@ -48,8 +48,16 @@ echo "ABCD0123" >"$FW" NAME=$(basename "$FW") +if printf '\000' >"$DIR"/trigger_request; then + echo "$0: empty filename should not succeed" >&2 + exit 1 +fi + # Request a firmware that doesn't exist, it should fail. -echo -n "nope-$NAME" >"$DIR"/trigger_request +if echo -n "nope-$NAME" >"$DIR"/trigger_request; then + echo "$0: firmware shouldn't have loaded" >&2 + exit 1 +fi if diff -q "$FW" /dev/test_firmware >/dev/null ; then echo "$0: firmware was not expected to match" >&2 exit 1
Greg Kroah-Hartman
maintainerPATCH 46/56 selftests: firmware: send expected errors to /dev/null
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luis R. Rodriguez <[email protected]>
commit 880444e214cfd293a2e8cc4bd3505f7ffa6ce33a upstream.
Error that we expect should not be spilled to stdout.
Without this we get:
./fw_filesystem.sh: line 58: printf: write error: Invalid argument ./fw_filesystem.sh: line 63: printf: write error: No such device ./fw_filesystem.sh: line 69: echo: write error: No such file or directory ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works
With it:
./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works
--- tools/testing/selftests/firmware/fw_filesystem.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/testing/selftests/firmware/fw_filesystem.sh +2 -2
@@ -48,13 +48,13 @@ echo "ABCD0123" >"$FW" NAME=$(basename "$FW") -if printf '\000' >"$DIR"/trigger_request; then +if printf '\000' >"$DIR"/trigger_request 2> /dev/null; then echo "$0: empty filename should not succeed" >&2 exit 1 fi # Request a firmware that doesn't exist, it should fail. -if echo -n "nope-$NAME" >"$DIR"/trigger_request; then +if echo -n "nope-$NAME" >"$DIR"/trigger_request 2> /dev/null; then echo "$0: firmware shouldn't have loaded" >&2 exit 1 fi
Greg Kroah-Hartman
maintainerPATCH 47/56 tools: firmware: check for distro fallback udev cancel rule
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luis R. Rodriguez <[email protected]>
commit afb999cdef69148f366839e74470d8f5375ba5f1 upstream.
Some distributions (Debian, OpenSUSE) have a udev rule in place to cancel all fallback mechanism uevents immediately. This would obviously make it hard to test against the fallback mechanism test interface, so we need to check for this.
--- tools/testing/selftests/firmware/fw_userhelper.sh | 28 ++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-)
tools/testing/selftests/firmware/fw_userhelper.sh +26 -2
@@ -64,9 +64,33 @@ trap "test_finish" EXIT echo "ABCD0123" >"$FW" NAME=$(basename "$FW") +DEVPATH="$DIR"/"nope-$NAME"/loading + # Test failure when doing nothing (timeout works). -echo 1 >/sys/class/firmware/timeout -echo -n "$NAME" >"$DIR"/trigger_request +echo -n 2 >/sys/class/firmware/timeout +echo -n "nope-$NAME" >"$DIR"/trigger_request 2>/dev/null & + +# Give the kernel some time to load the loading file, must be less +# than the timeout above. +sleep 1 +if [ ! -f $DEVPATH ]; then + echo "$0: fallback mechanism immediately cancelled" + echo "" + echo "The file never appeared: $DEVPATH" + echo "" + echo "This might be a distribution udev rule setup by your distribution" + echo "to immediately cancel all fallback requests, this must be" + echo "removed before running these tests. To confirm look for" + echo "a firmware rule like /lib/udev/rules.d/50-firmware.rules" + echo "and see if you have something like this:" + echo "" + echo "SUBSYSTEM==\"firmware\", ACTION==\"add\", ATTR{loading}=\"-1\"" + echo "" + echo "If you do remove this file or comment out this line before" + echo "proceeding with these tests." + exit 1 +fi + if diff -q "$FW" /dev/test_firmware >/dev/null ; then echo "$0: firmware was not expected to match" >&2 exit 1
Greg Kroah-Hartman
maintainerPATCH 48/56 MIPS: AR7: Defer registration of GPIO
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonas Gorski <[email protected]>
commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream.
When called from prom init code, ar7_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time.
Move ar7_gpio_init() to ar7_register_devices() (a device_initcall) where kmalloc works.
Patchwork: https://patchwork.linux-mips.org/patch/17542/
--- arch/mips/ar7/platform.c | 4 ++++ arch/mips/ar7/prom.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-)
arch/mips/ar7/platform.c +4 -0
@@ -654,6 +654,10 @@ static int __init ar7_register_devices(vu32 val;int res; + res =ar7_gpio_init (); +if (res) +pr_warn ("unable to register gpios: %d\n" , res); + res =ar7_register_uarts ();if (res)pr_err ("unable to setup uart(s): %d\n" , res);
arch/mips/ar7/prom.c +0 -2
@@ -246,8 +246,6 @@ void __init prom_init(void)ar7_init_cmdline (fw_arg0, (char **)fw_arg1);ar7_init_env ((struct env_var *)fw_arg2);console_config (); - -ar7_gpio_init (); }#define PORT (offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4)))
Greg Kroah-Hartman
maintainerPATCH 49/56 MIPS: AR7: Ensure that serial ports are properly set up
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oswald Buddenhagen <[email protected]>
commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.
Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is never copied, resulting in a dead port.
Patchwork: https://patchwork.linux-mips.org/patch/17543/
--- arch/mips/ar7/platform.c | 1 + 1 file changed, 1 insertion(+)
arch/mips/ar7/platform.c +1 -0
@@ -576,6 +576,7 @@ static int __init ar7_register_uarts(voi uart_port.type =PORT_AR7 ; uart_port.uartclk =clk_get_rate (bus_clk) /2 ; uart_port.iotype =UPIO_MEM32 ; + uart_port.flags =UPF_FIXED_TYPE ; uart_port.regshift =2 ; uart_port.line =0 ;
Greg Kroah-Hartman
maintainerPATCH 50/56 Input: elan_i2c - add ELAN060C to the ACPI table
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream.
ELAN060C touchpad uses elan_i2c as its driver. It can be found on Lenovo ideapad 320-14AST.
--- drivers/input/mouse/elan_i2c_core.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/mouse/elan_i2c_core.c +1 -0
@@ -1240,6 +1240,7 @@ static const struct acpi_device_id elan_ { "ELAN0605", 0 }, { "ELAN0609", 0 }, { "ELAN060B", 0 }, + { "ELAN060C", 0 }, { "ELAN0611", 0 }, { "ELAN1000", 0 }, { }
Greg Kroah-Hartman
maintainerPATCH 51/56 drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sinclair Yeh <[email protected]>
commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream.
This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work around mode set failure in 2D VMs")
With Wayland desktop and atomic mode set, during the mode setting process there is a moment when two framebuffer sized surfaces are being pinned. This was not an issue with Xorg.
Since this only happens during a mode change, there should be no performance impact by increasing allowable mem_size.
--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +1 -1
@@ -708,7 +708,7 @@ static int vmw_driver_load(struct drm_de* allocation taken by fbdev */ if (!(dev_priv->capabilities &SVGA_CAP_3D )) - mem_size *=2 ; + mem_size *=3 ; dev_priv->max_mob_pages = mem_size *1024 /PAGE_SIZE ; dev_priv->prim_bb_mem =
Greg Kroah-Hartman
maintainerPATCH 52/56 rbd: use GFP_NOIO for parent stat and data requests
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <[email protected]>
commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.
rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on the writeback path for cloned images -- we attempt a stat on the parent object to see if it exists and potentially read it in to call copyup. GFP_NOIO should be used instead of GFP_KERNEL here.
--- drivers/block/rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/block/rbd.c +2 -2
@@ -2736,7 +2736,7 @@ static int rbd_img_obj_parent_read_full(* from the parent. */ page_count = (u32 )calc_pages_for (0 , length); - pages =ceph_alloc_page_vector (page_count,GFP_KERNEL ); + pages =ceph_alloc_page_vector (page_count,GFP_NOIO );if (IS_ERR (pages)) { result =PTR_ERR (pages); pages =NULL ;
@@ -2863,7 +2863,7 @@ static int rbd_img_obj_exists_submit(str*/ size =sizeof (__le64) +sizeof (__le32) +sizeof (__le32); page_count = (u32 )calc_pages_for (0 , size); - pages =ceph_alloc_page_vector (page_count,GFP_KERNEL ); + pages =ceph_alloc_page_vector (page_count,GFP_NOIO );if (IS_ERR (pages))return PTR_ERR (pages);
Greg Kroah-Hartman
maintainerPATCH 53/56 can: sun4i: handle overrun in RX FIFO
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gerhard Bertelsmann <[email protected]>
commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream.
SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not drained fast enough (overrun) it's getting mangled. Already received frames are dropped - the data can't be restored.
--- drivers/net/can/sun4i_can.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/net/can/sun4i_can.c +10 -2
@@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi } stats->rx_over_errors++; stats->rx_errors++; + +/* reset the CAN IP by entering reset mode +* ignoring timeout error +*/ +set_reset_mode (dev); +set_normal_mode (dev); +/* clear bit */ sun4i_can_write_cmdreg (priv,SUN4I_CMD_CLEAR_OR_FLAG ); }
@@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(inetif_wake_queue (dev);can_led_event (dev,CAN_LED_EVENT_TX ); } -if (isrc &SUN4I_INT_RBUF_VLD ) { -/* receive interrupt */ +if ((isrc &SUN4I_INT_RBUF_VLD ) && + !(isrc &SUN4I_INT_DATA_OR )) { +/* receive interrupt - don't read if overrun occurred */ while (status &SUN4I_STA_RBUF_RDY ) {/* RX buffer is not empty */ sun4i_can_rx (dev);
Greg Kroah-Hartman
maintainerPATCH 55/56 x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Borislav Petkov <[email protected]>
commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.
The warning below says it all:
BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is __this_cpu_preempt_check CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4 Call Trace: dump_stack check_preemption_disabled ? do_early_param __this_cpu_preempt_check arch_perfmon_init op_nmi_init ? alloc_pci_root_info oprofile_arch_init oprofile_init do_one_initcall ...
These accessors should not have been used in the first place: it is PPro so no mixed silicon revisions and thus it can simply use boot_cpu_data.
--- arch/x86/oprofile/op_model_ppro.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/oprofile/op_model_ppro.c +2 -2
@@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters( eax.full =cpuid_eax (0xa );/* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ -if (eax.split.version_id ==0 &&__this_cpu_read (cpu_info.x86) ==6 && -__this_cpu_read (cpu_info.x86_model) ==15 ) { +if (eax.split.version_id ==0 && boot_cpu_data.x86 ==6 && + boot_cpu_data.x86_model ==15 ) { eax.split.version_id =2 ; eax.split.num_counters =2 ; eax.split.bit_width =40 ;
Greg Kroah-Hartman
maintainerPATCH 56/56 PKCS#7: fix unitialized boolean want
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
commit 06aae592425701851e02bb850cb9f4997f0ae163 upstream.
The boolean want is not initialized and hence garbage. The default should be false (later it is only set to true on tne sinfo->authattrs check).
Found with static analysis using CoverityScan
--- crypto/asymmetric_keys/pkcs7_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
crypto/asymmetric_keys/pkcs7_parser.c +1 -1
@@ -87,7 +87,7 @@ EXPORT_SYMBOL_GPL(pkcs7_free_message);static int pkcs7_check_authattrs (struct pkcs7_message *msg) {struct pkcs7_signed_info *sinfo; -bool want; +bool want = false; sinfo = msg->signed_infos;if (!sinfo)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 116 pass: 116 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm. One regression detected on x86. We’re doing some re-runs to see if it’s a solid failure or intermittent. It is however a testcase which hasn’t failed in the past. Also as per usual the HiKey results are reported separate because the platform support isn’t in tree.
Summary
------------------------------------------------------------------------
kernel: 4.4.98-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 528c687b455dced176c5e4be9275fb5a2ccdd60a
git describe: v4.4.97-57-g528c687b455d
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.97-57-g528c687b455d
Regressions (compared to build v4.4.96)
------------------------------------------------------------------------
dell-poweredge-r200 - x86_64:
ltp-syscalls-tests:
* readahead02
* test src: git://github.com/linux-test-project/ltp.git
Boards, architectures and test suites:
-------------------------------------
juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 8, fail: 13, pass: 31 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 159, fail: 3, pass: 937 (known failures)
* ltp-timers-tests - pass: 12
x15 - arm
* boot - pass: 20
* kselftest - skip: 12, fail: 12, pass: 29 (known failures)
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, fail: 3, pass: 1036 (known failures)
* ltp-timers-tests - pass: 12
dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - skip: 10, fail: 15, pass: 42 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957
* ltp-timers-tests - pass: 12
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
And the hikey results.
Summary
------------------------------------------------------------------------
kernel: 4.4.98-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.98-rc1-hikey-20171113
git commit: 96176dea6d2c63d2f94877204d06f4d94b9e3b05
git describe: 4.4.98-rc1-hikey-20171113
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.98-rc1-hikey-20171113
No regressions (compared to build 4.4.96-rc1-hikey-20171031)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 10, fail: 13, pass: 31 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 125, fail: 3, pass: 979 (known failures)
* ltp-timers-tests - pass: 12
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Greg Kroah-Hartman
maintainerQuoted 18 lines · Tom Gall
Quoted 18 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Results from Linaro’s test farm. One regression detected on x86. We’re doing some re-runs to see if it’s a solid failure or intermittent. It is however a testcase which hasn’t failed in the past. Also as per usual the HiKey results are reported separate because the platform support isn’t in tree.
I thought I gave you enough \n in the past, did you use all of them up? :(
Anyway, what is the new x86 failure?
Is it this:
Quoted 1 line
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957
If so, any pointers to the specific log messages, and which tests are failing? Digging through the web site isn't the easiest...
And kselftests should have gotten less failures this time around, given that some of them were patched in this -rc, why didn't that number go down?
thanks,
greg k-h
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Tom Gall
Quoted 22 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Quoted 9 lines
Quoted 1 line
Results from Linaro’s test farm. One regression detected on x86. We’re doing some re-runs to see if it’s a solid failure or intermittent. It is however a testcase which hasn’t failed in the past. Also as per usual the HiKey results are reported separate because the platform support isn’t in tree.
I thought I gave you enough \n in the past, did you use all of them up? :(
Anyway, what is the new x86 failure?
Is it this:
Quoted 1 line
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957
It's
readahead02 0 TINFO : creating test file of size: 67108864 readahead02 0 TINFO : read_testfile(0) readahead02 0 TINFO : read_testfile(1) readahead02 0 TINFO : max ra estimate: 262144 readahead02 0 TINFO : readahead calls made: 256 readahead02 1 TPASS : offset is still at 0 as expected readahead02 0 TINFO : read_testfile(0) took: 951656 usec readahead02 0 TINFO : read_testfile(1) took: 921704 usec readahead02 0 TINFO : read_testfile(0) read: 67108864 bytes readahead02 0 TINFO : read_testfile(1) read: 51257344 bytes readahead02 2 TPASS : readahead saved some I/O readahead02 0 TINFO : cache can hold at least: 86180 kB readahead02 0 TINFO : read_testfile(0) used cache: 65308 kB readahead02 0 TINFO : read_testfile(1) used cache: 15332 kB readahead02 0 TWARN : readahead02.c:351: using less cache than expected
Source of the test:
https://github.com/linux-test-project/ltp/blob/20170929/testcases/kernel/syscalls/readahead/readahead02.c#L351
It's the first time this test failed since we started running it. I'll ask Naresh to look into it.
Quoted 7 lines
If so, any pointers to the specific log messages, and which tests are failing? Digging through the web site isn't the easiest...
And kselftests should have gotten less failures this time around, given that some of them were patched in this -rc, why didn't that number go down?
Do you mean the tests were patched or the kernel code that was exercised? If it's the former, it won't have effect as we're using the kselftests sources from 4.13
milosz
Quoted 53 lines · Milosz Wasilewski
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Tom Gall
Quoted 22 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Quoted 9 lines
Quoted 1 line
Results from Linaro’s test farm. One regression detected on x86. We’re doing some re-runs to see if it’s a solid failure or intermittent. It is however a testcase which hasn’t failed in the past. Also as per usual the HiKey results are reported separate because the platform support isn’t in tree.
I thought I gave you enough \n in the past, did you use all of them up? :(
Anyway, what is the new x86 failure?
Is it this:
Quoted 1 line
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957
It's
readahead02 0 TINFO : creating test file of size: 67108864 readahead02 0 TINFO : read_testfile(0) readahead02 0 TINFO : read_testfile(1) readahead02 0 TINFO : max ra estimate: 262144 readahead02 0 TINFO : readahead calls made: 256 readahead02 1 TPASS : offset is still at 0 as expected readahead02 0 TINFO : read_testfile(0) took: 951656 usec readahead02 0 TINFO : read_testfile(1) took: 921704 usec readahead02 0 TINFO : read_testfile(0) read: 67108864 bytes readahead02 0 TINFO : read_testfile(1) read: 51257344 bytes readahead02 2 TPASS : readahead saved some I/O readahead02 0 TINFO : cache can hold at least: 86180 kB readahead02 0 TINFO : read_testfile(0) used cache: 65308 kB readahead02 0 TINFO : read_testfile(1) used cache: 15332 kB readahead02 0 TWARN : readahead02.c:351: using less cache than expected
Quoted 5 lines
Source of the test:
https://github.com/linux-test-project/ltp/blob/20170929/testcases/kernel/syscalls/readahead/readahead02.c#L351It's the first time this test failed since we started running it. I'll ask Naresh to look into it.
Please ignore this LTP readahead02 failure.
Re-tested and it got pass.
- cd /opt/ltp/testcases/bin/
- export TMPDIR=/home
- ./readahead02
readahead02 0 TINFO : creating test file of size: 67108864 readahead02 0 TINFO : read_testfile(0) readahead02 0 TINFO : read_testfile(1) readahead02 0 TINFO : readahead calls made: 16384 readahead02 1 TPASS : offset is still at 0 as expected readahead02 0 TINFO : read_testfile(0) took: 973355 usec readahead02 0 TINFO : read_testfile(1) took: 281199 usec readahead02 0 TINFO : read_testfile(0) read: 67108864 bytes readahead02 0 TINFO : read_testfile(1) read: 0 bytes readahead02 2 TPASS : readahead saved some I/O readahead02 0 TINFO : cache can hold at least: 364856 kB readahead02 0 TINFO : read_testfile(0) used cache: 65252 kB readahead02 0 TINFO : read_testfile(1) used cache: 65368 kB readahead02 3 TPASS : using cache as expected
Quoted 9 lines
Quoted 8 lines
If so, any pointers to the specific log messages, and which tests are failing? Digging through the web site isn't the easiest...
And kselftests should have gotten less failures this time around, given that some of them were patched in this -rc, why didn't that number go down?
Quoted 5 lines
Do you mean the tests were patched or the kernel code that was exercised? If it's the former, it won't have effect as we're using the kselftests sources from 4.13
milosz
- Naresh
Greg Kroah-Hartman
maintainerQuoted 68 lines · Naresh Kamboju
Quoted 53 lines · Milosz Wasilewski
Quoted 24 lines · Greg Kroah-Hartman
Quoted 23 lines · Tom Gall
Quoted 22 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.98 release. There are 56 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Nov 15 12:55:32 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Quoted 9 lines
Quoted 1 line
Results from Linaro’s test farm. One regression detected on x86. We’re doing some re-runs to see if it’s a solid failure or intermittent. It is however a testcase which hasn’t failed in the past. Also as per usual the HiKey results are reported separate because the platform support isn’t in tree.
I thought I gave you enough \n in the past, did you use all of them up? :(
Anyway, what is the new x86 failure?
Is it this:
Quoted 1 line
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957
It's
readahead02 0 TINFO : creating test file of size: 67108864 readahead02 0 TINFO : read_testfile(0) readahead02 0 TINFO : read_testfile(1) readahead02 0 TINFO : max ra estimate: 262144 readahead02 0 TINFO : readahead calls made: 256 readahead02 1 TPASS : offset is still at 0 as expected readahead02 0 TINFO : read_testfile(0) took: 951656 usec readahead02 0 TINFO : read_testfile(1) took: 921704 usec readahead02 0 TINFO : read_testfile(0) read: 67108864 bytes readahead02 0 TINFO : read_testfile(1) read: 51257344 bytes readahead02 2 TPASS : readahead saved some I/O readahead02 0 TINFO : cache can hold at least: 86180 kB readahead02 0 TINFO : read_testfile(0) used cache: 65308 kB readahead02 0 TINFO : read_testfile(1) used cache: 15332 kB readahead02 0 TWARN : readahead02.c:351: using less cache than expectedQuoted 5 lines
Source of the test:
https://github.com/linux-test-project/ltp/blob/20170929/testcases/kernel/syscalls/readahead/readahead02.c#L351It's the first time this test failed since we started running it. I'll ask Naresh to look into it.
Please ignore this LTP readahead02 failure.
Re-tested and it got pass.- cd
/opt/ltp/testcases/bin/
- export TMPDIR=/home
- ./readahead02
Quoted 14 lines
readahead02 0 TINFO : creating test file of size: 67108864 readahead02 0 TINFO : read_testfile(0) readahead02 0 TINFO : read_testfile(1) readahead02 0 TINFO : readahead calls made: 16384 readahead02 1 TPASS : offset is still at 0 as expected readahead02 0 TINFO : read_testfile(0) took: 973355 usec readahead02 0 TINFO : read_testfile(1) took: 281199 usec readahead02 0 TINFO : read_testfile(0) read: 67108864 bytes readahead02 0 TINFO : read_testfile(1) read: 0 bytes readahead02 2 TPASS : readahead saved some I/O readahead02 0 TINFO : cache can hold at least: 364856 kB readahead02 0 TINFO : read_testfile(0) used cache: 65252 kB readahead02 0 TINFO : read_testfile(1) used cache: 65368 kB readahead02 3 TPASS : using cache as expected
You all need to really fix up your testing systems... :(
And for x86, you can just run it on your desktop as a sanity check, why not do that at the least?
thanks,
greg k-h
Quoted 1 line · Greg Kroah-Hartman
On Wed, Nov 15, 2017 at 05:45:41PM +0530, Naresh Kamboju wrote:
...
Quoted 23 lines
Quoted 8 lines
Please ignore this LTP readahead02 failure.
Re-tested and it got pass.- cd
/opt/ltp/testcases/bin/
- export TMPDIR=/home
- ./readahead02Quoted 14 lines
readahead02 0 TINFO : creating test file of size: 67108864 readahead02 0 TINFO : read_testfile(0) readahead02 0 TINFO : read_testfile(1) readahead02 0 TINFO : readahead calls made: 16384 readahead02 1 TPASS : offset is still at 0 as expected readahead02 0 TINFO : read_testfile(0) took: 973355 usec readahead02 0 TINFO : read_testfile(1) took: 281199 usec readahead02 0 TINFO : read_testfile(0) read: 67108864 bytes readahead02 0 TINFO : read_testfile(1) read: 0 bytes readahead02 2 TPASS : readahead saved some I/O readahead02 0 TINFO : cache can hold at least: 364856 kB readahead02 0 TINFO : read_testfile(0) used cache: 65252 kB readahead02 0 TINFO : read_testfile(1) used cache: 65368 kB readahead02 3 TPASS : using cache as expected
Quoted 2 lines
You all need to really fix up your testing systems... :(
Hard lesson to learn. Tests are not as deterministic as we would like them to be. For my part, I tend to re-run qemu tests before I report failures because some failures are sporadic. After a couple of years I know the usual suspects, which helps. Adding an automatic retry mechanism might be useful.
Guenter