2018-10-08 18:35:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 000/113] 4.4.160-stable review

This is the start of the stable review cycle for the 4.4.160 release.
There are 113 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 Oct 10 17:55:13 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.160-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.160-rc1

Ashish Samant <[email protected]>
ocfs2: fix locking for res->tracking and dlm->tracking_list

Jann Horn <[email protected]>
proc: restrict kernel stack dumps to root

Leonard Crestez <[email protected]>
crypto: mxs-dcp - Fix wait logic on chan threads

Kai-Heng Feng <[email protected]>
ALSA: hda/realtek - Cannot adjust speaker's volume on Dell XPS 27 7760

Aurelien Aptel <[email protected]>
smb2: fix missing files in root share directory listing

Josh Abraham <[email protected]>
xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage

Olaf Hering <[email protected]>
xen: avoid crash in disable_hotplug_cpu

Vitaly Kuznetsov <[email protected]>
xen/manage: don't complain about an empty value in control/sysrq node

Dan Carpenter <[email protected]>
cifs: read overflow in is_valid_oplock_break()

Julian Wiedmann <[email protected]>
s390/qeth: don't dump past end of unknown HW header

Kai-Heng Feng <[email protected]>
r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED

Miguel Ojeda <[email protected]>
arm64: jump_label.h: use asm_volatile_goto macro instead of "asm goto"

Randy Dunlap <[email protected]>
hexagon: modify ffs() and fls() to return int

Randy Dunlap <[email protected]>
arch/hexagon: fix kernel/dma.c build warning

Joe Thornber <[email protected]>
dm thin metadata: try to avoid ever aborting transactions

Stephen Rothwell <[email protected]>
fs/cifs: suppress a string overflow warning

Ben Skeggs <[email protected]>
drm/nouveau/TBDdevinit: don't fail when PMU/PRE_OS is missing from VBIOS

Ben Hutchings <[email protected]>
USB: yurex: Check for truncation in yurex_read()

Jann Horn <[email protected]>
RDMA/ucma: check fd type in ucma_migrate_id()

Sandipan Das <[email protected]>
perf probe powerpc: Ignore SyS symbols irrespective of endianness

Stephen Boyd <[email protected]>
pinctrl: msm: Really mask level interrupts to prevent latching

Anton Vasilyev <[email protected]>
usb: gadget: fotg210-udc: Fix memory leak of fotg210->ep[i]

Daniel Black <[email protected]>
mm: madvise(MADV_DODUMP): allow hugetlbfs pages

Naoya Horiguchi <[email protected]>
tools/vm/page-types.c: fix "defined but not used" warning

Naoya Horiguchi <[email protected]>
tools/vm/slabinfo.c: fix sign-compare warning

Emmanuel Grumbach <[email protected]>
mac80211: shorten the IBSS debug messages

Ilan Peer <[email protected]>
mac80211: Fix station bandwidth setting after channel switch

Emmanuel Grumbach <[email protected]>
mac80211: fix a race between restart and CSA flows

Dan Carpenter <[email protected]>
cfg80211: fix a type issue in ieee80211_chandef_to_operating_class()

Jon Kuhn <[email protected]>
fs/cifs: don't translate SFM_SLASH (U+F026) to backslash

Jia-Ju Bai <[email protected]>
net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx()

Masahiro Yamada <[email protected]>
i2c: uniphier-f: issue STOP only for last message or I2C_M_STOP

Masahiro Yamada <[email protected]>
i2c: uniphier: issue STOP only for last message or I2C_M_STOP

Xiao Ni <[email protected]>
RAID10 BUG_ON in raise_barrier when force is true and conf->barrier is 0

Arunk Khandavalli <[email protected]>
cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE

Yuan-Chi Pang <[email protected]>
mac80211: mesh: fix HWMP sequence numbering to follow standard

Michael Hennerich <[email protected]>
gpio: adp5588: Fix sleep-in-atomic-context bug

Danek Duvall <[email protected]>
mac80211_hwsim: correct use of IEEE80211_VHT_CAP_RXSTBC_X

Danek Duvall <[email protected]>
mac80211: correct use of IEEE80211_VHT_CAP_RXSTBC_X

Paul Mackerras <[email protected]>
KVM: PPC: Book3S HV: Don't truncate HPTE index in xlate function

Sakari Ailus <[email protected]>
media: v4l: event: Prevent freeing event subscriptions while accessed

Marc Zyngier <[email protected]>
arm64: KVM: Sanitize PSTATE.M when being set from userspace

Suzuki K Poulose <[email protected]>
arm64: cpufeature: Track 32bit EL0 support

Mika Westerberg <[email protected]>
i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus

Dan Carpenter <[email protected]>
hwmon: (adt7475) Make adt7475_read_word() return errors

Lothar Felten <[email protected]>
hwmon: (ina2xx) fix sysfs shunt resistor read access

Bo Chen <[email protected]>
e1000: ensure to free old tx/rx rings in set_ringparam()

Bo Chen <[email protected]>
e1000: check on netif_running() before calling e1000_up()

Huazhong Tan <[email protected]>
net: hns: fix length and page_offset overflow when CONFIG_ARM64_64K_PAGES

Anson Huang <[email protected]>
thermal: of-thermal: disable passive polling when thermal zone is disabled

Theodore Ts'o <[email protected]>
ext4: never move the system.data xattr out of the inode body

Dave Martin <[email protected]>
arm64: KVM: Tighten guest core register access from userspace

Uwe Kleine-König <[email protected]>
serial: imx: restore handshaking irq for imx1

Vincent Pelletier <[email protected]>
scsi: target: iscsi: Use bin2hex instead of a re-implementation

Bart Van Assche <[email protected]>
IB/srp: Avoid that sg_reset -d ${srp_device} triggers an infinite loop

Aaron Ma <[email protected]>
Input: elantech - enable middle button of touchpad on ThinkPad P72

Alan Stern <[email protected]>
USB: remove LPM management from usb_driver_claim_interface()

Sebastian Andrzej Siewior <[email protected]>
Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()"

Oliver Neukum <[email protected]>
USB: usbdevfs: restore warning for nonsensical flags

Oliver Neukum <[email protected]>
USB: usbdevfs: sanitize flags more

ming_qian <[email protected]>
media: uvcvideo: Support realtek's UVC 1.5 device

Alexey Dobriyan <[email protected]>
slub: make ->cpu_partial unsigned int

Alan Stern <[email protected]>
USB: handle NULL config in usb_find_alt_setting()

Alan Stern <[email protected]>
USB: fix error handling in usb_driver_claim_interface()

Geert Uytterhoeven <[email protected]>
spi: rspi: Fix interrupted DMA transfers

Geert Uytterhoeven <[email protected]>
spi: rspi: Fix invalid SPI use during system suspend

Hiromitsu Yamasaki <[email protected]>
spi: sh-msiof: Fix handling of write value for SISTR register

Gaku Inami <[email protected]>
spi: sh-msiof: Fix invalid SPI use during system suspend

Marcel Ziswiler <[email protected]>
spi: tegra20-slink: explicitly enable/disable clock

Christophe Leroy <[email protected]>
serial: cpm_uart: return immediately from console poll

Andy Whitcroft <[email protected]>
floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

Kevin Hilman <[email protected]>
ARM: dts: dra7: fix DCAN node addresses

J. Bruce Fields <[email protected]>
nfsd: fix corrupted reply to badly ordered compound

Jessica Yu <[email protected]>
module: exclude SHN_UNDEF symbols from kallsyms api

Liam Girdwood <[email protected]>
ASoC: dapm: Fix potential DAI widget pointer deref when linking DAIs

Johan Hovold <[email protected]>
EDAC, i7core: Fix memleaks and use-after-free on probe and remove

Zhouyang Jia <[email protected]>
scsi: bnx2i: add error handling for ioremap_nocache

Zhouyang Jia <[email protected]>
HID: hid-ntrig: add error handling for sysfs_create_group

Ethan Tuttle <[email protected]>
ARM: mvebu: declare asm symbols as character arrays in pmsu.c

Tony Lindgren <[email protected]>
wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()

Dan Carpenter <[email protected]>
rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()

Ben Greear <[email protected]>
ath10k: protect ath10k_htt_rx_ring_free with rx_ring.lock

Kai-Heng Feng <[email protected]>
ALSA: hda: Add AZX_DCAPS_PM_RUNTIME for AMD Raven Ridge

Zhouyang Jia <[email protected]>
media: tm6000: add error handling for dvb_register_adapter

Zhouyang Jia <[email protected]>
drivers/tty: add error handling for pcmcia_loop_config

Alistair Strachan <[email protected]>
staging: android: ashmem: Fix mmap size validation

Javier Martinez Canillas <[email protected]>
media: omap3isp: zero-initialize the isp cam_xclk{a,b} initial data

Akinobu Mita <[email protected]>
media: soc_camera: ov772x: correct setting of banding filter

Akinobu Mita <[email protected]>
media: s3c-camif: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power

Nicholas Mc Guire <[email protected]>
ALSA: snd-aoa: add of_node_put() in error path

Vasily Gorbik <[email protected]>
s390/extmem: fix gcc 8 stringop-overflow warning

Thomas Gleixner <[email protected]>
alarmtimer: Prevent overflow for relative nanosleep

Alexey Kardashevskiy <[email protected]>
powerpc/powernv/ioda2: Reduce upper limit for DMA window size

Julia Lawall <[email protected]>
usb: wusbcore: security: cast sizeof to int for comparison

Breno Leitao <[email protected]>
scsi: ibmvscsi: Improve strings handling

Bart Van Assche <[email protected]>
scsi: klist: Make it safe to use klists in atomic context

Bart Van Assche <[email protected]>
scsi: target/iscsi: Make iscsit_ta_authentication() respect the output buffer size

Jan Beulich <[email protected]>
x86/entry/64: Add two more instruction suffixes

Andy Shevchenko <[email protected]>
x86/tsc: Add missing header to tsc_msr.c

Alexey Khoroshilov <[email protected]>
media: fsl-viu: fix error handling in viu_of_probe()

Hari Bathini <[email protected]>
powerpc/kdump: Handle crashkernel memory reservation failure

Sylwester Nawrocki <[email protected]>
media: exynos4-is: Prevent NULL pointer dereference in __isp_video_try_fmt()

Guoqing Jiang <[email protected]>
md-cluster: clear another node's suspend_area after the copy is finished

Michael Scott <[email protected]>
6lowpan: iphc: reset mac_header after decompress to fix panic

Johan Hovold <[email protected]>
USB: serial: kobil_sct: fix modem-status error handling

Jian-Hong Pan <[email protected]>
Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Sudeep Holla <[email protected]>
power: vexpress: fix corruption in notifier registration

Anton Vasilyev <[email protected]>
uwb: hwa-rc: fix memory leak at probe

Colin Ian King <[email protected]>
staging: rts5208: fix missing error check on call to rtsx_write_register

Dan Williams <[email protected]>
x86/numa_emulation: Fix emulated-to-physical node mapping

Dan Carpenter <[email protected]>
vmci: type promotion bug in qp_host_get_user_memory()

Matt Ranostay <[email protected]>
tsl2550: fix lux1_input error in low light

Stafford Horne <[email protected]>
crypto: skcipher - Fix -Wstringop-truncation warnings


-------------

Diffstat:

Documentation/hwmon/ina2xx | 2 +-
Makefile | 4 +-
arch/arm/boot/dts/dra7.dtsi | 4 +-
arch/arm/mach-mvebu/pmsu.c | 6 +-
arch/arm64/include/asm/cpufeature.h | 8 ++-
arch/arm64/include/asm/jump_label.h | 4 +-
arch/arm64/include/asm/kvm_emulate.h | 5 ++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kernel/cpufeature.c | 8 +++
arch/arm64/kvm/guest.c | 55 +++++++++++++++-
arch/hexagon/include/asm/bitops.h | 4 +-
arch/hexagon/kernel/dma.c | 2 +-
arch/powerpc/kernel/machine_kexec.c | 7 ++-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
arch/s390/mm/extmem.c | 4 +-
arch/x86/entry/entry_64.S | 4 +-
arch/x86/kernel/tsc_msr.c | 1 +
arch/x86/mm/numa_emulation.c | 2 +-
crypto/ablkcipher.c | 2 +
crypto/blkcipher.c | 1 +
drivers/block/floppy.c | 3 +
drivers/bluetooth/btusb.c | 1 +
drivers/crypto/mxs-dcp.c | 53 +++++++++-------
drivers/edac/i7core_edac.c | 22 ++++---
drivers/gpio/gpio-adp5588.c | 24 +++++--
.../gpu/drm/nouveau/nvkm/subdev/devinit/gm204.c | 3 +-
drivers/hid/hid-ntrig.c | 2 +
drivers/hwmon/adt7475.c | 14 +++--
drivers/hwmon/ina2xx.c | 13 +++-
drivers/i2c/busses/i2c-i801.c | 9 ++-
drivers/i2c/busses/i2c-uniphier-f.c | 7 +--
drivers/i2c/busses/i2c-uniphier.c | 7 +--
drivers/infiniband/core/ucma.c | 6 ++
drivers/infiniband/ulp/srp/ib_srp.c | 6 +-
drivers/input/mouse/elantech.c | 2 +
drivers/md/dm-thin-metadata.c | 36 ++++++++++-
drivers/md/dm-thin.c | 73 +++++++++++++++++++---
drivers/md/md-cluster.c | 19 +++---
drivers/md/raid10.c | 5 +-
drivers/media/i2c/soc_camera/ov772x.c | 2 +-
drivers/media/platform/exynos4-is/fimc-isp-video.c | 11 +++-
drivers/media/platform/fsl-viu.c | 38 ++++++-----
drivers/media/platform/omap3isp/isp.c | 2 +-
drivers/media/platform/s3c-camif/camif-capture.c | 2 +
drivers/media/usb/tm6000/tm6000-dvb.c | 5 ++
drivers/media/usb/uvc/uvc_video.c | 24 +++++--
drivers/media/v4l2-core/v4l2-event.c | 37 +++++------
drivers/media/v4l2-core/v4l2-fh.c | 2 +
drivers/misc/tsl2550.c | 2 +-
drivers/misc/vmw_vmci/vmci_queue_pair.c | 4 +-
drivers/net/ethernet/cadence/macb.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hnae.h | 6 +-
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 7 ++-
drivers/net/ethernet/realtek/r8169.c | 9 ++-
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +-
drivers/net/wireless/mac80211_hwsim.c | 3 -
drivers/net/wireless/rndis_wlan.c | 2 +
drivers/net/wireless/ti/wlcore/cmd.c | 6 ++
drivers/pinctrl/qcom/pinctrl-msm.c | 24 +++++++
drivers/power/reset/vexpress-poweroff.c | 12 ++--
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
drivers/scsi/bnx2i/bnx2i_hwi.c | 2 +
drivers/scsi/ibmvscsi/ibmvscsi.c | 4 +-
drivers/spi/spi-rspi.c | 34 ++++++++--
drivers/spi/spi-sh-msiof.c | 28 ++++++++-
drivers/spi/spi-tegra20-slink.c | 31 ++++++---
drivers/staging/android/ashmem.c | 6 ++
drivers/staging/rts5208/sd.c | 2 +-
drivers/target/iscsi/iscsi_target_auth.c | 15 +----
drivers/target/iscsi/iscsi_target_tpg.c | 3 +-
drivers/thermal/of-thermal.c | 7 ++-
drivers/tty/serial/8250/serial_cs.c | 6 +-
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 10 ++-
drivers/tty/serial/imx.c | 8 +++
drivers/usb/class/cdc-wdm.c | 2 +-
drivers/usb/core/devio.c | 24 ++++++-
drivers/usb/core/driver.c | 28 ++++-----
drivers/usb/core/usb.c | 2 +
drivers/usb/gadget/udc/fotg210-udc.c | 15 +++--
drivers/usb/misc/yurex.c | 3 +
drivers/usb/serial/kobil_sct.c | 12 +++-
drivers/usb/wusbcore/security.c | 2 +-
drivers/uwb/hwa-rc.c | 1 +
drivers/xen/cpu_hotplug.c | 15 ++---
drivers/xen/events/events_base.c | 2 +-
drivers/xen/manage.c | 6 +-
fs/cifs/cifs_unicode.c | 3 -
fs/cifs/cifssmb.c | 11 +++-
fs/cifs/misc.c | 8 +++
fs/cifs/smb2ops.c | 2 +-
fs/ext4/xattr.c | 5 ++
fs/nfsd/nfs4proc.c | 1 +
fs/ocfs2/dlm/dlmmaster.c | 4 +-
fs/proc/base.c | 14 +++++
include/linux/platform_data/ina2xx.h | 2 +-
include/linux/slub_def.h | 3 +-
include/media/v4l2-fh.h | 1 +
kernel/module.c | 6 +-
kernel/time/alarmtimer.c | 3 +-
lib/klist.c | 10 +--
mm/madvise.c | 2 +-
mm/slub.c | 6 +-
net/6lowpan/iphc.c | 1 +
net/mac80211/ibss.c | 22 +++----
net/mac80211/main.c | 26 ++++++--
net/mac80211/mesh_hwmp.c | 4 ++
net/mac80211/mlme.c | 53 ++++++++++++++++
net/wireless/nl80211.c | 1 +
net/wireless/util.c | 2 +-
sound/aoa/core/gpio-feature.c | 4 +-
sound/pci/hda/hda_intel.c | 3 +-
sound/pci/hda/patch_realtek.c | 1 +
sound/soc/soc-dapm.c | 7 +++
tools/perf/arch/powerpc/util/sym-handling.c | 4 +-
tools/vm/page-types.c | 6 --
tools/vm/slabinfo.c | 4 +-
118 files changed, 842 insertions(+), 287 deletions(-)




2018-10-08 18:33:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 001/113] crypto: skcipher - Fix -Wstringop-truncation warnings

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stafford Horne <[email protected]>

[ Upstream commit cefd769fd0192c84d638f66da202459ed8ad63ba ]

As of GCC 9.0.0 the build is reporting warnings like:

crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’:
crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation]
strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<default>",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(rblkcipher.geniv));
~~~~~~~~~~~~~~~~~~~~~~~~~

This means the strnycpy might create a non null terminated string. Fix this by
explicitly performing '\0' termination.

Cc: Greg Kroah-Hartman <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Max Filippov <[email protected]>
Cc: Eric Biggers <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Signed-off-by: Stafford Horne <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
crypto/ablkcipher.c | 2 ++
crypto/blkcipher.c | 1 +
2 files changed, 3 insertions(+)

--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -384,6 +384,7 @@ static int crypto_ablkcipher_report(stru
strncpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<default>",
sizeof(rblkcipher.geniv));
+ rblkcipher.geniv[sizeof(rblkcipher.geniv) - 1] = '\0';

rblkcipher.blocksize = alg->cra_blocksize;
rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize;
@@ -465,6 +466,7 @@ static int crypto_givcipher_report(struc
strncpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<built-in>",
sizeof(rblkcipher.geniv));
+ rblkcipher.geniv[sizeof(rblkcipher.geniv) - 1] = '\0';

rblkcipher.blocksize = alg->cra_blocksize;
rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize;
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -515,6 +515,7 @@ static int crypto_blkcipher_report(struc
strncpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
strncpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "<default>",
sizeof(rblkcipher.geniv));
+ rblkcipher.geniv[sizeof(rblkcipher.geniv) - 1] = '\0';

rblkcipher.blocksize = alg->cra_blocksize;
rblkcipher.min_keysize = alg->cra_blkcipher.min_keysize;



2018-10-08 18:33:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 011/113] md-cluster: clear another nodes suspend_area after the copy is finished

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Guoqing Jiang <[email protected]>

[ Upstream commit 010228e4a932ca1e8365e3b58c8e1e44c16ff793 ]

When one node leaves cluster or stops the resyncing
(resync or recovery) array, then other nodes need to
call recover_bitmaps to continue the unfinished task.

But we need to clear suspend_area later after other
nodes copy the resync information to their bitmap
(by call bitmap_copy_from_slot). Otherwise, all nodes
could write to the suspend_area even the suspend_area
is not handled by any node, because area_resyncing
returns 0 at the beginning of raid1_write_request.
Which means one node could write suspend_area while
another node is resyncing the same area, then data
could be inconsistent.

So let's clear suspend_area later to avoid above issue
with the protection of bm lock. Also it is straightforward
to clear suspend_area after nodes have copied the resync
info to bitmap.

Signed-off-by: Guoqing Jiang <[email protected]>
Reviewed-by: NeilBrown <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/md-cluster.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)

--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -239,15 +239,6 @@ static void recover_bitmaps(struct md_th
while (cinfo->recovery_map) {
slot = fls64((u64)cinfo->recovery_map) - 1;

- /* Clear suspend_area associated with the bitmap */
- spin_lock_irq(&cinfo->suspend_lock);
- list_for_each_entry_safe(s, tmp, &cinfo->suspend_list, list)
- if (slot == s->slot) {
- list_del(&s->list);
- kfree(s);
- }
- spin_unlock_irq(&cinfo->suspend_lock);
-
snprintf(str, 64, "bitmap%04d", slot);
bm_lockres = lockres_init(mddev, str, NULL, 1);
if (!bm_lockres) {
@@ -266,6 +257,16 @@ static void recover_bitmaps(struct md_th
pr_err("md-cluster: Could not copy data from bitmap %d\n", slot);
goto dlm_unlock;
}
+
+ /* Clear suspend_area associated with the bitmap */
+ spin_lock_irq(&cinfo->suspend_lock);
+ list_for_each_entry_safe(s, tmp, &cinfo->suspend_list, list)
+ if (slot == s->slot) {
+ list_del(&s->list);
+ kfree(s);
+ }
+ spin_unlock_irq(&cinfo->suspend_lock);
+
if (hi > 0) {
/* TODO:Wait for current resync to get over */
set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);



2018-10-08 18:33:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 013/113] powerpc/kdump: Handle crashkernel memory reservation failure

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hari Bathini <[email protected]>

[ Upstream commit 8950329c4a64c6d3ca0bc34711a1afbd9ce05657 ]

Memory reservation for crashkernel could fail if there are holes around
kdump kernel offset (128M). Fail gracefully in such cases and print an
error message.

Signed-off-by: Hari Bathini <[email protected]>
Tested-by: David Gibson <[email protected]>
Reviewed-by: Dave Young <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kernel/machine_kexec.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -186,7 +186,12 @@ void __init reserve_crashkernel(void)
(unsigned long)(crashk_res.start >> 20),
(unsigned long)(memblock_phys_mem_size() >> 20));

- memblock_reserve(crashk_res.start, crash_size);
+ if (!memblock_is_region_memory(crashk_res.start, crash_size) ||
+ memblock_reserve(crashk_res.start, crash_size)) {
+ pr_err("Failed to reserve memory for crashkernel!\n");
+ crashk_res.start = crashk_res.end = 0;
+ return;
+ }
}

int overlaps_crashkernel(unsigned long start, unsigned long size)



2018-10-08 18:33:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 014/113] media: fsl-viu: fix error handling in viu_of_probe()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexey Khoroshilov <[email protected]>

[ Upstream commit 662a99e145661c2b35155cf375044deae9b79896 ]

viu_of_probe() ignores fails in i2c_get_adapter(),
tries to unlock uninitialized mutex on error path.

The patch streamlining the error handling in viu_of_probe().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/fsl-viu.c | 38 +++++++++++++++++++++++---------------
1 file changed, 23 insertions(+), 15 deletions(-)

--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1417,7 +1417,7 @@ static int viu_of_probe(struct platform_
sizeof(struct viu_reg), DRV_NAME)) {
dev_err(&op->dev, "Error while requesting mem region\n");
ret = -EBUSY;
- goto err;
+ goto err_irq;
}

/* remap registers */
@@ -1425,7 +1425,7 @@ static int viu_of_probe(struct platform_
if (!viu_regs) {
dev_err(&op->dev, "Can't map register set\n");
ret = -ENOMEM;
- goto err;
+ goto err_irq;
}

/* Prepare our private structure */
@@ -1433,7 +1433,7 @@ static int viu_of_probe(struct platform_
if (!viu_dev) {
dev_err(&op->dev, "Can't allocate private structure\n");
ret = -ENOMEM;
- goto err;
+ goto err_irq;
}

viu_dev->vr = viu_regs;
@@ -1449,16 +1449,21 @@ static int viu_of_probe(struct platform_
ret = v4l2_device_register(viu_dev->dev, &viu_dev->v4l2_dev);
if (ret < 0) {
dev_err(&op->dev, "v4l2_device_register() failed: %d\n", ret);
- goto err;
+ goto err_irq;
}

ad = i2c_get_adapter(0);
+ if (!ad) {
+ ret = -EFAULT;
+ dev_err(&op->dev, "couldn't get i2c adapter\n");
+ goto err_v4l2;
+ }

v4l2_ctrl_handler_init(&viu_dev->hdl, 5);
if (viu_dev->hdl.error) {
ret = viu_dev->hdl.error;
dev_err(&op->dev, "couldn't register control\n");
- goto err_vdev;
+ goto err_i2c;
}
/* This control handler will inherit the control(s) from the
sub-device(s). */
@@ -1476,7 +1481,7 @@ static int viu_of_probe(struct platform_
vdev = video_device_alloc();
if (vdev == NULL) {
ret = -ENOMEM;
- goto err_vdev;
+ goto err_hdl;
}

*vdev = viu_template;
@@ -1497,7 +1502,7 @@ static int viu_of_probe(struct platform_
ret = video_register_device(viu_dev->vdev, VFL_TYPE_GRABBER, -1);
if (ret < 0) {
video_device_release(viu_dev->vdev);
- goto err_vdev;
+ goto err_unlock;
}

/* enable VIU clock */
@@ -1505,12 +1510,12 @@ static int viu_of_probe(struct platform_
if (IS_ERR(clk)) {
dev_err(&op->dev, "failed to lookup the clock!\n");
ret = PTR_ERR(clk);
- goto err_clk;
+ goto err_vdev;
}
ret = clk_prepare_enable(clk);
if (ret) {
dev_err(&op->dev, "failed to enable the clock!\n");
- goto err_clk;
+ goto err_vdev;
}
viu_dev->clk = clk;

@@ -1521,7 +1526,7 @@ static int viu_of_probe(struct platform_
if (request_irq(viu_dev->irq, viu_intr, 0, "viu", (void *)viu_dev)) {
dev_err(&op->dev, "Request VIU IRQ failed.\n");
ret = -ENODEV;
- goto err_irq;
+ goto err_clk;
}

mutex_unlock(&viu_dev->lock);
@@ -1529,16 +1534,19 @@ static int viu_of_probe(struct platform_
dev_info(&op->dev, "Freescale VIU Video Capture Board\n");
return ret;

-err_irq:
- clk_disable_unprepare(viu_dev->clk);
err_clk:
- video_unregister_device(viu_dev->vdev);
+ clk_disable_unprepare(viu_dev->clk);
err_vdev:
- v4l2_ctrl_handler_free(&viu_dev->hdl);
+ video_unregister_device(viu_dev->vdev);
+err_unlock:
mutex_unlock(&viu_dev->lock);
+err_hdl:
+ v4l2_ctrl_handler_free(&viu_dev->hdl);
+err_i2c:
i2c_put_adapter(ad);
+err_v4l2:
v4l2_device_unregister(&viu_dev->v4l2_dev);
-err:
+err_irq:
irq_dispose_mapping(viu_irq);
return ret;
}



2018-10-08 18:33:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 015/113] x86/tsc: Add missing header to tsc_msr.c

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Shevchenko <[email protected]>

[ Upstream commit dbd0fbc76c77daac08ddd245afdcbade0d506e19 ]

Add a missing header otherwise compiler warns about missed prototype:

CC arch/x86/kernel/tsc_msr.o
arch/x86/kernel/tsc_msr.c:73:15: warning: no previous prototype for ‘cpu_khz_from_msr’ [-Wmissing-prototypes]
unsigned long cpu_khz_from_msr(void)
^~~~~~~~~~~~~~~~

Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Pavel Tatashin <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/tsc_msr.c | 1 +
1 file changed, 1 insertion(+)

--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -21,6 +21,7 @@
#include <asm/setup.h>
#include <asm/apic.h>
#include <asm/param.h>
+#include <asm/tsc.h>

/* CPU reference clock frequency: in KHz */
#define FREQ_83 83200



2018-10-08 18:33:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 016/113] x86/entry/64: Add two more instruction suffixes

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Beulich <[email protected]>

[ Upstream commit 6709812f094d96543b443645c68daaa32d3d3e77 ]

Sadly, other than claimed in:

a368d7fd2a ("x86/entry/64: Add instruction suffix")

... there are two more instances which want to be adjusted.

As said there, omitting suffixes from instructions in AT&T mode is bad
practice when operand size cannot be determined by the assembler from
register operands, and is likely going to be warned about by upstream
gas in the future (mine does already).

Add the other missing suffixes here as well.

Signed-off-by: Jan Beulich <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/entry/entry_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -90,7 +90,7 @@ ENDPROC(native_usergs_sysret64)
.endm

.macro TRACE_IRQS_IRETQ_DEBUG
- bt $9, EFLAGS(%rsp) /* interrupts off? */
+ btl $9, EFLAGS(%rsp) /* interrupts off? */
jnc 1f
TRACE_IRQS_ON_DEBUG
1:
@@ -620,7 +620,7 @@ retint_kernel:
#ifdef CONFIG_PREEMPT
/* Interrupts are off */
/* Check if we need preemption */
- bt $9, EFLAGS(%rsp) /* were interrupts off? */
+ btl $9, EFLAGS(%rsp) /* were interrupts off? */
jnc 1f
0: cmpl $0, PER_CPU_VAR(__preempt_count)
jnz 1f



2018-10-08 18:33:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 017/113] scsi: target/iscsi: Make iscsit_ta_authentication() respect the output buffer size

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

[ Upstream commit 35bea5c84fd13c643cce63f0b5cd4b148f8c901d ]

Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")
Signed-off-by: Bart Van Assche <[email protected]>
Reviewed-by: Mike Christie <[email protected]>
Cc: Mike Christie <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/iscsi/iscsi_target_tpg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/target/iscsi/iscsi_target_tpg.c
+++ b/drivers/target/iscsi/iscsi_target_tpg.c
@@ -637,8 +637,7 @@ int iscsit_ta_authentication(struct iscs
none = strstr(buf1, NONE);
if (none)
goto out;
- strncat(buf1, ",", strlen(","));
- strncat(buf1, NONE, strlen(NONE));
+ strlcat(buf1, "," NONE, sizeof(buf1));
if (iscsi_update_param_value(param, buf1) < 0)
return -EINVAL;
}



2018-10-08 18:33:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 018/113] scsi: klist: Make it safe to use klists in atomic context

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

[ Upstream commit 624fa7790f80575a4ec28fbdb2034097dc18d051 ]

In the scsi_transport_srp implementation it cannot be avoided to
iterate over a klist from atomic context when using the legacy block
layer instead of blk-mq. Hence this patch that makes it safe to use
klists in atomic context. This patch avoids that lockdep reports the
following:

WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
Possible interrupt unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&(&k->k_lock)->rlock);
local_irq_disable();
lock(&(&q->__queue_lock)->rlock);
lock(&(&k->k_lock)->rlock);
<Interrupt>
lock(&(&q->__queue_lock)->rlock);

stack backtrace:
Workqueue: kblockd blk_timeout_work
Call Trace:
dump_stack+0xa4/0xf5
check_usage+0x6e6/0x700
__lock_acquire+0x185d/0x1b50
lock_acquire+0xd2/0x260
_raw_spin_lock+0x32/0x50
klist_next+0x47/0x190
device_for_each_child+0x8e/0x100
srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
scsi_times_out+0xd4/0x410 [scsi_mod]
blk_rq_timed_out+0x36/0x70
blk_timeout_work+0x1b5/0x220
process_one_work+0x4fe/0xad0
worker_thread+0x63/0x5a0
kthread+0x1c1/0x1e0
ret_from_fork+0x24/0x30

See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost to
rport translation").

Signed-off-by: Bart Van Assche <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: James Bottomley <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/klist.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

--- a/lib/klist.c
+++ b/lib/klist.c
@@ -336,8 +336,9 @@ struct klist_node *klist_prev(struct kli
void (*put)(struct klist_node *) = i->i_klist->put;
struct klist_node *last = i->i_cur;
struct klist_node *prev;
+ unsigned long flags;

- spin_lock(&i->i_klist->k_lock);
+ spin_lock_irqsave(&i->i_klist->k_lock, flags);

if (last) {
prev = to_klist_node(last->n_node.prev);
@@ -356,7 +357,7 @@ struct klist_node *klist_prev(struct kli
prev = to_klist_node(prev->n_node.prev);
}

- spin_unlock(&i->i_klist->k_lock);
+ spin_unlock_irqrestore(&i->i_klist->k_lock, flags);

if (put && last)
put(last);
@@ -377,8 +378,9 @@ struct klist_node *klist_next(struct kli
void (*put)(struct klist_node *) = i->i_klist->put;
struct klist_node *last = i->i_cur;
struct klist_node *next;
+ unsigned long flags;

- spin_lock(&i->i_klist->k_lock);
+ spin_lock_irqsave(&i->i_klist->k_lock, flags);

if (last) {
next = to_klist_node(last->n_node.next);
@@ -397,7 +399,7 @@ struct klist_node *klist_next(struct kli
next = to_klist_node(next->n_node.next);
}

- spin_unlock(&i->i_klist->k_lock);
+ spin_unlock_irqrestore(&i->i_klist->k_lock, flags);

if (put && last)
put(last);



2018-10-08 18:33:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 019/113] scsi: ibmvscsi: Improve strings handling

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Breno Leitao <[email protected]>

[ Upstream commit 1262dc09dc9ae7bf4ad00b6a2c5ed6a6936bcd10 ]

Currently an open firmware property is copied into partition_name variable
without keeping a room for \0.

Later one, this variable (partition_name), which is 97 bytes long, is
strncpyed into ibmvcsci_host_data->madapter_info->partition_name, which is
96 bytes long, possibly truncating it 'again' and removing the \0.

This patch simply decreases the partition name to 96 and just copy using
strlcpy() which guarantees that the string is \0 terminated. I think there
is no issue if this there is a truncation in this very first copy, i.e,
when the open firmware property is read and copied into the driver for the
very first time;

This issue also causes the following warning on GCC 8:

drivers/scsi/ibmvscsi/ibmvscsi.c:281:2: warning: strncpy output may be truncated copying 96 bytes from a string of length 96 [-Wstringop-truncation]
...
inlined from ibmvscsi_probe at drivers/scsi/ibmvscsi/ibmvscsi.c:2221:7:
drivers/scsi/ibmvscsi/ibmvscsi.c:265:3: warning: strncpy specified bound 97 equals destination size [-Wstringop-truncation]

CC: Bart Van Assche <[email protected]>
CC: Tyrel Datwyler <[email protected]>
Signed-off-by: Breno Leitao <[email protected]>
Acked-by: Tyrel Datwyler <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -93,7 +93,7 @@ static int max_requests = IBMVSCSI_MAX_R
static int max_events = IBMVSCSI_MAX_REQUESTS_DEFAULT + 2;
static int fast_fail = 1;
static int client_reserve = 1;
-static char partition_name[97] = "UNKNOWN";
+static char partition_name[96] = "UNKNOWN";
static unsigned int partition_number = -1;

static struct scsi_transport_template *ibmvscsi_transport_template;
@@ -261,7 +261,7 @@ static void gather_partition_info(void)

ppartition_name = of_get_property(rootdn, "ibm,partition-name", NULL);
if (ppartition_name)
- strncpy(partition_name, ppartition_name,
+ strlcpy(partition_name, ppartition_name,
sizeof(partition_name));
p_number_ptr = of_get_property(rootdn, "ibm,partition-no", NULL);
if (p_number_ptr)



2018-10-08 18:33:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 002/113] tsl2550: fix lux1_input error in low light

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matt Ranostay <[email protected]>

[ Upstream commit ce054546cc2c26891cefa2f284d90d93b52205de ]

ADC channel 0 photodiode detects both infrared + visible light,
but ADC channel 1 just detects infrared. However, the latter is a bit
more sensitive in that range so complete darkness or low light causes
a error condition in which the chan0 - chan1 is negative that
results in a -EAGAIN.

This patch changes the resulting lux1_input sysfs attribute message from
"Resource temporarily unavailable" to a user-grokable lux value of 0.

Cc: Arnd Bergmann <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Matt Ranostay <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/tsl2550.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/misc/tsl2550.c
+++ b/drivers/misc/tsl2550.c
@@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0,
} else
lux = 0;
else
- return -EAGAIN;
+ return 0;

/* LUX range check */
return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;



2018-10-08 18:34:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 003/113] vmci: type promotion bug in qp_host_get_user_memory()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 7fb2fd4e25fc1fb10dcb30b5519de257cfeae84c ]

The problem is that if get_user_pages_fast() fails and returns a
negative error code, it gets type promoted to a high positive value and
treated as a success.

Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -755,7 +755,7 @@ static int qp_host_get_user_memory(u64 p
retval = get_user_pages_fast((uintptr_t) produce_uva,
produce_q->kernel_if->num_pages, 1,
produce_q->kernel_if->u.h.header_page);
- if (retval < produce_q->kernel_if->num_pages) {
+ if (retval < (int)produce_q->kernel_if->num_pages) {
pr_debug("get_user_pages_fast(produce) failed (retval=%d)",
retval);
qp_release_pages(produce_q->kernel_if->u.h.header_page,
@@ -767,7 +767,7 @@ static int qp_host_get_user_memory(u64 p
retval = get_user_pages_fast((uintptr_t) consume_uva,
consume_q->kernel_if->num_pages, 1,
consume_q->kernel_if->u.h.header_page);
- if (retval < consume_q->kernel_if->num_pages) {
+ if (retval < (int)consume_q->kernel_if->num_pages) {
pr_debug("get_user_pages_fast(consume) failed (retval=%d)",
retval);
qp_release_pages(consume_q->kernel_if->u.h.header_page,



2018-10-08 18:34:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 004/113] x86/numa_emulation: Fix emulated-to-physical node mapping

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Williams <[email protected]>

[ Upstream commit 3b6c62f363a19ce82bf378187ab97c9dc01e3927 ]

Without this change the distance table calculation for emulated nodes
may use the wrong numa node and report an incorrect distance.

Signed-off-by: Dan Williams <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Wei Yang <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/153089328103.27680.14778434392225818887.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/mm/numa_emulation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -60,7 +60,7 @@ static int __init emu_setup_memblk(struc
eb->nid = nid;

if (emu_nid_to_phys[nid] == NUMA_NO_NODE)
- emu_nid_to_phys[nid] = nid;
+ emu_nid_to_phys[nid] = pb->nid;

pb->start += size;
if (pb->start >= pb->end) {



2018-10-08 18:34:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 005/113] staging: rts5208: fix missing error check on call to rtsx_write_register

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Colin Ian King <[email protected]>

[ Upstream commit c5fae4f4fd28189b1062fb8ef7b21fec37cb8b17 ]

Currently the check on error return from the call to rtsx_write_register
is checking the error status from the previous call. Fix this by adding
in the missing assignment of retval.

Detected by CoverityScan, CID#709877

Fixes: fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288")
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rts5208/sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -5031,7 +5031,7 @@ int sd_execute_write_data(struct scsi_cm
goto SD_Execute_Write_Cmd_Failed;
}

- rtsx_write_register(chip, SD_BYTE_CNT_L, 0xFF, 0x00);
+ retval = rtsx_write_register(chip, SD_BYTE_CNT_L, 0xFF, 0x00);
if (retval != STATUS_SUCCESS) {
rtsx_trace(chip);
goto SD_Execute_Write_Cmd_Failed;



2018-10-08 18:34:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 006/113] uwb: hwa-rc: fix memory leak at probe

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anton Vasilyev <[email protected]>

[ Upstream commit 11b71782c1d10d9bccc31825cf84291cd7588a1e ]

hwarc_probe() allocates memory for hwarc, but does not free it
if uwb_rc_add() or hwarc_get_version() fail.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/uwb/hwa-rc.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/uwb/hwa-rc.c
+++ b/drivers/uwb/hwa-rc.c
@@ -875,6 +875,7 @@ error_get_version:
error_rc_add:
usb_put_intf(iface);
usb_put_dev(hwarc->usb_dev);
+ kfree(hwarc);
error_alloc:
uwb_rc_put(uwb_rc);
error_rc_alloc:



2018-10-08 18:34:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 010/113] 6lowpan: iphc: reset mac_header after decompress to fix panic

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michael Scott <[email protected]>

[ Upstream commit 03bc05e1a4972f73b4eb8907aa373369e825c252 ]

After decompression of 6lowpan socket data, an IPv6 header is inserted
before the existing socket payload. After this, we reset the
network_header value of the skb to account for the difference in payload
size from prior to decompression + the addition of the IPv6 header.

However, we fail to reset the mac_header value.

Leaving the mac_header value untouched here, can cause a calculation
error in net/packet/af_packet.c packet_rcv() function when an
AF_PACKET socket is opened in SOCK_RAW mode for use on a 6lowpan
interface.

On line 2088, the data pointer is moved backward by the value returned
from skb_mac_header(). If skb->data is adjusted so that it is before
the skb->head pointer (which can happen when an old value of mac_header
is left in place) the kernel generates a panic in net/core/skbuff.c
line 1717.

This panic can be generated by BLE 6lowpan interfaces (such as bt0) and
802.15.4 interfaces (such as lowpan0) as they both use the same 6lowpan
sources for compression and decompression.

Signed-off-by: Michael Scott <[email protected]>
Acked-by: Alexander Aring <[email protected]>
Acked-by: Jukka Rissanen <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/6lowpan/iphc.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -569,6 +569,7 @@ int lowpan_header_decompress(struct sk_b
hdr.hop_limit, &hdr.daddr);

skb_push(skb, sizeof(hdr));
+ skb_reset_mac_header(skb);
skb_reset_network_header(skb);
skb_copy_to_linear_data(skb, &hdr, sizeof(hdr));




2018-10-08 18:34:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 007/113] power: vexpress: fix corruption in notifier registration

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sudeep Holla <[email protected]>

[ Upstream commit 09bebb1adb21ecd04adf7ccb3b06f73e3a851e93 ]

Vexpress platforms provide two different restart handlers: SYS_REBOOT
that restart the entire system, while DB_RESET only restarts the
daughter board containing the CPU. DB_RESET is overridden by SYS_REBOOT
if it exists.

notifier_chain_register used in register_restart_handler by design
relies on notifiers to be registered once only, however vexpress restart
notifier can get registered twice. When this happen it corrupts list
of notifiers, as result some notifiers can be not called on proper
event, traverse on list can be cycled forever, and second unregister
can access already freed memory.

So far, since this was the only restart handler in the system, no issue
was observed even if the same notifier was registered twice. However
commit 6c5c0d48b686 ("watchdog: sp805: add restart handler") added
support for SP805 restart handlers and since the system under test
contains two vexpress restart and two SP805 watchdog instances, it was
observed that during the boot traversing the restart handler list looped
forever as there's a cycle in that list resulting in boot hang.

This patch fixes the issues by ensuring that the notifier is installed
only once.

Cc: Sebastian Reichel <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
Fixes: 46c99ac66222 ("power/reset: vexpress: Register with kernel restart handler")
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/power/reset/vexpress-poweroff.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -35,6 +35,7 @@ static void vexpress_reset_do(struct dev
}

static struct device *vexpress_power_off_device;
+static atomic_t vexpress_restart_nb_refcnt = ATOMIC_INIT(0);

static void vexpress_power_off(void)
{
@@ -99,10 +100,13 @@ static int _vexpress_register_restart_ha
int err;

vexpress_restart_device = dev;
- err = register_restart_handler(&vexpress_restart_nb);
- if (err) {
- dev_err(dev, "cannot register restart handler (err=%d)\n", err);
- return err;
+ if (atomic_inc_return(&vexpress_restart_nb_refcnt) == 1) {
+ err = register_restart_handler(&vexpress_restart_nb);
+ if (err) {
+ dev_err(dev, "cannot register restart handler (err=%d)\n", err);
+ atomic_dec(&vexpress_restart_nb_refcnt);
+ return err;
+ }
}
device_create_file(dev, &dev_attr_active);




2018-10-08 18:34:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 008/113] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jian-Hong Pan <[email protected]>

[ Upstream commit 45ae68b8cfc25bdbffc11248001c47ab1b76ff6e ]

Without this patch we cannot turn on the Bluethooth adapter on HP
14-bs007la.

T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=b009 Rev= 2.00
S: Manufacturer=Realtek
S: Product=802.11n WLAN Adapter
S: SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms

Signed-off-by: Jian-Hong Pan <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/bluetooth/btusb.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -340,6 +340,7 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x7392, 0xa611), .driver_info = BTUSB_REALTEK },

/* Additional Realtek 8723DE Bluetooth devices */
+ { USB_DEVICE(0x0bda, 0xb009), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x2ff8, 0xb011), .driver_info = BTUSB_REALTEK },

/* Additional Realtek 8821AE Bluetooth devices */



2018-10-08 18:34:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 022/113] alarmtimer: Prevent overflow for relative nanosleep

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

[ Upstream commit 5f936e19cc0ef97dbe3a56e9498922ad5ba1edef ]

Air Icy reported:

UBSAN: Undefined behaviour in kernel/time/alarmtimer.c:811:7
signed integer overflow:
1529859276030040771 + 9223372036854775807 cannot be represented in type 'long long int'
Call Trace:
alarm_timer_nsleep+0x44c/0x510 kernel/time/alarmtimer.c:811
__do_sys_clock_nanosleep kernel/time/posix-timers.c:1235 [inline]
__se_sys_clock_nanosleep kernel/time/posix-timers.c:1213 [inline]
__x64_sys_clock_nanosleep+0x326/0x4e0 kernel/time/posix-timers.c:1213
do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290

alarm_timer_nsleep() uses ktime_add() to add the current time and the
relative expiry value. ktime_add() has no sanity checks so the addition
can overflow when the relative timeout is large enough.

Use ktime_add_safe() which has the necessary sanity checks in place and
limits the result to the valid range.

Fixes: 9a7adcf5c6de ("timers: Posix interface for alarm-timers")
Reported-by: Team OWL337 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: John Stultz <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/time/alarmtimer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -773,7 +773,8 @@ static int alarm_timer_nsleep(const cloc
/* Convert (if necessary) to absolute time */
if (flags != TIMER_ABSTIME) {
ktime_t now = alarm_bases[type].gettime();
- exp = ktime_add(now, exp);
+
+ exp = ktime_add_safe(now, exp);
}

if (alarmtimer_do_nsleep(&alarm, exp))



2018-10-08 18:34:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 033/113] rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit ae636fb1554833ee5133ca47bf4b2791b6739c52 ]

This is a static checker fix, not something I have tested. The issue
is that on the second iteration through the loop, we jump forward by
le32_to_cpu(auth_req->length) bytes. The problem is that if the length
is more than "buflen" then we end up with a negative "buflen". A
negative buflen is type promoted to a high positive value and the loop
continues but it's accessing beyond the end of the buffer.

I believe the "auth_req->length" comes from the firmware and if the
firmware is malicious or buggy, you're already toasted so the impact of
this bug is probably not very severe.

Fixes: 030645aceb3d ("rndis_wlan: handle 802.11 indications from device")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/rndis_wlan.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -2919,6 +2919,8 @@ static void rndis_wlan_auth_indication(s

while (buflen >= sizeof(*auth_req)) {
auth_req = (void *)buf;
+ if (buflen < le32_to_cpu(auth_req->length))
+ return;
type = "unknown";
flags = le32_to_cpu(auth_req->flags);
pairwise_error = false;



2018-10-08 18:34:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 035/113] ARM: mvebu: declare asm symbols as character arrays in pmsu.c

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ethan Tuttle <[email protected]>

[ Upstream commit d0d378ff451a66e486488eec842e507d28145813 ]

With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to
detect buffer overflows. If src or dest is declared as a char, attempts to
copy more than byte will result in a fortify_panic().

Address this problem in mvebu_setup_boot_addr_wa() by declaring
mvebu_boot_wa_start and mvebu_boot_wa_end as character arrays. Also remove
a couple addressof operators to avoid "arithmetic on pointer to an
incomplete type" compiler error.

See commit 54a7d50b9205 ("x86: mark kprobe templates as character arrays,
not single characters") for a similar fix.

Fixes "detected buffer overflow in memcpy" error during init on some mvebu
systems (armada-370-xp, armada-375):

(fortify_panic) from (mvebu_setup_boot_addr_wa+0xb0/0xb4)
(mvebu_setup_boot_addr_wa) from (mvebu_v7_cpu_pm_init+0x154/0x204)
(mvebu_v7_cpu_pm_init) from (do_one_initcall+0x7c/0x1a8)
(do_one_initcall) from (kernel_init_freeable+0x1bc/0x254)
(kernel_init_freeable) from (kernel_init+0x8/0x114)
(kernel_init) from (ret_from_fork+0x14/0x2c)

Signed-off-by: Ethan Tuttle <[email protected]>
Tested-by: Ethan Tuttle <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-mvebu/pmsu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -117,8 +117,8 @@ void mvebu_pmsu_set_cpu_boot_addr(int hw
PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
}

-extern unsigned char mvebu_boot_wa_start;
-extern unsigned char mvebu_boot_wa_end;
+extern unsigned char mvebu_boot_wa_start[];
+extern unsigned char mvebu_boot_wa_end[];

/*
* This function sets up the boot address workaround needed for SMP
@@ -131,7 +131,7 @@ int mvebu_setup_boot_addr_wa(unsigned in
phys_addr_t resume_addr_reg)
{
void __iomem *sram_virt_base;
- u32 code_len = &mvebu_boot_wa_end - &mvebu_boot_wa_start;
+ u32 code_len = mvebu_boot_wa_end - mvebu_boot_wa_start;

mvebu_mbus_del_window(BOOTROM_BASE, BOOTROM_SIZE);
mvebu_mbus_add_window_by_id(crypto_eng_target, crypto_eng_attribute,



2018-10-08 18:35:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 037/113] scsi: bnx2i: add error handling for ioremap_nocache

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhouyang Jia <[email protected]>

[ Upstream commit aa154ea885eb0c2407457ce9c1538d78c95456fa ]

When ioremap_nocache fails, the lack of error-handling code may cause
unexpected results.

This patch adds error-handling code after calling ioremap_nocache.

Signed-off-by: Zhouyang Jia <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Acked-by: Manish Rangankar <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/bnx2i/bnx2i_hwi.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/scsi/bnx2i/bnx2i_hwi.c
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -2742,6 +2742,8 @@ int bnx2i_map_ep_dbell_regs(struct bnx2i
BNX2X_DOORBELL_PCI_BAR);
reg_off = (1 << BNX2X_DB_SHIFT) * (cid_num & 0x1FFFF);
ep->qp.ctx_base = ioremap_nocache(reg_base + reg_off, 4);
+ if (!ep->qp.ctx_base)
+ return -ENOMEM;
goto arm_cq;
}




2018-10-08 18:35:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 039/113] ASoC: dapm: Fix potential DAI widget pointer deref when linking DAIs

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Liam Girdwood <[email protected]>

[ Upstream commit e01b4f624278d5efe5fb5da585ca371947b16680 ]

Sometime a component or topology may configure a DAI widget with no
private data leading to a dev_dbg() dereferencne of this data.

Fix this to check for non NULL private data and let users know if widget
is missing DAI.

Signed-off-by: Liam Girdwood <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/soc-dapm.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3864,6 +3864,13 @@ int snd_soc_dapm_link_dai_widgets(struct
continue;
}

+ /* let users know there is no DAI to link */
+ if (!dai_w->priv) {
+ dev_dbg(card->dev, "dai widget %s has no DAI\n",
+ dai_w->name);
+ continue;
+ }
+
dai = dai_w->priv;

/* ...find all widgets with the same stream and link them */



2018-10-08 18:35:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 040/113] module: exclude SHN_UNDEF symbols from kallsyms api

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jessica Yu <[email protected]>

[ Upstream commit 9f2d1e68cf4d641def734adaccfc3823d3575e6c ]

Livepatch modules are special in that we preserve their entire symbol
tables in order to be able to apply relocations after module load. The
unwanted side effect of this is that undefined (SHN_UNDEF) symbols of
livepatch modules are accessible via the kallsyms api and this can
confuse symbol resolution in livepatch (klp_find_object_symbol()) and
cause subtle bugs in livepatch.

Have the module kallsyms api skip over SHN_UNDEF symbols. These symbols
are usually not available for normal modules anyway as we cut down their
symbol tables to just the core (non-undefined) symbols, so this should
really just affect livepatch modules. Note that this patch doesn't
affect the display of undefined symbols in /proc/kallsyms.

Reported-by: Josh Poimboeuf <[email protected]>
Tested-by: Josh Poimboeuf <[email protected]>
Reviewed-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Jessica Yu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/module.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3860,7 +3860,7 @@ static unsigned long mod_find_symname(st

for (i = 0; i < kallsyms->num_symtab; i++)
if (strcmp(name, symname(kallsyms, i)) == 0 &&
- kallsyms->symtab[i].st_info != 'U')
+ kallsyms->symtab[i].st_shndx != SHN_UNDEF)
return kallsyms->symtab[i].st_value;
return 0;
}
@@ -3906,6 +3906,10 @@ int module_kallsyms_on_each_symbol(int (
if (mod->state == MODULE_STATE_UNFORMED)
continue;
for (i = 0; i < kallsyms->num_symtab; i++) {
+
+ if (kallsyms->symtab[i].st_shndx == SHN_UNDEF)
+ continue;
+
ret = fn(data, symname(kallsyms, i),
mod, kallsyms->symtab[i].st_value);
if (ret != 0)



2018-10-08 18:35:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 034/113] wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tony Lindgren <[email protected]>

[ Upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1 ]

Otherwise we can get:

WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84

I've only seen this few times with the runtime PM patches enabled
so this one is probably not needed before that. This seems to
work currently based on the current PM implementation timer. Let's
apply this separately though in case others are hitting this issue.

Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ti/wlcore/cmd.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -35,6 +35,7 @@
#include "wl12xx_80211.h"
#include "cmd.h"
#include "event.h"
+#include "ps.h"
#include "tx.h"
#include "hw_ops.h"

@@ -191,6 +192,10 @@ int wlcore_cmd_wait_for_event_or_timeout

timeout_time = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT);

+ ret = wl1271_ps_elp_wakeup(wl);
+ if (ret < 0)
+ return ret;
+
do {
if (time_after(jiffies, timeout_time)) {
wl1271_debug(DEBUG_CMD, "timeout waiting for event %d",
@@ -222,6 +227,7 @@ int wlcore_cmd_wait_for_event_or_timeout
} while (!event);

out:
+ wl1271_ps_elp_sleep(wl);
kfree(events_vector);
return ret;
}



2018-10-08 18:35:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 041/113] nfsd: fix corrupted reply to badly ordered compound

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: "J. Bruce Fields" <[email protected]>

[ Upstream commit 5b7b15aee641904ae269be9846610a3950cbd64c ]

We're encoding a single op in the reply but leaving the number of ops
zero, so the reply makes no sense.

Somewhat academic as this isn't a case any real client will hit, though
in theory perhaps that could change in a future protocol extension.

Reviewed-by: Jeff Layton <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/nfs4proc.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1632,6 +1632,7 @@ nfsd4_proc_compound(struct svc_rqst *rqs
if (status) {
op = &args->ops[0];
op->status = status;
+ resp->opcnt = 1;
goto encode_op;
}




2018-10-08 18:35:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 043/113] floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Whitcroft <[email protected]>

commit 65eea8edc315589d6c993cf12dbb5d0e9ef1fe4e upstream.

The final field of a floppy_struct is the field "name", which is a pointer
to a string in kernel memory. The kernel pointer should not be copied to
user memory. The FDGETPRM ioctl copies a floppy_struct to user memory,
including this "name" field. This pointer cannot be used by the user
and it will leak a kernel address to user-space, which will reveal the
location of kernel code and data and undermine KASLR protection.

Model this code after the compat ioctl which copies the returned data
to a previously cleared temporary structure on the stack (excluding the
name pointer) and copy out to userspace from there. As we already have
an inparam union with an appropriate member and that memory is already
cleared even for read only calls make use of that as a temporary store.

Based on an initial patch by Brian Belleville.

CVE-2018-7755
Signed-off-by: Andy Whitcroft <[email protected]>
Broke up long line.
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/block/floppy.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3459,6 +3459,9 @@ static int fd_locked_ioctl(struct block_
(struct floppy_struct **)&outparam);
if (ret)
return ret;
+ memcpy(&inparam.g, outparam,
+ offsetof(struct floppy_struct, name));
+ outparam = &inparam.g;
break;
case FDMSGON:
UDP->flags |= FTD_MSG;



2018-10-08 18:35:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 042/113] ARM: dts: dra7: fix DCAN node addresses

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kevin Hilman <[email protected]>

[ Upstream commit 949bdcc8a97c6078f21c8d4966436b117f2e4cd3 ]

Fix the DT node addresses to match the reg property addresses,
which were verified to match the TRM:
http://www.ti.com/lit/pdf/sprui30

Cc: Roger Quadros <[email protected]>
Signed-off-by: Kevin Hilman <[email protected]>
Acked-by: Roger Quadros <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1549,7 +1549,7 @@
};
};

- dcan1: can@481cc000 {
+ dcan1: can@4ae3c000 {
compatible = "ti,dra7-d_can";
ti,hwmods = "dcan1";
reg = <0x4ae3c000 0x2000>;
@@ -1559,7 +1559,7 @@
status = "disabled";
};

- dcan2: can@481d0000 {
+ dcan2: can@48480000 {
compatible = "ti,dra7-d_can";
ti,hwmods = "dcan2";
reg = <0x48480000 0x2000>;



2018-10-08 18:35:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 044/113] serial: cpm_uart: return immediately from console poll

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christophe Leroy <[email protected]>

commit be28c1e3ca29887e207f0cbcd294cefe5074bab6 upstream.

kgdb expects poll function to return immediately and
returning NO_POLL_CHAR when no character is available.

Fixes: f5316b4aea024 ("kgdb,8250,pl011: Return immediately from console poll")
Cc: Jason Wessel <[email protected]>
Cc: <[email protected]>
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1068,8 +1068,8 @@ static int poll_wait_key(char *obuf, str
/* Get the address of the host memory buffer.
*/
bdp = pinfo->rx_cur;
- while (bdp->cbd_sc & BD_SC_EMPTY)
- ;
+ if (bdp->cbd_sc & BD_SC_EMPTY)
+ return NO_POLL_CHAR;

/* If the buffer address is in the CPM DPRAM, don't
* convert it.
@@ -1104,7 +1104,11 @@ static int cpm_get_poll_char(struct uart
poll_chars = 0;
}
if (poll_chars <= 0) {
- poll_chars = poll_wait_key(poll_buf, pinfo);
+ int ret = poll_wait_key(poll_buf, pinfo);
+
+ if (ret == NO_POLL_CHAR)
+ return ret;
+ poll_chars = ret;
pollp = poll_buf;
}
poll_chars--;



2018-10-08 18:35:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 046/113] spi: sh-msiof: Fix invalid SPI use during system suspend

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gaku Inami <[email protected]>

commit ffa69d6a16f686efe45269342474e421f2aa58b2 upstream.

If the SPI queue is running during system suspend, the system may lock
up.

Fix this by stopping/restarting the queue during system suspend/resume
by calling spi_master_suspend()/spi_master_resume() from the PM
callbacks. In-kernel users will receive an -ESHUTDOWN error while
system suspend/resume is in progress.

Signed-off-by: Gaku Inami <[email protected]>
Signed-off-by: Hiromitsu Yamasaki <[email protected]>
[geert: Cleanup, reword]
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-sh-msiof.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)

--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -1275,12 +1275,37 @@ static const struct platform_device_id s
};
MODULE_DEVICE_TABLE(platform, spi_driver_ids);

+#ifdef CONFIG_PM_SLEEP
+static int sh_msiof_spi_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sh_msiof_spi_priv *p = platform_get_drvdata(pdev);
+
+ return spi_master_suspend(p->master);
+}
+
+static int sh_msiof_spi_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sh_msiof_spi_priv *p = platform_get_drvdata(pdev);
+
+ return spi_master_resume(p->master);
+}
+
+static SIMPLE_DEV_PM_OPS(sh_msiof_spi_pm_ops, sh_msiof_spi_suspend,
+ sh_msiof_spi_resume);
+#define DEV_PM_OPS &sh_msiof_spi_pm_ops
+#else
+#define DEV_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
static struct platform_driver sh_msiof_spi_drv = {
.probe = sh_msiof_spi_probe,
.remove = sh_msiof_spi_remove,
.id_table = spi_driver_ids,
.driver = {
.name = "spi_sh_msiof",
+ .pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(sh_msiof_match),
},
};



2018-10-08 18:35:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 024/113] ALSA: snd-aoa: add of_node_put() in error path

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 222bce5eb88d1af656419db04bcd84b2419fb900 ]

Both calls to of_find_node_by_name() and of_get_next_child() return a
node pointer with refcount incremented thus it must be explicidly
decremented here after the last usage. As we are assured to have a
refcounted np either from the initial
of_find_node_by_name(NULL, name); or from the of_get_next_child(gpio, np)
in the while loop if we reached the error code path below, an
x of_node_put(np) is needed.

Signed-off-by: Nicholas Mc Guire <[email protected]>
Fixes: commit f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/aoa/core/gpio-feature.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/sound/aoa/core/gpio-feature.c
+++ b/sound/aoa/core/gpio-feature.c
@@ -88,8 +88,10 @@ static struct device_node *get_gpio(char
}

reg = of_get_property(np, "reg", NULL);
- if (!reg)
+ if (!reg) {
+ of_node_put(np);
return NULL;
+ }

*gpioptr = *reg;




2018-10-08 18:35:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 009/113] USB: serial: kobil_sct: fix modem-status error handling

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

[ Upstream commit a420b5d939ee58f1d950f0ea782834056520aeaa ]

Make sure to return -EIO in case of a short modem-status read request.

While at it, split the debug message to not include the (zeroed)
transfer-buffer content in case of errors.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/kobil_sct.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/drivers/usb/serial/kobil_sct.c
+++ b/drivers/usb/serial/kobil_sct.c
@@ -408,12 +408,20 @@ static int kobil_tiocmget(struct tty_str
transfer_buffer_length,
KOBIL_TIMEOUT);

- dev_dbg(&port->dev, "%s - Send get_status_line_state URB returns: %i. Statusline: %02x\n",
- __func__, result, transfer_buffer[0]);
+ dev_dbg(&port->dev, "Send get_status_line_state URB returns: %i\n",
+ result);
+ if (result < 1) {
+ if (result >= 0)
+ result = -EIO;
+ goto out_free;
+ }
+
+ dev_dbg(&port->dev, "Statusline: %02x\n", transfer_buffer[0]);

result = 0;
if ((transfer_buffer[0] & SUSBCR_GSL_DSR) != 0)
result = TIOCM_DSR;
+out_free:
kfree(transfer_buffer);
return result;
}



2018-10-08 18:35:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 025/113] media: s3c-camif: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Akinobu Mita <[email protected]>

[ Upstream commit 30ed2b83343bd1e07884ca7355dac70d25ffc158 ]

When the subdevice doesn't provide s_power core ops callback, the
v4l2_subdev_call for s_power returns -ENOIOCTLCMD. If the subdevice
doesn't have the special handling for its power saving mode, the s_power
isn't required. So -ENOIOCTLCMD from the v4l2_subdev_call should be
ignored.

Cc: Hans Verkuil <[email protected]>
Signed-off-by: Akinobu Mita <[email protected]>
Acked-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/s3c-camif/camif-capture.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -117,6 +117,8 @@ static int sensor_set_power(struct camif

if (camif->sensor.power_count == !on)
err = v4l2_subdev_call(sensor->sd, core, s_power, on);
+ if (err == -ENOIOCTLCMD)
+ err = 0;
if (!err)
sensor->power_count += on ? 1 : -1;




2018-10-08 18:35:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 026/113] media: soc_camera: ov772x: correct setting of banding filter

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Akinobu Mita <[email protected]>

[ Upstream commit 22216ec41e919682c15345e95928f266e8ba6f9e ]

The banding filter ON/OFF is controlled via bit 5 of COM8 register. It
is attempted to be enabled in ov772x_set_params() by the following line.

ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);

But this unexpectedly results disabling the banding filter, because the
mask and set bits are exclusive.

On the other hand, ov772x_s_ctrl() correctly sets the bit by:

ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF);

The same fix was already applied to non-soc_camera version of ov772x
driver in the commit commit a024ee14cd36 ("media: ov772x: correct setting
of banding filter")

Cc: Jacopo Mondi <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Hans Verkuil <[email protected]>
Signed-off-by: Akinobu Mita <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/i2c/soc_camera/ov772x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/i2c/soc_camera/ov772x.c
+++ b/drivers/media/i2c/soc_camera/ov772x.c
@@ -834,7 +834,7 @@ static int ov772x_set_params(struct ov77
* set COM8
*/
if (priv->band_filter) {
- ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);
+ ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF);
if (!ret)
ret = ov772x_mask_set(client, BDBASE,
0xff, 256 - priv->band_filter);



2018-10-08 18:35:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 045/113] spi: tegra20-slink: explicitly enable/disable clock

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marcel Ziswiler <[email protected]>

commit 7001cab1dabc0b72b2b672ef58a90ab64f5e2343 upstream.

Depending on the SPI instance one may get an interrupt storm upon
requesting resp. interrupt unless the clock is explicitly enabled
beforehand. This has been observed trying to bring up instance 4 on
T20.

Signed-off-by: Marcel Ziswiler <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-tegra20-slink.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)

--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1063,6 +1063,24 @@ static int tegra_slink_probe(struct plat
goto exit_free_master;
}

+ /* disabled clock may cause interrupt storm upon request */
+ tspi->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(tspi->clk)) {
+ ret = PTR_ERR(tspi->clk);
+ dev_err(&pdev->dev, "Can not get clock %d\n", ret);
+ goto exit_free_master;
+ }
+ ret = clk_prepare(tspi->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Clock prepare failed %d\n", ret);
+ goto exit_free_master;
+ }
+ ret = clk_enable(tspi->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Clock enable failed %d\n", ret);
+ goto exit_free_master;
+ }
+
spi_irq = platform_get_irq(pdev, 0);
tspi->irq = spi_irq;
ret = request_threaded_irq(tspi->irq, tegra_slink_isr,
@@ -1071,14 +1089,7 @@ static int tegra_slink_probe(struct plat
if (ret < 0) {
dev_err(&pdev->dev, "Failed to register ISR for IRQ %d\n",
tspi->irq);
- goto exit_free_master;
- }
-
- tspi->clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(tspi->clk)) {
- dev_err(&pdev->dev, "can not get clock\n");
- ret = PTR_ERR(tspi->clk);
- goto exit_free_irq;
+ goto exit_clk_disable;
}

tspi->rst = devm_reset_control_get(&pdev->dev, "spi");
@@ -1138,6 +1149,8 @@ exit_rx_dma_free:
tegra_slink_deinit_dma_param(tspi, true);
exit_free_irq:
free_irq(spi_irq, tspi);
+exit_clk_disable:
+ clk_disable(tspi->clk);
exit_free_master:
spi_master_put(master);
return ret;
@@ -1150,6 +1163,8 @@ static int tegra_slink_remove(struct pla

free_irq(tspi->irq, tspi);

+ clk_disable(tspi->clk);
+
if (tspi->tx_dma_chan)
tegra_slink_deinit_dma_param(tspi, false);




2018-10-08 18:35:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 027/113] media: omap3isp: zero-initialize the isp cam_xclk{a,b} initial data

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Javier Martinez Canillas <[email protected]>

[ Upstream commit 2ec7debd44b49927a6e2861521994cc075a389ed ]

The struct clk_init_data init variable is declared in the isp_xclk_init()
function so is an automatic variable allocated in the stack. But it's not
explicitly zero-initialized, so some init fields are left uninitialized.

This causes the data structure to have undefined values that may confuse
the common clock framework when the clock is registered.

For example, the uninitialized .flags field could have the CLK_IS_CRITICAL
bit set, causing the framework to wrongly prepare the clk on registration.
This leads to the isp_xclk_prepare() callback being called, which in turn
calls to the omap3isp_get() function that increments the isp dev refcount.

Since this omap3isp_get() call is unexpected, this leads to an unbalanced
omap3isp_get() call that prevents the requested IRQ to be later enabled,
due the refcount not being 0 when the correct omap3isp_get() call happens.

Fixes: 9b28ee3c9122 ("[media] omap3isp: Use the common clock framework")

Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Sakari Ailus <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/omap3isp/isp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -303,7 +303,7 @@ static struct clk *isp_xclk_src_get(stru
static int isp_xclk_init(struct isp_device *isp)
{
struct device_node *np = isp->dev->of_node;
- struct clk_init_data init;
+ struct clk_init_data init = { 0 };
unsigned int i;

for (i = 0; i < ARRAY_SIZE(isp->xclks); ++i)



2018-10-08 18:36:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 032/113] ath10k: protect ath10k_htt_rx_ring_free with rx_ring.lock

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Greear <[email protected]>

[ Upstream commit 168f75f11fe68455e0d058a818ebccfc329d8685 ]

While debugging driver crashes related to a buggy firmware
crashing under load, I noticed that ath10k_htt_rx_ring_free
could be called without being under lock. I'm not sure if this
is the root cause of the crash or not, but it seems prudent to
protect it.

Originally tested on 4.16+ kernel with ath10k-ct 10.4 firmware
running on 9984 NIC.

Signed-off-by: Ben Greear <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -212,11 +212,12 @@ int ath10k_htt_rx_ring_refill(struct ath
spin_lock_bh(&htt->rx_ring.lock);
ret = ath10k_htt_rx_ring_fill_n(htt, (htt->rx_ring.fill_level -
htt->rx_ring.fill_cnt));
- spin_unlock_bh(&htt->rx_ring.lock);

if (ret)
ath10k_htt_rx_ring_free(htt);

+ spin_unlock_bh(&htt->rx_ring.lock);
+
return ret;
}

@@ -230,7 +231,9 @@ void ath10k_htt_rx_free(struct ath10k_ht
skb_queue_purge(&htt->rx_compl_q);
skb_queue_purge(&htt->rx_in_ord_compl_q);

+ spin_lock_bh(&htt->rx_ring.lock);
ath10k_htt_rx_ring_free(htt);
+ spin_unlock_bh(&htt->rx_ring.lock);

dma_free_coherent(htt->ar->dev,
(htt->rx_ring.size *



2018-10-08 18:36:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 021/113] powerpc/powernv/ioda2: Reduce upper limit for DMA window size

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexey Kardashevskiy <[email protected]>

[ Upstream commit d3d4ffaae439981e1e441ebb125aa3588627c5d8 ]

We use PHB in mode1 which uses bit 59 to select a correct DMA window.
However there is mode2 which uses bits 59:55 and allows up to 32 DMA
windows per a PE.

Even though documentation does not clearly specify that, it seems that
the actual hardware does not support bits 59:55 even in mode1, in other
words we can create a window as big as 1<<58 but DMA simply won't work.

This reduces the upper limit from 59 to 55 bits to let the userspace know
about the hardware limits.

Fixes: 7aafac11e3 "powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested"
Signed-off-by: Alexey Kardashevskiy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2270,7 +2270,7 @@ static long pnv_pci_ioda2_table_alloc_pa
level_shift = entries_shift + 3;
level_shift = max_t(unsigned, level_shift, PAGE_SHIFT);

- if ((level_shift - 3) * levels + page_shift >= 60)
+ if ((level_shift - 3) * levels + page_shift >= 55)
return -EINVAL;

/* Allocate TCE table */



2018-10-08 18:36:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 058/113] Input: elantech - enable middle button of touchpad on ThinkPad P72

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aaron Ma <[email protected]>

commit 91a97507323e1ad4bfc10f4a5922e67cdaf8b3cd upstream.

Adding 2 new touchpad IDs to support middle button support.

Cc: [email protected]
Signed-off-by: Aaron Ma <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/mouse/elantech.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1180,6 +1180,8 @@ static const struct dmi_system_id elante
static const char * const middle_button_pnp_ids[] = {
"LEN2131", /* ThinkPad P52 w/ NFC */
"LEN2132", /* ThinkPad P52 */
+ "LEN2133", /* ThinkPad P72 w/ NFC */
+ "LEN2134", /* ThinkPad P72 */
NULL
};




2018-10-08 18:36:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 057/113] USB: remove LPM management from usb_driver_claim_interface()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit c183813fcee44a249339b7c46e1ad271ca1870aa upstream.

usb_driver_claim_interface() disables and re-enables Link Power
Management, but it shouldn't do either one, for the reasons listed
below. This patch removes the two LPM-related function calls from the
routine.

The reason for disabling LPM in the analogous function
usb_probe_interface() is so that drivers won't have to deal with
unwanted LPM transitions in their probe routine. But
usb_driver_claim_interface() doesn't call the driver's probe routine
(or any other callbacks), so that reason doesn't apply here.

Furthermore, no driver other than usbfs will ever call
usb_driver_claim_interface() unless it is already bound to another
interface in the same device, which means disabling LPM here would be
redundant. usbfs doesn't interact with LPM at all.

Lastly, the error return from usb_unlocked_disable_lpm() isn't handled
properly; the code doesn't clean up its earlier actions before
returning.

Signed-off-by: Alan Stern <[email protected]>
Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")
CC: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/driver.c | 15 ---------------
1 file changed, 15 deletions(-)

--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -509,7 +509,6 @@ int usb_driver_claim_interface(struct us
struct device *dev;
struct usb_device *udev;
int retval = 0;
- int lpm_disable_error = -ENODEV;

if (!iface)
return -ENODEV;
@@ -530,16 +529,6 @@ int usb_driver_claim_interface(struct us

iface->condition = USB_INTERFACE_BOUND;

- /* See the comment about disabling LPM in usb_probe_interface(). */
- if (driver->disable_hub_initiated_lpm) {
- lpm_disable_error = usb_unlocked_disable_lpm(udev);
- if (lpm_disable_error) {
- dev_err(&iface->dev, "%s Failed to disable LPM for driver %s\n.",
- __func__, driver->name);
- return -ENOMEM;
- }
- }
-
/* Claimed interfaces are initially inactive (suspended) and
* runtime-PM-enabled, but only if the driver has autosuspend
* support. Otherwise they are marked active, to prevent the
@@ -558,10 +547,6 @@ int usb_driver_claim_interface(struct us
if (device_is_registered(dev))
retval = device_bind_driver(dev);

- /* Attempt to re-enable USB3 LPM, if the disable was successful. */
- if (!lpm_disable_error)
- usb_unlocked_enable_lpm(udev);
-
if (retval) {
dev->driver = NULL;
usb_set_intfdata(iface, NULL);



2018-10-08 18:36:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 060/113] scsi: target: iscsi: Use bin2hex instead of a re-implementation

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vincent Pelletier <[email protected]>

commit 8c39e2699f8acb2e29782a834e56306da24937fe upstream.

Signed-off-by: Vincent Pelletier <[email protected]>
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
[[email protected]: hunk context change for 4.4 and 4.9, no code change]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/target/iscsi/iscsi_target_auth.c | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)

--- a/drivers/target/iscsi/iscsi_target_auth.c
+++ b/drivers/target/iscsi/iscsi_target_auth.c
@@ -26,15 +26,6 @@
#include "iscsi_target_nego.h"
#include "iscsi_target_auth.h"

-static void chap_binaryhex_to_asciihex(char *dst, char *src, int src_len)
-{
- int i;
-
- for (i = 0; i < src_len; i++) {
- sprintf(&dst[i*2], "%02x", (int) src[i] & 0xff);
- }
-}
-
static void chap_gen_challenge(
struct iscsi_conn *conn,
int caller,
@@ -47,7 +38,7 @@ static void chap_gen_challenge(
memset(challenge_asciihex, 0, CHAP_CHALLENGE_LENGTH * 2 + 1);

get_random_bytes(chap->challenge, CHAP_CHALLENGE_LENGTH);
- chap_binaryhex_to_asciihex(challenge_asciihex, chap->challenge,
+ bin2hex(challenge_asciihex, chap->challenge,
CHAP_CHALLENGE_LENGTH);
/*
* Set CHAP_C, and copy the generated challenge into c_str.
@@ -287,7 +278,7 @@ static int chap_server_compute_md5(
}
crypto_free_hash(tfm);

- chap_binaryhex_to_asciihex(response, server_digest, MD5_SIGNATURE_SIZE);
+ bin2hex(response, server_digest, MD5_SIGNATURE_SIZE);
pr_debug("[server] MD5 Server Digest: %s\n", response);

if (memcmp(server_digest, client_digest, MD5_SIGNATURE_SIZE) != 0) {
@@ -431,7 +422,7 @@ static int chap_server_compute_md5(
/*
* Convert response from binary hex to ascii hext.
*/
- chap_binaryhex_to_asciihex(response, digest, MD5_SIGNATURE_SIZE);
+ bin2hex(response, digest, MD5_SIGNATURE_SIZE);
*nr_out_len += sprintf(nr_out_ptr + *nr_out_len, "CHAP_R=0x%s",
response);
*nr_out_len += 1;



2018-10-08 18:36:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 062/113] arm64: KVM: Tighten guest core register access from userspace

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dave Martin <[email protected]>

commit d26c25a9d19b5976b319af528886f89cf455692d upstream.

We currently allow userspace to access the core register file
in about any possible way, including straddling multiple
registers and doing unaligned accesses.

This is not the expected use of the ABI, and nobody is actually
using it that way. Let's tighten it by explicitly checking
the size and alignment for each field of the register file.

Cc: <[email protected]>
Fixes: 2f4a07c5f9fe ("arm64: KVM: guest one-reg interface")
Reviewed-by: Christoffer Dall <[email protected]>
Reviewed-by: Mark Rutland <[email protected]>
Signed-off-by: Dave Martin <[email protected]>
[maz: rewrote Dave's initial patch to be more easily backported]
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kvm/guest.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)

--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -48,6 +48,45 @@ static u64 core_reg_offset_from_id(u64 i
return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
}

+static int validate_core_offset(const struct kvm_one_reg *reg)
+{
+ u64 off = core_reg_offset_from_id(reg->id);
+ int size;
+
+ switch (off) {
+ case KVM_REG_ARM_CORE_REG(regs.regs[0]) ...
+ KVM_REG_ARM_CORE_REG(regs.regs[30]):
+ case KVM_REG_ARM_CORE_REG(regs.sp):
+ case KVM_REG_ARM_CORE_REG(regs.pc):
+ case KVM_REG_ARM_CORE_REG(regs.pstate):
+ case KVM_REG_ARM_CORE_REG(sp_el1):
+ case KVM_REG_ARM_CORE_REG(elr_el1):
+ case KVM_REG_ARM_CORE_REG(spsr[0]) ...
+ KVM_REG_ARM_CORE_REG(spsr[KVM_NR_SPSR - 1]):
+ size = sizeof(__u64);
+ break;
+
+ case KVM_REG_ARM_CORE_REG(fp_regs.vregs[0]) ...
+ KVM_REG_ARM_CORE_REG(fp_regs.vregs[31]):
+ size = sizeof(__uint128_t);
+ break;
+
+ case KVM_REG_ARM_CORE_REG(fp_regs.fpsr):
+ case KVM_REG_ARM_CORE_REG(fp_regs.fpcr):
+ size = sizeof(__u32);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ if (KVM_REG_SIZE(reg->id) == size &&
+ IS_ALIGNED(off, size / sizeof(__u32)))
+ return 0;
+
+ return -EINVAL;
+}
+
static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
/*
@@ -67,6 +106,9 @@ static int get_core_reg(struct kvm_vcpu
(off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
return -ENOENT;

+ if (validate_core_offset(reg))
+ return -EINVAL;
+
if (copy_to_user(uaddr, ((u32 *)regs) + off, KVM_REG_SIZE(reg->id)))
return -EFAULT;

@@ -89,6 +131,9 @@ static int set_core_reg(struct kvm_vcpu
(off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
return -ENOENT;

+ if (validate_core_offset(reg))
+ return -EINVAL;
+
if (KVM_REG_SIZE(reg->id) > sizeof(tmp))
return -EINVAL;




2018-10-08 18:36:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 061/113] serial: imx: restore handshaking irq for imx1

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Uwe Kleine-König <[email protected]>

commit 7e620984b62532783912312e334f3c48cdacbd5d upstream.

Back in 2015 when irda was dropped from the driver imx1 was broken. This
change reintroduces the support for the third interrupt of the UART.

Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA")
Cc: stable <[email protected]>
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Leonard Crestez <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/imx.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1997,6 +1997,14 @@ static int serial_imx_probe(struct platf
dev_name(&pdev->dev), sport);
if (ret)
return ret;
+
+ ret = devm_request_irq(&pdev->dev, rtsirq, imx_rtsint, 0,
+ dev_name(&pdev->dev), sport);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request rts irq: %d\n",
+ ret);
+ return ret;
+ }
} else {
ret = devm_request_irq(&pdev->dev, rxirq, imx_int, 0,
dev_name(&pdev->dev), sport);



2018-10-08 18:36:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 066/113] e1000: check on netif_running() before calling e1000_up()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bo Chen <[email protected]>

[ Upstream commit cf1acec008f8d7761aa3fd7c4bca7e17b2d2512d ]

When the device is not up, the call to 'e1000_up()' from the error handling path
of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer
dereference. The null-pointer dereference is triggered in function
'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'.

This bug was reported by COD, a tool for testing kernel module binaries I am
building. This bug was also detected by KFI from Dr. Kai Cong.

This patch fixes the bug by checking on 'netif_running()' before calling
'e1000_up()' in 'e1000_set_ringparam()'.

Signed-off-by: Bo Chen <[email protected]>
Acked-by: Alexander Duyck <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -665,7 +665,8 @@ err_setup_rx:
err_alloc_rx:
kfree(txdr);
err_alloc_tx:
- e1000_up(adapter);
+ if (netif_running(adapter->netdev))
+ e1000_up(adapter);
err_setup:
clear_bit(__E1000_RESETTING, &adapter->flags);
return err;



2018-10-08 18:37:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 072/113] arm64: KVM: Sanitize PSTATE.M when being set from userspace

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marc Zyngier <[email protected]>

commit 2a3f93459d689d990b3ecfbe782fec89b97d3279 upstream.

Not all execution modes are valid for a guest, and some of them
depend on what the HW actually supports. Let's verify that what
userspace provides is compatible with both the VM settings and
the HW capabilities.

Cc: <[email protected]>
Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu")
Reviewed-by: Christoffer Dall <[email protected]>
Reviewed-by: Mark Rutland <[email protected]>
Reviewed-by: Dave Martin <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/kvm/guest.c | 10 +++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)

--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -41,6 +41,11 @@ void kvm_inject_undefined(struct kvm_vcp
void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);

+static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
+{
+ return !(vcpu->arch.hcr_el2 & HCR_RW);
+}
+
static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
{
vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -143,17 +143,25 @@ static int set_core_reg(struct kvm_vcpu
}

if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
- u32 mode = (*(u32 *)valp) & COMPAT_PSR_MODE_MASK;
+ u64 mode = (*(u64 *)valp) & COMPAT_PSR_MODE_MASK;
switch (mode) {
case COMPAT_PSR_MODE_USR:
+ if (!system_supports_32bit_el0())
+ return -EINVAL;
+ break;
case COMPAT_PSR_MODE_FIQ:
case COMPAT_PSR_MODE_IRQ:
case COMPAT_PSR_MODE_SVC:
case COMPAT_PSR_MODE_ABT:
case COMPAT_PSR_MODE_UND:
+ if (!vcpu_el1_is_32bit(vcpu))
+ return -EINVAL;
+ break;
case PSR_MODE_EL0t:
case PSR_MODE_EL1t:
case PSR_MODE_EL1h:
+ if (vcpu_el1_is_32bit(vcpu))
+ return -EINVAL;
break;
default:
err = -EINVAL;



2018-10-08 18:37:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 068/113] hwmon: (ina2xx) fix sysfs shunt resistor read access

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lothar Felten <[email protected]>

[ Upstream commit 3ad867001c91657c46dcf6656d52eb6080286fd5 ]

fix the sysfs shunt resistor read access: return the shunt resistor
value, not the calibration register contents.

update email address

Signed-off-by: Lothar Felten <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/hwmon/ina2xx | 2 +-
drivers/hwmon/ina2xx.c | 13 +++++++++++--
include/linux/platform_data/ina2xx.h | 2 +-
3 files changed, 13 insertions(+), 4 deletions(-)

--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -32,7 +32,7 @@ Supported chips:
Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/

-Author: Lothar Felten <[email protected]>
+Author: Lothar Felten <[email protected]>

Description
-----------
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -17,7 +17,7 @@
* Bi-directional Current/Power Monitor with I2C Interface
* Datasheet: http://www.ti.com/product/ina230
*
- * Copyright (C) 2012 Lothar Felten <[email protected]>
+ * Copyright (C) 2012 Lothar Felten <[email protected]>
* Thanks to Jan Volkering
*
* This program is free software; you can redistribute it and/or modify
@@ -328,6 +328,15 @@ static int ina2xx_set_shunt(struct ina2x
return 0;
}

+static ssize_t ina2xx_show_shunt(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct ina2xx_data *data = dev_get_drvdata(dev);
+
+ return snprintf(buf, PAGE_SIZE, "%li\n", data->rshunt);
+}
+
static ssize_t ina2xx_store_shunt(struct device *dev,
struct device_attribute *da,
const char *buf, size_t count)
@@ -402,7 +411,7 @@ static SENSOR_DEVICE_ATTR(power1_input,

/* shunt resistance */
static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR,
- ina2xx_show_value, ina2xx_store_shunt,
+ ina2xx_show_shunt, ina2xx_store_shunt,
INA2XX_CALIBRATION);

/* update interval (ina226 only) */
--- a/include/linux/platform_data/ina2xx.h
+++ b/include/linux/platform_data/ina2xx.h
@@ -1,7 +1,7 @@
/*
* Driver for Texas Instruments INA219, INA226 power monitor chips
*
- * Copyright (C) 2012 Lothar Felten <[email protected]>
+ * Copyright (C) 2012 Lothar Felten <[email protected]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as



2018-10-08 18:37:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 051/113] USB: handle NULL config in usb_find_alt_setting()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit c9a4cb204e9eb7fa7dfbe3f7d3a674fa530aa193 upstream.

usb_find_alt_setting() takes a pointer to a struct usb_host_config as
an argument; it searches for an interface with specified interface and
alternate setting numbers in that config. However, it crashes if the
usb_host_config pointer argument is NULL.

Since this is a general-purpose routine, available for use in many
places, we want to to be more robust. This patch makes it return NULL
whenever the config argument is NULL.

Signed-off-by: Alan Stern <[email protected]>
Reported-by: [email protected]
CC: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/usb.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -95,6 +95,8 @@ struct usb_host_interface *usb_find_alt_
struct usb_interface_cache *intf_cache = NULL;
int i;

+ if (!config)
+ return NULL;
for (i = 0; i < config->desc.bNumInterfaces; i++) {
if (config->intf_cache[i]->altsetting[0].desc.bInterfaceNumber
== iface_num) {



2018-10-08 18:37:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 053/113] media: uvcvideo: Support realteks UVC 1.5 device

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: ming_qian <[email protected]>

commit f620d1d7afc7db57ab59f35000752840c91f67e7 upstream.

media: uvcvideo: Support UVC 1.5 video probe & commit controls

The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be
recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been
reported to work well.

[[email protected]: Factor out code to helper function, update size checks]

Cc: [email protected]
Signed-off-by: ming_qian <[email protected]>
Signed-off-by: Laurent Pinchart <[email protected]>
Tested-by: Kai-Heng Feng <[email protected]>
Tested-by: Ana Guerrero Lopez <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/usb/uvc/uvc_video.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)

--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -163,14 +163,27 @@ static void uvc_fixup_video_ctrl(struct
}
}

+static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
+{
+ /*
+ * Return the size of the video probe and commit controls, which depends
+ * on the protocol version.
+ */
+ if (stream->dev->uvc_version < 0x0110)
+ return 26;
+ else if (stream->dev->uvc_version < 0x0150)
+ return 34;
+ else
+ return 48;
+}
+
static int uvc_get_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl, int probe, __u8 query)
{
+ __u16 size = uvc_video_ctrl_size(stream);
__u8 *data;
- __u16 size;
int ret;

- size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
query == UVC_GET_DEF)
return -EIO;
@@ -225,7 +238,7 @@ static int uvc_get_video_ctrl(struct uvc
ctrl->dwMaxVideoFrameSize = get_unaligned_le32(&data[18]);
ctrl->dwMaxPayloadTransferSize = get_unaligned_le32(&data[22]);

- if (size == 34) {
+ if (size >= 34) {
ctrl->dwClockFrequency = get_unaligned_le32(&data[26]);
ctrl->bmFramingInfo = data[30];
ctrl->bPreferedVersion = data[31];
@@ -254,11 +267,10 @@ out:
static int uvc_set_video_ctrl(struct uvc_streaming *stream,
struct uvc_streaming_control *ctrl, int probe)
{
+ __u16 size = uvc_video_ctrl_size(stream);
__u8 *data;
- __u16 size;
int ret;

- size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
data = kzalloc(size, GFP_KERNEL);
if (data == NULL)
return -ENOMEM;
@@ -275,7 +287,7 @@ static int uvc_set_video_ctrl(struct uvc
put_unaligned_le32(ctrl->dwMaxVideoFrameSize, &data[18]);
put_unaligned_le32(ctrl->dwMaxPayloadTransferSize, &data[22]);

- if (size == 34) {
+ if (size >= 34) {
put_unaligned_le32(ctrl->dwClockFrequency, &data[26]);
data[30] = ctrl->bmFramingInfo;
data[31] = ctrl->bPreferedVersion;



2018-10-08 18:37:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 028/113] staging: android: ashmem: Fix mmap size validation

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alistair Strachan <[email protected]>

[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]

The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.

Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.

Cc: Todd Kjos <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Joel Fernandes <[email protected]>
Signed-off-by: Alistair Strachan <[email protected]>
Acked-by: Joel Fernandes (Google) <[email protected]>
Reviewed-by: Martijn Coenen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/android/ashmem.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -370,6 +370,12 @@ static int ashmem_mmap(struct file *file
goto out;
}

+ /* requested mapping size larger than object size */
+ if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask)) &
calc_vm_prot_bits(PROT_MASK))) {



2018-10-08 18:37:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 029/113] drivers/tty: add error handling for pcmcia_loop_config

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhouyang Jia <[email protected]>

[ Upstream commit 85c634e919bd6ef17427f26a52920aeba12e16ee ]

When pcmcia_loop_config fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling pcmcia_loop_config.

Signed-off-by: Zhouyang Jia <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/8250/serial_cs.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/8250/serial_cs.c
+++ b/drivers/tty/serial/8250/serial_cs.c
@@ -629,8 +629,10 @@ static int serial_config(struct pcmcia_d
(link->has_func_id) &&
(link->socket->pcmcia_pfc == 0) &&
((link->func_id == CISTPL_FUNCID_MULTI) ||
- (link->func_id == CISTPL_FUNCID_SERIAL)))
- pcmcia_loop_config(link, serial_check_for_multi, info);
+ (link->func_id == CISTPL_FUNCID_SERIAL))) {
+ if (pcmcia_loop_config(link, serial_check_for_multi, info))
+ goto failed;
+ }

/*
* Apply any multi-port quirk.



2018-10-08 18:37:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 030/113] media: tm6000: add error handling for dvb_register_adapter

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhouyang Jia <[email protected]>

[ Upstream commit e95d7c6eb94c634852eaa5ff4caf3db05b5d2e86 ]

When dvb_register_adapter fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling dvb_register_adapter.

Signed-off-by: Zhouyang Jia <[email protected]>
[[email protected]: use pr_err and fix typo: adater -> adapter]
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/tm6000/tm6000-dvb.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -275,6 +275,11 @@ static int register_dvb(struct tm6000_co

ret = dvb_register_adapter(&dvb->adapter, "Trident TVMaster 6000 DVB-T",
THIS_MODULE, &dev->udev->dev, adapter_nr);
+ if (ret < 0) {
+ pr_err("tm6000: couldn't register the adapter!\n");
+ goto err;
+ }
+
dvb->adapter.priv = dev;

if (dvb->frontend) {



2018-10-08 18:37:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 048/113] spi: rspi: Fix invalid SPI use during system suspend

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <[email protected]>

commit c1ca59c22c56930b377a665fdd1b43351887830b upstream.

If the SPI queue is running during system suspend, the system may lock
up.

Fix this by stopping/restarting the queue during system suspend/resume,
by calling spi_master_suspend()/spi_master_resume() from the PM
callbacks. In-kernel users will receive an -ESHUTDOWN error while
system suspend/resume is in progress.

Based on a patch for sh-msiof by Gaku Inami.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-rspi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -1303,12 +1303,36 @@ static const struct platform_device_id s

MODULE_DEVICE_TABLE(platform, spi_driver_ids);

+#ifdef CONFIG_PM_SLEEP
+static int rspi_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct rspi_data *rspi = platform_get_drvdata(pdev);
+
+ return spi_master_suspend(rspi->master);
+}
+
+static int rspi_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct rspi_data *rspi = platform_get_drvdata(pdev);
+
+ return spi_master_resume(rspi->master);
+}
+
+static SIMPLE_DEV_PM_OPS(rspi_pm_ops, rspi_suspend, rspi_resume);
+#define DEV_PM_OPS &rspi_pm_ops
+#else
+#define DEV_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
static struct platform_driver rspi_driver = {
.probe = rspi_probe,
.remove = rspi_remove,
.id_table = spi_driver_ids,
.driver = {
.name = "renesas_spi",
+ .pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(rspi_of_match),
},
};



2018-10-08 18:37:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 052/113] slub: make ->cpu_partial unsigned int

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alexey Dobriyan <[email protected]>

commit e5d9998f3e09359b372a037a6ac55ba235d95d57 upstream.

/*
* cpu_partial determined the maximum number of objects
* kept in the per cpu partial lists of a processor.
*/

Can't be negative.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Alexey Dobriyan <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: zhong jiang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/linux/slub_def.h | 3 ++-
mm/slub.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)

--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -67,7 +67,8 @@ struct kmem_cache {
int size; /* The size of an object including meta data */
int object_size; /* The size of an object without meta data */
int offset; /* Free pointer offset. */
- int cpu_partial; /* Number of per cpu partial objects to keep around */
+ /* Number of per cpu partial objects to keep around */
+ unsigned int cpu_partial;
struct kmem_cache_order_objects oo;

/* Allocation and freeing of slabs */
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1661,7 +1661,7 @@ static void *get_partial_node(struct kme
{
struct page *page, *page2;
void *object = NULL;
- int available = 0;
+ unsigned int available = 0;
int objects;

/*
@@ -4674,10 +4674,10 @@ static ssize_t cpu_partial_show(struct k
static ssize_t cpu_partial_store(struct kmem_cache *s, const char *buf,
size_t length)
{
- unsigned long objects;
+ unsigned int objects;
int err;

- err = kstrtoul(buf, 10, &objects);
+ err = kstrtouint(buf, 10, &objects);
if (err)
return err;
if (objects && !kmem_cache_has_cpu_partial(s))



2018-10-08 18:37:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 085/113] cfg80211: fix a type issue in ieee80211_chandef_to_operating_class()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 8442938c3a2177ba16043b3a935f2c78266ad399 ]

The "chandef->center_freq1" variable is a u32 but "freq" is a u16 so we
are truncating away the high bits. I noticed this bug because in commit
9cf0a0b4b64a ("cfg80211: Add support for 60GHz band channels 5 and 6")
we made "freq <= 56160 + 2160 * 6" a valid requency when before it was
only "freq <= 56160 + 2160 * 4" that was valid. It introduces a static
checker warning:

net/wireless/util.c:1571 ieee80211_chandef_to_operating_class()
warn: always true condition '(freq <= 56160 + 2160 * 6) => (0-u16max <= 69120)'

But really we probably shouldn't have been truncating the high bits
away to begin with.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/wireless/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1360,7 +1360,7 @@ bool ieee80211_chandef_to_operating_clas
u8 *op_class)
{
u8 vht_opclass;
- u16 freq = chandef->center_freq1;
+ u32 freq = chandef->center_freq1;

if (freq >= 2412 && freq <= 2472) {
if (chandef->width > NL80211_CHAN_WIDTH_40)



2018-10-08 18:37:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 059/113] IB/srp: Avoid that sg_reset -d ${srp_device} triggers an infinite loop

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

commit ee92efe41cf358f4b99e73509f2bfd4733609f26 upstream.

Use different loop variables for the inner and outer loop. This avoids
that an infinite loop occurs if there are more RDMA channels than
target->req_ring_size.

Fixes: d92c0da71a35 ("IB/srp: Add multichannel support")
Cc: <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/ulp/srp/ib_srp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2594,7 +2594,7 @@ static int srp_reset_device(struct scsi_
{
struct srp_target_port *target = host_to_target(scmnd->device->host);
struct srp_rdma_ch *ch;
- int i;
+ int i, j;
u8 status;

shost_printk(KERN_ERR, target->scsi_host, "SRP reset_device called\n");
@@ -2608,8 +2608,8 @@ static int srp_reset_device(struct scsi_

for (i = 0; i < target->ch_count; i++) {
ch = &target->ch[i];
- for (i = 0; i < target->req_ring_size; ++i) {
- struct srp_request *req = &ch->req_ring[i];
+ for (j = 0; j < target->req_ring_size; ++j) {
+ struct srp_request *req = &ch->req_ring[j];

srp_finish_req(ch, req, scmnd->device, DID_RESET << 16);
}



2018-10-08 18:37:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 087/113] mac80211: Fix station bandwidth setting after channel switch

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilan Peer <[email protected]>

[ Upstream commit 0007e94355fdb71a1cf5dba0754155cba08f0666 ]

When performing a channel switch flow for a managed interface, the
flow did not update the bandwidth of the AP station and the rate
scale algorithm. In case of a channel width downgrade, this would
result with the rate scale algorithm using a bandwidth that does not
match the interface channel configuration.

Fix this by updating the AP station bandwidth and rate scaling algorithm
before the actual channel change in case of a bandwidth downgrade, or
after the actual channel change in case of a bandwidth upgrade.

Signed-off-by: Ilan Peer <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/mlme.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)

--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1021,6 +1021,10 @@ static void ieee80211_chswitch_work(stru
*/

if (sdata->reserved_chanctx) {
+ struct ieee80211_supported_band *sband = NULL;
+ struct sta_info *mgd_sta = NULL;
+ enum ieee80211_sta_rx_bandwidth bw = IEEE80211_STA_RX_BW_20;
+
/*
* with multi-vif csa driver may call ieee80211_csa_finish()
* many times while waiting for other interfaces to use their
@@ -1029,6 +1033,48 @@ static void ieee80211_chswitch_work(stru
if (sdata->reserved_ready)
goto out;

+ if (sdata->vif.bss_conf.chandef.width !=
+ sdata->csa_chandef.width) {
+ /*
+ * For managed interface, we need to also update the AP
+ * station bandwidth and align the rate scale algorithm
+ * on the bandwidth change. Here we only consider the
+ * bandwidth of the new channel definition (as channel
+ * switch flow does not have the full HT/VHT/HE
+ * information), assuming that if additional changes are
+ * required they would be done as part of the processing
+ * of the next beacon from the AP.
+ */
+ switch (sdata->csa_chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
+ default:
+ bw = IEEE80211_STA_RX_BW_20;
+ break;
+ case NL80211_CHAN_WIDTH_40:
+ bw = IEEE80211_STA_RX_BW_40;
+ break;
+ case NL80211_CHAN_WIDTH_80:
+ bw = IEEE80211_STA_RX_BW_80;
+ break;
+ case NL80211_CHAN_WIDTH_80P80:
+ case NL80211_CHAN_WIDTH_160:
+ bw = IEEE80211_STA_RX_BW_160;
+ break;
+ }
+
+ mgd_sta = sta_info_get(sdata, ifmgd->bssid);
+ sband =
+ local->hw.wiphy->bands[sdata->csa_chandef.chan->band];
+ }
+
+ if (sdata->vif.bss_conf.chandef.width >
+ sdata->csa_chandef.width) {
+ mgd_sta->sta.bandwidth = bw;
+ rate_control_rate_update(local, sband, mgd_sta,
+ IEEE80211_RC_BW_CHANGED);
+ }
+
ret = ieee80211_vif_use_reserved_context(sdata);
if (ret) {
sdata_info(sdata,
@@ -1039,6 +1085,13 @@ static void ieee80211_chswitch_work(stru
goto out;
}

+ if (sdata->vif.bss_conf.chandef.width <
+ sdata->csa_chandef.width) {
+ mgd_sta->sta.bandwidth = bw;
+ rate_control_rate_update(local, sband, mgd_sta,
+ IEEE80211_RC_BW_CHANGED);
+ }
+
goto out;
}




2018-10-08 18:37:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 090/113] tools/vm/page-types.c: fix "defined but not used" warning

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Naoya Horiguchi <[email protected]>

[ Upstream commit 7ab660f8baecfe26c1c267fa8e64d2073feae2bb ]

debugfs_known_mountpoints[] is not used any more, so let's remove it.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Naoya Horiguchi <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/vm/page-types.c | 6 ------
1 file changed, 6 deletions(-)

--- a/tools/vm/page-types.c
+++ b/tools/vm/page-types.c
@@ -150,12 +150,6 @@ static const char * const page_flag_name
};


-static const char * const debugfs_known_mountpoints[] = {
- "/sys/kernel/debug",
- "/debug",
- 0,
-};
-
/*
* data structures
*/



2018-10-08 18:37:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 063/113] ext4: never move the system.data xattr out of the inode body

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Theodore Ts'o <[email protected]>

commit 8cdb5240ec5928b20490a2bb34cb87e9a5f40226 upstream.

When expanding the extra isize space, we must never move the
system.data xattr out of the inode body. For performance reasons, it
doesn't make any sense, and the inline data implementation assumes
that system.data xattr is never in the external xattr block.

This addresses CVE-2018-10880

https://bugzilla.kernel.org/show_bug.cgi?id=200005

Signed-off-by: Theodore Ts'o <[email protected]>
Cc: [email protected]
Signed-off-by: Zubin Mithra <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/xattr.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1386,6 +1386,11 @@ retry:
/* Find the entry best suited to be pushed into EA block */
entry = NULL;
for (; !IS_LAST_ENTRY(last); last = EXT4_XATTR_NEXT(last)) {
+ /* never move system.data out of the inode */
+ if ((last->e_name_len == 4) &&
+ (last->e_name_index == EXT4_XATTR_INDEX_SYSTEM) &&
+ !memcmp(last->e_name, "data", 4))
+ continue;
total_size =
EXT4_XATTR_SIZE(le32_to_cpu(last->e_value_size)) +
EXT4_XATTR_LEN(last->e_name_len);



2018-10-08 18:37:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 091/113] mm: madvise(MADV_DODUMP): allow hugetlbfs pages

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Black <[email protected]>

commit d41aa5252394c065d1f04d1ceea885b70d00c9c6 upstream.

Reproducer, assuming 2M of hugetlbfs available:

Hugetlbfs mounted, size=2M and option user=testuser

# mount | grep ^hugetlbfs
hugetlbfs on /dev/hugepages type hugetlbfs (rw,pagesize=2M,user=dan)
# sysctl vm.nr_hugepages=1
vm.nr_hugepages = 1
# grep Huge /proc/meminfo
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 1
HugePages_Free: 1
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 2048 kB

Code:

#include <sys/mman.h>
#include <stddef.h>
#define SIZE 2*1024*1024
int main()
{
void *ptr;
ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_HUGETLB | MAP_ANONYMOUS, -1, 0);
madvise(ptr, SIZE, MADV_DONTDUMP);
madvise(ptr, SIZE, MADV_DODUMP);
}

Compile and strace:

mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7ff7c9200000
madvise(0x7ff7c9200000, 2097152, MADV_DONTDUMP) = 0
madvise(0x7ff7c9200000, 2097152, MADV_DODUMP) = -1 EINVAL (Invalid argument)

hugetlbfs pages have VM_DONTEXPAND in the VmFlags driver pages based on
author testing with analysis from Florian Weimer[1].

The inclusion of VM_DONTEXPAND into the VM_SPECIAL defination was a
consequence of the large useage of VM_DONTEXPAND in device drivers.

A consequence of [2] is that VM_DONTEXPAND marked pages are unable to be
marked DODUMP.

A user could quite legitimately madvise(MADV_DONTDUMP) their hugetlbfs
memory for a while and later request that madvise(MADV_DODUMP) on the same
memory. We correct this omission by allowing madvice(MADV_DODUMP) on
hugetlbfs pages.

[1] https://stackoverflow.com/questions/52548260/madvisedodump-on-the-same-ptr-size-as-a-successful-madvisedontdump-fails-wit
[2] commit 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers")

Link: http://lkml.kernel.org/r/[email protected]
Link: https://lists.launchpad.net/maria-discuss/msg05245.html
Fixes: 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers")
Reported-by: Kenneth Penza <[email protected]>
Signed-off-by: Daniel Black <[email protected]>
Reviewed-by: Mike Kravetz <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/madvise.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -76,7 +76,7 @@ static long madvise_behavior(struct vm_a
new_flags |= VM_DONTDUMP;
break;
case MADV_DODUMP:
- if (new_flags & VM_SPECIAL) {
+ if (!is_vm_hugetlb_page(vma) && new_flags & VM_SPECIAL) {
error = -EINVAL;
goto out;
}



2018-10-08 18:37:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 092/113] usb: gadget: fotg210-udc: Fix memory leak of fotg210->ep[i]

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anton Vasilyev <[email protected]>

[ Upstream commit c37bd52836296ecc9a0fc8060b819089aebdbcde ]

There is no deallocation of fotg210->ep[i] elements, allocated at
fotg210_udc_probe.

The patch adds deallocation of fotg210->ep array elements and simplifies
error path of fotg210_udc_probe().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/udc/fotg210-udc.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)

--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -1066,12 +1066,15 @@ static struct usb_gadget_ops fotg210_gad
static int fotg210_udc_remove(struct platform_device *pdev)
{
struct fotg210_udc *fotg210 = platform_get_drvdata(pdev);
+ int i;

usb_del_gadget_udc(&fotg210->gadget);
iounmap(fotg210->reg);
free_irq(platform_get_irq(pdev, 0), fotg210);

fotg210_ep_free_request(&fotg210->ep[0]->ep, fotg210->ep0_req);
+ for (i = 0; i < FOTG210_MAX_NUM_EP; i++)
+ kfree(fotg210->ep[i]);
kfree(fotg210);

return 0;
@@ -1102,7 +1105,7 @@ static int fotg210_udc_probe(struct plat
/* initialize udc */
fotg210 = kzalloc(sizeof(struct fotg210_udc), GFP_KERNEL);
if (fotg210 == NULL)
- goto err_alloc;
+ goto err;

for (i = 0; i < FOTG210_MAX_NUM_EP; i++) {
_ep[i] = kzalloc(sizeof(struct fotg210_ep), GFP_KERNEL);
@@ -1114,7 +1117,7 @@ static int fotg210_udc_probe(struct plat
fotg210->reg = ioremap(res->start, resource_size(res));
if (fotg210->reg == NULL) {
pr_err("ioremap error.\n");
- goto err_map;
+ goto err_alloc;
}

spin_lock_init(&fotg210->lock);
@@ -1162,7 +1165,7 @@ static int fotg210_udc_probe(struct plat
fotg210->ep0_req = fotg210_ep_alloc_request(&fotg210->ep[0]->ep,
GFP_KERNEL);
if (fotg210->ep0_req == NULL)
- goto err_req;
+ goto err_map;

fotg210_init(fotg210);

@@ -1190,12 +1193,14 @@ err_req:
fotg210_ep_free_request(&fotg210->ep[0]->ep, fotg210->ep0_req);

err_map:
- if (fotg210->reg)
- iounmap(fotg210->reg);
+ iounmap(fotg210->reg);

err_alloc:
+ for (i = 0; i < FOTG210_MAX_NUM_EP; i++)
+ kfree(fotg210->ep[i]);
kfree(fotg210);

+err:
return ret;
}




2018-10-08 18:37:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 065/113] net: hns: fix length and page_offset overflow when CONFIG_ARM64_64K_PAGES

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Huazhong Tan <[email protected]>

[ Upstream commit 3ed614dce3ca9912d22be215ff0f11104b69fe62 ]

When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE
is 65536(64K). But the type of length and page_offset are u16, they will
overflow. So change them to u32.

Fixes: 6fe6611ff275 ("net: add Hisilicon Network Subsystem hnae framework support")
Signed-off-by: Huazhong Tan <[email protected]>
Signed-off-by: Salil Mehta <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -171,10 +171,10 @@ struct hnae_desc_cb {

/* priv data for the desc, e.g. skb when use with ip stack*/
void *priv;
- u16 page_offset;
- u16 reuse_flag;
+ u32 page_offset;
+ u32 length; /* length of the buffer */

- u16 length; /* length of the buffer */
+ u16 reuse_flag;

/* desc type, used by the ring user to mark the type of the priv data */
u16 type;



2018-10-08 18:37:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 049/113] spi: rspi: Fix interrupted DMA transfers

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Geert Uytterhoeven <[email protected]>

commit 8dbbaa47b96f6ea5f09f922b4effff3c505cd8cf upstream.

When interrupted, wait_event_interruptible_timeout() returns
-ERESTARTSYS, and the SPI transfer in progress will fail, as expected:

m25p80 spi0.0: SPI transfer failed: -512
spi_master spi0: failed to transfer one message from queue

However, as the underlying DMA transfers may not have completed, all
subsequent SPI transfers may start to fail:

spi_master spi0: receive timeout
qspi_transfer_out_in() returned -110
m25p80 spi0.0: SPI transfer failed: -110
spi_master spi0: failed to transfer one message from queue

Fix this by calling dmaengine_terminate_all() not only for timeouts, but
also for errors.

This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed
by CTRL-C.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-rspi.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -587,11 +587,13 @@ static int rspi_dma_transfer(struct rspi

ret = wait_event_interruptible_timeout(rspi->wait,
rspi->dma_callbacked, HZ);
- if (ret > 0 && rspi->dma_callbacked)
+ if (ret > 0 && rspi->dma_callbacked) {
ret = 0;
- else if (!ret) {
- dev_err(&rspi->master->dev, "DMA timeout\n");
- ret = -ETIMEDOUT;
+ } else {
+ if (!ret) {
+ dev_err(&rspi->master->dev, "DMA timeout\n");
+ ret = -ETIMEDOUT;
+ }
if (tx)
dmaengine_terminate_all(rspi->master->dma_tx);
if (rx)



2018-10-08 18:37:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 067/113] e1000: ensure to free old tx/rx rings in set_ringparam()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bo Chen <[email protected]>

[ Upstream commit ee400a3f1bfe7004a3e14b81c38ccc5583c26295 ]

In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value
and the old tx/rx rings are freed only when the device is up. There are resource
leaks on old tx/rx rings when the device is not up. This bug is reported by COD,
a tool for testing kernel module binaries I am building.

This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in
'e1000_set_ringparam()'.

Signed-off-by: Bo Chen <[email protected]>
Reviewed-by: Alexander Duyck <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -645,14 +645,14 @@ static int e1000_set_ringparam(struct ne
adapter->tx_ring = tx_old;
e1000_free_all_rx_resources(adapter);
e1000_free_all_tx_resources(adapter);
- kfree(tx_old);
- kfree(rx_old);
adapter->rx_ring = rxdr;
adapter->tx_ring = txdr;
err = e1000_up(adapter);
if (err)
goto err_setup;
}
+ kfree(tx_old);
+ kfree(rx_old);

clear_bit(__E1000_RESETTING, &adapter->flags);
return 0;



2018-10-08 18:37:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stephen Boyd <[email protected]>

[ Upstream commit b55326dc969ea2d704a008d9a97583b128f54f4f ]

The interrupt controller hardware in this pin controller has two status
enable bits. The first "normal" status enable bit enables or disables
the summary interrupt line being raised when a gpio interrupt triggers
and the "raw" status enable bit allows or prevents the hardware from
latching an interrupt into the status register for a gpio interrupt.
Currently we just toggle the "normal" status enable bit in the mask and
unmask ops so that the summary irq interrupt going to the CPU's
interrupt controller doesn't trigger for the masked gpio interrupt.

For a level triggered interrupt, the flow would be as follows: the pin
controller sees the interrupt, latches the status into the status
register, raises the summary irq to the CPU, summary irq handler runs
and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
interrupt, the interrupt handler runs, and finally unmask the interrupt.
When the interrupt handler completes, we expect that the interrupt line
level will go back to the deasserted state so the genirq code can unmask
the interrupt without it triggering again.

If we only mask the interrupt by clearing the "normal" status enable bit
then we'll ack the interrupt but it will continue to show up as pending
in the status register because the raw status bit is enabled, the
hardware hasn't deasserted the line, and thus the asserted state latches
into the status register again. When the hardware deasserts the
interrupt the pin controller still thinks there is a pending unserviced
level interrupt because it latched it earlier. This behavior causes
software to see an extra interrupt for level type interrupts each time
the interrupt is handled.

Let's fix this by clearing the raw status enable bit for level type
interrupts so that the hardware stops latching the status of the
interrupt after we ack it. We don't do this for edge type interrupts
because it seems that toggling the raw status enable bit for edge type
interrupts causes spurious edge interrupts.

Signed-off-by: Stephen Boyd <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pinctrl/qcom/pinctrl-msm.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -577,6 +577,29 @@ static void msm_gpio_irq_mask(struct irq
spin_lock_irqsave(&pctrl->lock, flags);

val = readl(pctrl->regs + g->intr_cfg_reg);
+ /*
+ * There are two bits that control interrupt forwarding to the CPU. The
+ * RAW_STATUS_EN bit causes the level or edge sensed on the line to be
+ * latched into the interrupt status register when the hardware detects
+ * an irq that it's configured for (either edge for edge type or level
+ * for level type irq). The 'non-raw' status enable bit causes the
+ * hardware to assert the summary interrupt to the CPU if the latched
+ * status bit is set. There's a bug though, the edge detection logic
+ * seems to have a problem where toggling the RAW_STATUS_EN bit may
+ * cause the status bit to latch spuriously when there isn't any edge
+ * so we can't touch that bit for edge type irqs and we have to keep
+ * the bit set anyway so that edges are latched while the line is masked.
+ *
+ * To make matters more complicated, leaving the RAW_STATUS_EN bit
+ * enabled all the time causes level interrupts to re-latch into the
+ * status register because the level is still present on the line after
+ * we ack it. We clear the raw status enable bit during mask here and
+ * set the bit on unmask so the interrupt can't latch into the hardware
+ * while it's masked.
+ */
+ if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
+ val &= ~BIT(g->intr_raw_status_bit);
+
val &= ~BIT(g->intr_enable_bit);
writel(val, pctrl->regs + g->intr_cfg_reg);

@@ -598,6 +621,7 @@ static void msm_gpio_irq_unmask(struct i
spin_lock_irqsave(&pctrl->lock, flags);

val = readl(pctrl->regs + g->intr_cfg_reg);
+ val |= BIT(g->intr_raw_status_bit);
val |= BIT(g->intr_enable_bit);
writel(val, pctrl->regs + g->intr_cfg_reg);




2018-10-08 18:38:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 095/113] RDMA/ucma: check fd type in ucma_migrate_id()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

[ Upstream commit 0d23ba6034b9cf48b8918404367506da3e4b3ee5 ]

The current code grabs the private_data of whatever file descriptor
userspace has supplied and implicitly casts it to a `struct ucma_file *`,
potentially causing a type confusion.

This is probably fine in practice because the pointer is only used for
comparisons, it is never actually dereferenced; and even in the
comparisons, it is unlikely that a file from another filesystem would have
a ->private_data pointer that happens to also be valid in this context.
But ->private_data is not always guaranteed to be a valid pointer to an
object owned by the file's filesystem; for example, some filesystems just
cram numbers in there.

Check the type of the supplied file descriptor to be safe, analogous to how
other places in the kernel do it.

Fixes: 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")
Signed-off-by: Jann Horn <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/core/ucma.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -123,6 +123,8 @@ static DEFINE_MUTEX(mut);
static DEFINE_IDR(ctx_idr);
static DEFINE_IDR(multicast_idr);

+static const struct file_operations ucma_fops;
+
static inline struct ucma_context *_ucma_find_context(int id,
struct ucma_file *file)
{
@@ -1535,6 +1537,10 @@ static ssize_t ucma_migrate_id(struct uc
f = fdget(cmd.fd);
if (!f.file)
return -ENOENT;
+ if (f.file->f_op != &ucma_fops) {
+ ret = -EINVAL;
+ goto file_put;
+ }

/* Validate current fd and prevent destruction of id. */
ctx = ucma_get_ctx(f.file->private_data, cmd.id);



2018-10-08 18:38:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 069/113] hwmon: (adt7475) Make adt7475_read_word() return errors

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit f196dec6d50abb2e65fb54a0621b2f1b4d922995 ]

The adt7475_read_word() function was meant to return negative error
codes on failure.

Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Tokunori Ikegami <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/adt7475.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -274,14 +274,18 @@ static inline u16 volt2reg(int channel,
return clamp_val(reg, 0, 1023) & (0xff << 2);
}

-static u16 adt7475_read_word(struct i2c_client *client, int reg)
+static int adt7475_read_word(struct i2c_client *client, int reg)
{
- u16 val;
+ int val1, val2;

- val = i2c_smbus_read_byte_data(client, reg);
- val |= (i2c_smbus_read_byte_data(client, reg + 1) << 8);
+ val1 = i2c_smbus_read_byte_data(client, reg);
+ if (val1 < 0)
+ return val1;
+ val2 = i2c_smbus_read_byte_data(client, reg + 1);
+ if (val2 < 0)
+ return val2;

- return val;
+ return val1 | (val2 << 8);
}

static void adt7475_write_word(struct i2c_client *client, int reg, u16 val)



2018-10-08 18:38:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 071/113] arm64: cpufeature: Track 32bit EL0 support

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Suzuki K Poulose <[email protected]>

commit 042446a31e3803d81c7e618dd80928dc3dce70c5 upstream.

Add cpu_hwcap bit for keeping track of the support for 32bit EL0.

Tested-by: Yury Norov <[email protected]>
Signed-off-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/cpufeature.h | 8 +++++++-
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kernel/cpufeature.c | 8 ++++++++
3 files changed, 16 insertions(+), 1 deletion(-)

--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -31,8 +31,9 @@
#define ARM64_WORKAROUND_CAVIUM_23154 6
#define ARM64_WORKAROUND_834220 7
#define ARM64_WORKAROUND_CAVIUM_27456 8
+#define ARM64_HAS_32BIT_EL0 9

-#define ARM64_NCAPS 9
+#define ARM64_NCAPS 10

#ifndef __ASSEMBLY__

@@ -180,6 +181,11 @@ static inline bool cpu_supports_mixed_en
return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
}

+static inline bool system_supports_32bit_el0(void)
+{
+ return cpus_have_cap(ARM64_HAS_32BIT_EL0);
+}
+
static inline bool system_supports_mixed_endian_el0(void)
{
return id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -109,6 +109,7 @@
#define ID_AA64PFR0_ASIMD_SUPPORTED 0x0
#define ID_AA64PFR0_EL1_64BIT_ONLY 0x1
#define ID_AA64PFR0_EL0_64BIT_ONLY 0x1
+#define ID_AA64PFR0_EL0_32BIT_64BIT 0x2

/* id_aa64mmfr0 */
#define ID_AA64MMFR0_TGRAN4_SHIFT 28
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -653,6 +653,14 @@ static const struct arm64_cpu_capabiliti
.min_field_value = 2,
},
#endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+ {
+ .desc = "32-bit EL0 Support",
+ .capability = ARM64_HAS_32BIT_EL0,
+ .matches = has_cpuid_feature,
+ .sys_reg = SYS_ID_AA64PFR0_EL1,
+ .field_pos = ID_AA64PFR0_EL0_SHIFT,
+ .min_field_value = ID_AA64PFR0_EL0_32BIT_64BIT,
+ },
{},
};




2018-10-08 18:38:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 070/113] i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

[ Upstream commit 7fd6d98b89f382d414e1db528e29a67bbd749457 ]

Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict
with PCI BAR") made it possible for AML code to access SMBus I/O ports
by installing custom SystemIO OpRegion handler and blocking i80i driver
access upon first AML read/write to this OpRegion.

However, while ThinkPad T560 does have SystemIO OpRegion declared under
the SMBus device, it does not access any of the SMBus registers:

Device (SMBU)
{
...

OperationRegion (SMBP, PCI_Config, 0x50, 0x04)
Field (SMBP, DWordAcc, NoLock, Preserve)
{
, 5,
TCOB, 11,
Offset (0x04)
}

Name (TCBV, 0x00)
Method (TCBS, 0, NotSerialized)
{
If ((TCBV == 0x00))
{
TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05)
}

Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */
}

OperationRegion (TCBA, SystemIO, TCBS (), 0x10)
Field (TCBA, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
, 9,
CPSC, 1
}
}

Problem with the current approach is that it blocks all I/O port access
and because this system has touchpad connected to the SMBus controller
after first AML access (happens during suspend/resume cycle) the
touchpad fails to work anymore.

Fix this so that we allow ACPI AML I/O port access if it does not touch
the region reserved for the SMBus.

Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737
Reported-by: Yussuf Khalil <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-i801.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1272,6 +1272,13 @@ static void i801_add_tco(struct i801_pri
}

#ifdef CONFIG_ACPI
+static bool i801_acpi_is_smbus_ioport(const struct i801_priv *priv,
+ acpi_physical_address address)
+{
+ return address >= priv->smba &&
+ address <= pci_resource_end(priv->pci_dev, SMBBAR);
+}
+
static acpi_status
i801_acpi_io_handler(u32 function, acpi_physical_address address, u32 bits,
u64 *value, void *handler_context, void *region_context)
@@ -1287,7 +1294,7 @@ i801_acpi_io_handler(u32 function, acpi_
*/
mutex_lock(&priv->acpi_lock);

- if (!priv->acpi_reserved) {
+ if (!priv->acpi_reserved && i801_acpi_is_smbus_ioport(priv, address)) {
priv->acpi_reserved = true;

dev_warn(&pdev->dev, "BIOS is accessing SMBus registers\n");



2018-10-08 18:38:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 073/113] media: v4l: event: Prevent freeing event subscriptions while accessed

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sakari Ailus <[email protected]>

commit ad608fbcf166fec809e402d548761768f602702c upstream.

The event subscriptions are added to the subscribed event list while
holding a spinlock, but that lock is subsequently released while still
accessing the subscription object. This makes it possible to unsubscribe
the event --- and freeing the subscription object's memory --- while
the subscription object is simultaneously accessed.

Prevent this by adding a mutex to serialise the event subscription and
unsubscription. This also gives a guarantee to the callback ops that the
add op has returned before the del op is called.

This change also results in making the elems field less special:
subscriptions are only added to the event list once they are fully
initialised.

Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Hans Verkuil <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Cc: [email protected] # for 4.14 and up
Fixes: c3b5b0241f62 ("V4L/DVB: V4L: Events: Add backend")
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/v4l2-core/v4l2-event.c | 37 +++++++++++++++++------------------
drivers/media/v4l2-core/v4l2-fh.c | 2 +
include/media/v4l2-fh.h | 1
3 files changed, 22 insertions(+), 18 deletions(-)

--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -119,14 +119,6 @@ static void __v4l2_event_queue_fh(struct
if (sev == NULL)
return;

- /*
- * If the event has been added to the fh->subscribed list, but its
- * add op has not completed yet elems will be 0, treat this as
- * not being subscribed.
- */
- if (!sev->elems)
- return;
-
/* Increase event sequence number on fh. */
fh->sequence++;

@@ -212,6 +204,7 @@ int v4l2_event_subscribe(struct v4l2_fh
struct v4l2_subscribed_event *sev, *found_ev;
unsigned long flags;
unsigned i;
+ int ret = 0;

if (sub->type == V4L2_EVENT_ALL)
return -EINVAL;
@@ -229,31 +222,36 @@ int v4l2_event_subscribe(struct v4l2_fh
sev->flags = sub->flags;
sev->fh = fh;
sev->ops = ops;
+ sev->elems = elems;
+
+ mutex_lock(&fh->subscribe_lock);

spin_lock_irqsave(&fh->vdev->fh_lock, flags);
found_ev = v4l2_event_subscribed(fh, sub->type, sub->id);
- if (!found_ev)
- list_add(&sev->list, &fh->subscribed);
spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);

if (found_ev) {
+ /* Already listening */
kfree(sev);
- return 0; /* Already listening */
+ goto out_unlock;
}

if (sev->ops && sev->ops->add) {
- int ret = sev->ops->add(sev, elems);
+ ret = sev->ops->add(sev, elems);
if (ret) {
- sev->ops = NULL;
- v4l2_event_unsubscribe(fh, sub);
- return ret;
+ kfree(sev);
+ goto out_unlock;
}
}

- /* Mark as ready for use */
- sev->elems = elems;
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_add(&sev->list, &fh->subscribed);
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);

- return 0;
+out_unlock:
+ mutex_unlock(&fh->subscribe_lock);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(v4l2_event_subscribe);

@@ -292,6 +290,8 @@ int v4l2_event_unsubscribe(struct v4l2_f
return 0;
}

+ mutex_lock(&fh->subscribe_lock);
+
spin_lock_irqsave(&fh->vdev->fh_lock, flags);

sev = v4l2_event_subscribed(fh, sub->type, sub->id);
@@ -310,6 +310,7 @@ int v4l2_event_unsubscribe(struct v4l2_f
sev->ops->del(sev);

kfree(sev);
+ mutex_unlock(&fh->subscribe_lock);

return 0;
}
--- a/drivers/media/v4l2-core/v4l2-fh.c
+++ b/drivers/media/v4l2-core/v4l2-fh.c
@@ -49,6 +49,7 @@ void v4l2_fh_init(struct v4l2_fh *fh, st
INIT_LIST_HEAD(&fh->available);
INIT_LIST_HEAD(&fh->subscribed);
fh->sequence = -1;
+ mutex_init(&fh->subscribe_lock);
}
EXPORT_SYMBOL_GPL(v4l2_fh_init);

@@ -93,6 +94,7 @@ void v4l2_fh_exit(struct v4l2_fh *fh)
if (fh->vdev == NULL)
return;
v4l2_event_unsubscribe_all(fh);
+ mutex_destroy(&fh->subscribe_lock);
fh->vdev = NULL;
}
EXPORT_SYMBOL_GPL(v4l2_fh_exit);
--- a/include/media/v4l2-fh.h
+++ b/include/media/v4l2-fh.h
@@ -43,6 +43,7 @@ struct v4l2_fh {
wait_queue_head_t wait;
struct list_head subscribed; /* Subscribed events */
struct list_head available; /* Dequeueable event */
+ struct mutex subscribe_lock;
unsigned int navailable;
u32 sequence;




2018-10-08 18:38:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 055/113] USB: usbdevfs: restore warning for nonsensical flags

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <[email protected]>

commit 81e0403b26d94360abd1f6a57311337973bc82cd upstream.

If we filter flags before they reach the core we need to generate our
own warnings.

Signed-off-by: Oliver Neukum <[email protected]>
Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/devio.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1535,6 +1535,11 @@ static int proc_do_submiturb(struct usb_
u |= URB_NO_INTERRUPT;
as->urb->transfer_flags = u;

+ if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
+ dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_SHORT_NOT_OK.\n");
+ if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
+ dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_ZERO_PACKET.\n");
+
as->urb->transfer_buffer_length = uurb->buffer_length;
as->urb->setup_packet = (unsigned char *)dr;
dr = NULL;



2018-10-08 18:38:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 080/113] RAID10 BUG_ON in raise_barrier when force is true and conf->barrier is 0

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xiao Ni <[email protected]>

[ Upstream commit 1d0ffd264204eba1861865560f1f7f7a92919384 ]

In raid10 reshape_request it gets max_sectors in read_balance. If the underlayer disks
have bad blocks, the max_sectors is less than last. It will call goto read_more many
times. It calls raise_barrier(conf, sectors_done != 0) every time. In this condition
sectors_done is not 0. So the value passed to the argument force of raise_barrier is
true.

In raise_barrier it checks conf->barrier when force is true. If force is true and
conf->barrier is 0, it panic. In this case reshape_request submits bio to under layer
disks. And in the callback function of the bio it calls lower_barrier. If the bio
finishes before calling raise_barrier again, it can trigger the BUG_ON.

Add one pair of raise_barrier/lower_barrier to fix this bug.

Signed-off-by: Xiao Ni <[email protected]>
Suggested-by: Neil Brown <[email protected]>
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid10.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -4336,11 +4336,12 @@ static sector_t reshape_request(struct m
allow_barrier(conf);
}

+ raise_barrier(conf, 0);
read_more:
/* Now schedule reads for blocks from sector_nr to last */
r10_bio = mempool_alloc(conf->r10buf_pool, GFP_NOIO);
r10_bio->state = 0;
- raise_barrier(conf, sectors_done != 0);
+ raise_barrier(conf, 1);
atomic_set(&r10_bio->remaining, 0);
r10_bio->mddev = mddev;
r10_bio->sector = sector_nr;
@@ -4445,6 +4446,8 @@ bio_full:
if (sector_nr <= last)
goto read_more;

+ lower_barrier(conf);
+
/* Now that we have done the whole section we can
* update reshape_progress
*/



2018-10-08 18:38:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 081/113] i2c: uniphier: issue STOP only for last message or I2C_M_STOP

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Masahiro Yamada <[email protected]>

[ Upstream commit 38f5d8d8cbb2ffa2b54315118185332329ec891c ]

This driver currently emits a STOP if the next message is not
I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR
ioctl, where read/write transactions are combined without STOP
between.

Issue STOP only when the message is the last one _or_ flagged with
I2C_M_STOP.

Fixes: dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver")
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-uniphier.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)

--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -247,11 +247,8 @@ static int uniphier_i2c_master_xfer(stru
return ret;

for (msg = msgs; msg < emsg; msg++) {
- /* If next message is read, skip the stop condition */
- bool stop = !(msg + 1 < emsg && msg[1].flags & I2C_M_RD);
- /* but, force it if I2C_M_STOP is set */
- if (msg->flags & I2C_M_STOP)
- stop = true;
+ /* Emit STOP if it is the last message or I2C_M_STOP is set. */
+ bool stop = (msg + 1 == emsg) || (msg->flags & I2C_M_STOP);

ret = uniphier_i2c_master_xfer_one(adap, msg, stop);
if (ret)



2018-10-08 18:38:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 082/113] i2c: uniphier-f: issue STOP only for last message or I2C_M_STOP

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Masahiro Yamada <[email protected]>

[ Upstream commit 4c85609b08c4761eca0a40fd7beb06bc650f252d ]

This driver currently emits a STOP if the next message is not
I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR
ioctl, where read/write transactions are combined without STOP
between.

Issue STOP only when the message is the last one _or_ flagged with
I2C_M_STOP.

Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/busses/i2c-uniphier-f.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)

--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -394,11 +394,8 @@ static int uniphier_fi2c_master_xfer(str
return ret;

for (msg = msgs; msg < emsg; msg++) {
- /* If next message is read, skip the stop condition */
- bool stop = !(msg + 1 < emsg && msg[1].flags & I2C_M_RD);
- /* but, force it if I2C_M_STOP is set */
- if (msg->flags & I2C_M_STOP)
- stop = true;
+ /* Emit STOP if it is the last message or I2C_M_STOP is set. */
+ bool stop = (msg + 1 == emsg) || (msg->flags & I2C_M_STOP);

ret = uniphier_fi2c_master_xfer_one(adap, msg, stop);
if (ret)



2018-10-08 18:38:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 056/113] Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()"

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sebastian Andrzej Siewior <[email protected]>

commit e871db8d78df1c411032cbb3acfdf8930509360e upstream.

This reverts commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427.

The bug the patch describes to, has been already fixed in commit
2df6948428542 ("USB: cdc-wdm: don't enable interrupts in USB-giveback")
so need to this, revert it.

Fixes: 6e22e3af7bb3 ("usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()")
Cc: stable <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/class/cdc-wdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -453,7 +453,7 @@ static int clear_wdm_read_flag(struct wd

set_bit(WDM_RESPONDING, &desc->flags);
spin_unlock_irq(&desc->iuspin);
- rv = usb_submit_urb(desc->response, GFP_ATOMIC);
+ rv = usb_submit_urb(desc->response, GFP_KERNEL);
spin_lock_irq(&desc->iuspin);
if (rv) {
dev_err(&desc->intf->dev,



2018-10-08 18:38:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 100/113] arch/hexagon: fix kernel/dma.c build warning

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit 200f351e27f014fcbf69b544b0b4b72aeaf45fd3 ]

Fix build warning in arch/hexagon/kernel/dma.c by casting a void *
to unsigned long to match the function parameter type.

../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 'gen_pool_add' makes integer from pointer without a cast [enabled by default]
../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but argument is of type 'void *'

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Patch-mainline: linux-kernel @ 07/20/2018, 20:17
[[email protected]: fixed architecture name]
Signed-off-by: Richard Kuo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/hexagon/kernel/dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/hexagon/kernel/dma.c
+++ b/arch/hexagon/kernel/dma.c
@@ -68,7 +68,7 @@ static void *hexagon_dma_alloc_coherent(
panic("Can't create %s() memory pool!", __func__);
else
gen_pool_add(coherent_pool,
- pfn_to_virt(max_low_pfn),
+ (unsigned long)pfn_to_virt(max_low_pfn),
hexagon_coherent_pool_size, -1);
}




2018-10-08 18:38:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 047/113] spi: sh-msiof: Fix handling of write value for SISTR register

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hiromitsu Yamasaki <[email protected]>

commit 31a5fae4c5a009898da6d177901d5328051641ff upstream.

This patch changes writing to the SISTR register according to the H/W
user's manual.

The TDREQ bit and RDREQ bits of SISTR are read-only, and must be written
their initial values of zero.

Signed-off-by: Hiromitsu Yamasaki <[email protected]>
[geert: reword]
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-sh-msiof.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -374,7 +374,8 @@ static void sh_msiof_spi_set_mode_regs(s

static void sh_msiof_reset_str(struct sh_msiof_spi_priv *p)
{
- sh_msiof_write(p, STR, sh_msiof_read(p, STR));
+ sh_msiof_write(p, STR,
+ sh_msiof_read(p, STR) & ~(STR_TDREQ | STR_RDREQ));
}

static void sh_msiof_spi_write_fifo_8(struct sh_msiof_spi_priv *p,



2018-10-08 18:38:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 112/113] proc: restrict kernel stack dumps to root

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jann Horn <[email protected]>

commit f8a00cef17206ecd1b30d3d9f99e10d9fa707aa7 upstream.

Currently, you can use /proc/self/task/*/stack to cause a stack walk on
a task you control while it is running on another CPU. That means that
the stack can change under the stack walker. The stack walker does
have guards against going completely off the rails and into random
kernel memory, but it can interpret random data from your kernel stack
as instruction pointers and stack pointers. This can cause exposure of
kernel stack contents to userspace.

Restrict the ability to inspect kernel stacks of arbitrary tasks to root
in order to prevent a local attacker from exploiting racy stack unwinding
to leak kernel task stack contents. See the added comment for a longer
rationale.

There don't seem to be any users of this userspace API that can't
gracefully bail out if reading from the file fails. Therefore, I believe
that this change is unlikely to break things. In the case that this patch
does end up needing a revert, the next-best solution might be to fake a
single-entry stack based on wchan.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 2ec220e27f50 ("proc: add /proc/*/stack")
Signed-off-by: Jann Horn <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: Ken Chen <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Laura Abbott <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: "H . Peter Anvin" <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/proc/base.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -471,6 +471,20 @@ static int proc_pid_stack(struct seq_fil
int err;
int i;

+ /*
+ * The ability to racily run the kernel stack unwinder on a running task
+ * and then observe the unwinder output is scary; while it is useful for
+ * debugging kernel issues, it can also allow an attacker to leak kernel
+ * stack contents.
+ * Doing this in a manner that is at least safe from races would require
+ * some work to ensure that the remote task can not be scheduled; and
+ * even then, this would still expose the unwinder as local attack
+ * surface.
+ * Therefore, this interface is restricted to root.
+ */
+ if (!file_ns_capable(m->file, &init_user_ns, CAP_SYS_ADMIN))
+ return -EACCES;
+
entries = kmalloc(MAX_STACK_TRACE_DEPTH * sizeof(*entries), GFP_KERNEL);
if (!entries)
return -ENOMEM;



2018-10-08 18:38:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 074/113] KVM: PPC: Book3S HV: Dont truncate HPTE index in xlate function

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Mackerras <[email protected]>

[ Upstream commit 46dec40fb741f00f1864580130779aeeaf24fb3d ]

This fixes a bug which causes guest virtual addresses to get translated
to guest real addresses incorrectly when the guest is using the HPT MMU
and has more than 256GB of RAM, or more specifically has a HPT larger
than 2GB. This has showed up in testing as a failure of the host to
emulate doorbell instructions correctly on POWER9 for HPT guests with
more than 256GB of RAM.

The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate()
is stored as an int, and in forming the HPTE address, the index gets
shifted left 4 bits as an int before being signed-extended to 64 bits.
The simple fix is to make the variable a long int, matching the
return type of kvmppc_hv_find_lock_hpte(), which is what calculates
the index.

Fixes: 697d3899dcb4 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests")
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -314,7 +314,7 @@ static int kvmppc_mmu_book3s_64_hv_xlate
unsigned long pp, key;
unsigned long v, gr;
__be64 *hptep;
- int index;
+ long int index;
int virtmode = vcpu->arch.shregs.msr & (data ? MSR_DR : MSR_IR);

/* Get SLB entry */



2018-10-08 18:38:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 088/113] mac80211: shorten the IBSS debug messages

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Emmanuel Grumbach <[email protected]>

[ Upstream commit c6e57b3896fc76299913b8cfd82d853bee8a2c84 ]

When tracing is enabled, all the debug messages are recorded and must
not exceed MAX_MSG_LEN (100) columns. Longer debug messages grant the
user with:

WARNING: CPU: 3 PID: 32642 at /tmp/wifi-core-20180806094828/src/iwlwifi-stack-dev/net/mac80211/./trace_msg.h:32 trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
Workqueue: phy1 ieee80211_iface_work [mac80211]
RIP: 0010:trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
Call Trace:
__sdata_dbg+0xbd/0x120 [mac80211]
ieee80211_ibss_rx_queued_mgmt+0x15f/0x510 [mac80211]
ieee80211_iface_work+0x21d/0x320 [mac80211]

Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/ibss.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)

--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -948,8 +948,8 @@ static void ieee80211_rx_mgmt_deauth_ibs
if (len < IEEE80211_DEAUTH_FRAME_LEN)
return;

- ibss_dbg(sdata, "RX DeAuth SA=%pM DA=%pM BSSID=%pM (reason: %d)\n",
- mgmt->sa, mgmt->da, mgmt->bssid, reason);
+ ibss_dbg(sdata, "RX DeAuth SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
+ ibss_dbg(sdata, "\tBSSID=%pM (reason: %d)\n", mgmt->bssid, reason);
sta_info_destroy_addr(sdata, mgmt->sa);
}

@@ -967,9 +967,9 @@ static void ieee80211_rx_mgmt_auth_ibss(
auth_alg = le16_to_cpu(mgmt->u.auth.auth_alg);
auth_transaction = le16_to_cpu(mgmt->u.auth.auth_transaction);

- ibss_dbg(sdata,
- "RX Auth SA=%pM DA=%pM BSSID=%pM (auth_transaction=%d)\n",
- mgmt->sa, mgmt->da, mgmt->bssid, auth_transaction);
+ ibss_dbg(sdata, "RX Auth SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
+ ibss_dbg(sdata, "\tBSSID=%pM (auth_transaction=%d)\n",
+ mgmt->bssid, auth_transaction);

if (auth_alg != WLAN_AUTH_OPEN || auth_transaction != 1)
return;
@@ -1174,10 +1174,10 @@ static void ieee80211_rx_bss_info(struct
rx_timestamp = drv_get_tsf(local, sdata);
}

- ibss_dbg(sdata,
- "RX beacon SA=%pM BSSID=%pM TSF=0x%llx BCN=0x%llx diff=%lld @%lu\n",
+ ibss_dbg(sdata, "RX beacon SA=%pM BSSID=%pM TSF=0x%llx\n",
mgmt->sa, mgmt->bssid,
- (unsigned long long)rx_timestamp,
+ (unsigned long long)rx_timestamp);
+ ibss_dbg(sdata, "\tBCN=0x%llx diff=%lld @%lu\n",
(unsigned long long)beacon_timestamp,
(unsigned long long)(rx_timestamp - beacon_timestamp),
jiffies);
@@ -1536,9 +1536,9 @@ static void ieee80211_rx_mgmt_probe_req(

tx_last_beacon = drv_tx_last_beacon(local);

- ibss_dbg(sdata,
- "RX ProbeReq SA=%pM DA=%pM BSSID=%pM (tx_last_beacon=%d)\n",
- mgmt->sa, mgmt->da, mgmt->bssid, tx_last_beacon);
+ ibss_dbg(sdata, "RX ProbeReq SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
+ ibss_dbg(sdata, "\tBSSID=%pM (tx_last_beacon=%d)\n",
+ mgmt->bssid, tx_last_beacon);

if (!tx_last_beacon && is_multicast_ether_addr(mgmt->da))
return;



2018-10-08 18:38:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 102/113] arm64: jump_label.h: use asm_volatile_goto macro instead of "asm goto"

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miguel Ojeda <[email protected]>

[ Upstream commit 13aceef06adfaf93d52e01e28a8bc8a0ad471d83 ]

All other uses of "asm goto" go through asm_volatile_goto, which avoids
a miscompile when using GCC < 4.8.2. Replace our open-coded "asm goto"
statements with the asm_volatile_goto macro to avoid issues with older
toolchains.

Cc: Catalin Marinas <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/jump_label.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm64/include/asm/jump_label.h
+++ b/arch/arm64/include/asm/jump_label.h
@@ -28,7 +28,7 @@

static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
{
- asm goto("1: nop\n\t"
+ asm_volatile_goto("1: nop\n\t"
".pushsection __jump_table, \"aw\"\n\t"
".align 3\n\t"
".quad 1b, %l[l_yes], %c0\n\t"
@@ -42,7 +42,7 @@ l_yes:

static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
{
- asm goto("1: b %l[l_yes]\n\t"
+ asm_volatile_goto("1: b %l[l_yes]\n\t"
".pushsection __jump_table, \"aw\"\n\t"
".align 3\n\t"
".quad 1b, %l[l_yes], %c0\n\t"



2018-10-08 18:38:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 106/113] xen/manage: dont complain about an empty value in control/sysrq node

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vitaly Kuznetsov <[email protected]>

[ Upstream commit 87dffe86d406bee8782cac2db035acb9a28620a7 ]

When guest receives a sysrq request from the host it acknowledges it by
writing '\0' to control/sysrq xenstore node. This, however, make xenstore
watch fire again but xenbus_scanf() fails to parse empty value with "%c"
format string:

sysrq: SysRq : Emergency Sync
Emergency Sync complete
xen:manage: Error -34 reading sysrq code in control/sysrq

Ignore -ERANGE the same way we already ignore -ENOENT, empty value in
control/sysrq is totally legal.

Signed-off-by: Vitaly Kuznetsov <[email protected]>
Reviewed-by: Wei Liu <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/manage.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -280,9 +280,11 @@ static void sysrq_handler(struct xenbus_
/*
* The Xenstore watch fires directly after registering it and
* after a suspend/resume cycle. So ENOENT is no error but
- * might happen in those cases.
+ * might happen in those cases. ERANGE is observed when we get
+ * an empty value (''), this happens when we acknowledge the
+ * request by writing '\0' below.
*/
- if (err != -ENOENT)
+ if (err != -ENOENT && err != -ERANGE)
pr_err("Error %d reading sysrq code in control/sysrq\n",
err);
xenbus_transaction_end(xbt, 1);



2018-10-08 18:39:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 076/113] mac80211_hwsim: correct use of IEEE80211_VHT_CAP_RXSTBC_X

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Danek Duvall <[email protected]>

[ Upstream commit d7c863a2f65e48f442379f4ee1846d52e0c5d24d ]

The mac80211_hwsim driver intends to say that it supports up to four
STBC receive streams, but instead it ends up saying something undefined.
The IEEE80211_VHT_CAP_RXSTBC_X macros aren't independent bits that can
be ORed together, but values. In this case, _4 is the appropriate one
to use.

Signed-off-by: Danek Duvall <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/mac80211_hwsim.c | 3 ---
1 file changed, 3 deletions(-)

--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2453,9 +2453,6 @@ static int mac80211_hwsim_new_radio(stru
IEEE80211_VHT_CAP_SHORT_GI_80 |
IEEE80211_VHT_CAP_SHORT_GI_160 |
IEEE80211_VHT_CAP_TXSTBC |
- IEEE80211_VHT_CAP_RXSTBC_1 |
- IEEE80211_VHT_CAP_RXSTBC_2 |
- IEEE80211_VHT_CAP_RXSTBC_3 |
IEEE80211_VHT_CAP_RXSTBC_4 |
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK;
sband->vht_cap.vht_mcs.rx_mcs_map =



2018-10-08 18:39:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 094/113] perf probe powerpc: Ignore SyS symbols irrespective of endianness

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sandipan Das <[email protected]>

[ Upstream commit fa694160cca6dbba17c57dc7efec5f93feaf8795 ]

This makes sure that the SyS symbols are ignored for any powerpc system,
not just the big endian ones.

Reported-by: Naveen N. Rao <[email protected]>
Signed-off-by: Sandipan Das <[email protected]>
Reviewed-by: Kamalesh Babulal <[email protected]>
Acked-by: Naveen N. Rao <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Ravi Bangoria <[email protected]>
Fixes: fb6d59423115 ("perf probe ppc: Use the right prefix when ignoring SyS symbols on ppc")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/perf/arch/powerpc/util/sym-handling.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -27,15 +27,16 @@ void arch__elf_sym_adjust(GElf_Sym *sym)
#endif
#endif

-#if !defined(_CALL_ELF) || _CALL_ELF != 2
int arch__choose_best_symbol(struct symbol *syma,
struct symbol *symb __maybe_unused)
{
char *sym = syma->name;

+#if !defined(_CALL_ELF) || _CALL_ELF != 2
/* Skip over any initial dot */
if (*sym == '.')
sym++;
+#endif

/* Avoid "SyS" kernel syscall aliases */
if (strlen(sym) >= 3 && !strncmp(sym, "SyS", 3))
@@ -46,6 +47,7 @@ int arch__choose_best_symbol(struct symb
return SYMBOL_A;
}

+#if !defined(_CALL_ELF) || _CALL_ELF != 2
/* Allow matching against dot variants */
int arch__compare_symbol_names(const char *namea, const char *nameb)
{



2018-10-08 18:39:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 096/113] USB: yurex: Check for truncation in yurex_read()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Hutchings <[email protected]>

[ Upstream commit 14427b86837a4baf1c121934c6599bdb67dfa9fc ]

snprintf() always returns the full length of the string it could have
printed, even if it was truncated because the buffer was too small.
So in case the counter value is truncated, we will over-read from
in_buffer and over-write to the caller's buffer.

I don't think it's actually possible for this to happen, but in case
truncation occurs, WARN and return -EIO.

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/misc/yurex.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -431,6 +431,9 @@ static ssize_t yurex_read(struct file *f
spin_unlock_irqrestore(&dev->lock, flags);
mutex_unlock(&dev->io_mutex);

+ if (WARN_ON_ONCE(len >= sizeof(in_buffer)))
+ return -EIO;
+
return simple_read_from_buffer(buffer, count, ppos, in_buffer, len);
}




2018-10-08 18:39:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 098/113] fs/cifs: suppress a string overflow warning

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stephen Rothwell <[email protected]>

[ Upstream commit bcfb84a996f6fa90b5e6e2954b2accb7a4711097 ]

A powerpc build of cifs with gcc v8.2.0 produces this warning:

fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since we are already doing a strlen() on the source, change the strncpy
to a memcpy().

Signed-off-by: Stephen Rothwell <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/cifssmb.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -577,10 +577,15 @@ CIFSSMBNegotiate(const unsigned int xid,
}

count = 0;
+ /*
+ * We know that all the name entries in the protocols array
+ * are short (< 16 bytes anyway) and are NUL terminated.
+ */
for (i = 0; i < CIFS_NUM_PROT; i++) {
- strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
- count += strlen(protocols[i].name) + 1;
- /* null at end of source and target buffers anyway */
+ size_t len = strlen(protocols[i].name) + 1;
+
+ memcpy(pSMB->DialectsArray+count, protocols[i].name, len);
+ count += len;
}
inc_rfc1001_len(pSMB, count);
pSMB->ByteCount = cpu_to_le16(count);



2018-10-08 18:39:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 110/113] ALSA: hda/realtek - Cannot adjust speakers volume on Dell XPS 27 7760

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kai-Heng Feng <[email protected]>

commit 709ae62e8e6d9ac4df7dadb3b8ae432675c45ef9 upstream.

The issue is the same as commit dd9aa335c880 ("ALSA: hda/realtek - Can't
adjust speaker's volume on a Dell AIO"), the output requires to connect
to a node with Amp-out capability.

Applying the same fixup ALC298_FIXUP_SPK_VOLUME can fix the issue.

BugLink: https://bugs.launchpad.net/bugs/1775068
Signed-off-by: Kai-Heng Feng <[email protected]>
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5642,6 +5642,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x0706, "Dell Inspiron 7559", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", ALC255_FIXUP_DELL_SPK_NOISE),
SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x075c, "Dell XPS 27 7760", ALC298_FIXUP_SPK_VOLUME),
SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
SND_PCI_QUIRK(0x1028, 0x07b0, "Dell Precision 7520", ALC295_FIXUP_DISABLE_DAC3),
SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),



2018-10-08 18:39:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 111/113] crypto: mxs-dcp - Fix wait logic on chan threads

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Leonard Crestez <[email protected]>

commit d80771c08363ad7fbf0f56f5301e7ca65065c582 upstream.

When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver
prints warnings such as:

WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c
do not call blocking ops when !TASK_RUNNING; state=1 set at [<8081978c>] dcp_chan_thread_sha+0x3c/0x2ec

The problem is that blocking ops will manipulate current->state
themselves so it is not allowed to call them between
set_current_state(TASK_INTERRUPTIBLE) and schedule().

Fix this by converting the per-chan mutex to a spinlock (it only
protects tiny list ops anyway) and rearranging the wait logic so that
callbacks are called current->state as TASK_RUNNING. Those callbacks
will indeed call blocking ops themselves so this is required.

Cc: <[email protected]>
Signed-off-by: Leonard Crestez <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/crypto/mxs-dcp.c | 53 ++++++++++++++++++++++++++---------------------
1 file changed, 30 insertions(+), 23 deletions(-)

--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -63,7 +63,7 @@ struct dcp {
struct dcp_coherent_block *coh;

struct completion completion[DCP_MAX_CHANS];
- struct mutex mutex[DCP_MAX_CHANS];
+ spinlock_t lock[DCP_MAX_CHANS];
struct task_struct *thread[DCP_MAX_CHANS];
struct crypto_queue queue[DCP_MAX_CHANS];
};
@@ -349,13 +349,20 @@ static int dcp_chan_thread_aes(void *dat

int ret;

- do {
- __set_current_state(TASK_INTERRUPTIBLE);
+ while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);

- mutex_lock(&sdcp->mutex[chan]);
+ spin_lock(&sdcp->lock[chan]);
backlog = crypto_get_backlog(&sdcp->queue[chan]);
arq = crypto_dequeue_request(&sdcp->queue[chan]);
- mutex_unlock(&sdcp->mutex[chan]);
+ spin_unlock(&sdcp->lock[chan]);
+
+ if (!backlog && !arq) {
+ schedule();
+ continue;
+ }
+
+ set_current_state(TASK_RUNNING);

if (backlog)
backlog->complete(backlog, -EINPROGRESS);
@@ -363,11 +370,8 @@ static int dcp_chan_thread_aes(void *dat
if (arq) {
ret = mxs_dcp_aes_block_crypt(arq);
arq->complete(arq, ret);
- continue;
}
-
- schedule();
- } while (!kthread_should_stop());
+ }

return 0;
}
@@ -407,9 +411,9 @@ static int mxs_dcp_aes_enqueue(struct ab
rctx->ecb = ecb;
actx->chan = DCP_CHAN_CRYPTO;

- mutex_lock(&sdcp->mutex[actx->chan]);
+ spin_lock(&sdcp->lock[actx->chan]);
ret = crypto_enqueue_request(&sdcp->queue[actx->chan], &req->base);
- mutex_unlock(&sdcp->mutex[actx->chan]);
+ spin_unlock(&sdcp->lock[actx->chan]);

wake_up_process(sdcp->thread[actx->chan]);

@@ -645,13 +649,20 @@ static int dcp_chan_thread_sha(void *dat
struct ahash_request *req;
int ret, fini;

- do {
- __set_current_state(TASK_INTERRUPTIBLE);
+ while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);

- mutex_lock(&sdcp->mutex[chan]);
+ spin_lock(&sdcp->lock[chan]);
backlog = crypto_get_backlog(&sdcp->queue[chan]);
arq = crypto_dequeue_request(&sdcp->queue[chan]);
- mutex_unlock(&sdcp->mutex[chan]);
+ spin_unlock(&sdcp->lock[chan]);
+
+ if (!backlog && !arq) {
+ schedule();
+ continue;
+ }
+
+ set_current_state(TASK_RUNNING);

if (backlog)
backlog->complete(backlog, -EINPROGRESS);
@@ -663,12 +674,8 @@ static int dcp_chan_thread_sha(void *dat
ret = dcp_sha_req_to_buf(arq);
fini = rctx->fini;
arq->complete(arq, ret);
- if (!fini)
- continue;
}
-
- schedule();
- } while (!kthread_should_stop());
+ }

return 0;
}
@@ -726,9 +733,9 @@ static int dcp_sha_update_fx(struct ahas
rctx->init = 1;
}

- mutex_lock(&sdcp->mutex[actx->chan]);
+ spin_lock(&sdcp->lock[actx->chan]);
ret = crypto_enqueue_request(&sdcp->queue[actx->chan], &req->base);
- mutex_unlock(&sdcp->mutex[actx->chan]);
+ spin_unlock(&sdcp->lock[actx->chan]);

wake_up_process(sdcp->thread[actx->chan]);
mutex_unlock(&actx->mutex);
@@ -984,7 +991,7 @@ static int mxs_dcp_probe(struct platform
platform_set_drvdata(pdev, sdcp);

for (i = 0; i < DCP_MAX_CHANS; i++) {
- mutex_init(&sdcp->mutex[i]);
+ spin_lock_init(&sdcp->lock[i]);
init_completion(&sdcp->completion[i]);
crypto_init_queue(&sdcp->queue[i], 50);
}



2018-10-08 18:39:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 113/113] ocfs2: fix locking for res->tracking and dlm->tracking_list

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ashish Samant <[email protected]>

commit cbe355f57c8074bc4f452e5b6e35509044c6fa23 upstream.

In dlm_init_lockres() we access and modify res->tracking and
dlm->tracking_list without holding dlm->track_lock. This can cause list
corruptions and can end up in kernel panic.

Fix this by locking res->tracking and dlm->tracking_list with
dlm->track_lock instead of dlm->spinlock.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ashish Samant <[email protected]>
Reviewed-by: Changwei Ge <[email protected]>
Acked-by: Joseph Qi <[email protected]>
Acked-by: Jun Piao <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Changwei Ge <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ocfs2/dlm/dlmmaster.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ocfs2/dlm/dlmmaster.c
+++ b/fs/ocfs2/dlm/dlmmaster.c
@@ -589,9 +589,9 @@ static void dlm_init_lockres(struct dlm_

res->last_used = 0;

- spin_lock(&dlm->spinlock);
+ spin_lock(&dlm->track_lock);
list_add_tail(&res->tracking, &dlm->tracking_list);
- spin_unlock(&dlm->spinlock);
+ spin_unlock(&dlm->track_lock);

memset(res->lvb, 0, DLM_LVB_LEN);
memset(res->refmap, 0, sizeof(res->refmap));



2018-10-08 18:39:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 101/113] hexagon: modify ffs() and fls() to return int

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit 5c41aaad409c097cf1ef74f2c649fed994744ef5 ]

Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a
printk format build warning. This is due to hexagon's ffs() being
coded as returning long instead of int.

Fix the printk format warning by changing all of hexagon's ffs() and
fls() functions to return int instead of long. The variables that
they return are already int instead of long. This return type
matches the return type in <asm-generic/bitops/>.

../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]

There are no ffs() or fls() allmodconfig build errors after making this
change.

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Richard Kuo <[email protected]>
Cc: [email protected]
Cc: Geert Uytterhoeven <[email protected]>
Patch-mainline: linux-kernel @ 07/22/2018, 16:03
Signed-off-by: Richard Kuo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/hexagon/include/asm/bitops.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/hexagon/include/asm/bitops.h
+++ b/arch/hexagon/include/asm/bitops.h
@@ -211,7 +211,7 @@ static inline long ffz(int x)
* This is defined the same way as ffs.
* Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
*/
-static inline long fls(int x)
+static inline int fls(int x)
{
int r;

@@ -232,7 +232,7 @@ static inline long fls(int x)
* the libc and compiler builtin ffs routines, therefore
* differs in spirit from the above ffz (man ffs).
*/
-static inline long ffs(int x)
+static inline int ffs(int x)
{
int r;




2018-10-08 18:40:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 105/113] cifs: read overflow in is_valid_oplock_break()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <[email protected]>

[ Upstream commit 097f5863b1a0c9901f180bbd56ae7d630655faaa ]

We need to verify that the "data_offset" is within bounds.

Reported-by: Dr Silvio Cesare of InfoSect <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Steve French <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/misc.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -406,9 +406,17 @@ is_valid_oplock_break(char *buffer, stru
(struct smb_com_transaction_change_notify_rsp *)buf;
struct file_notify_information *pnotify;
__u32 data_offset = 0;
+ size_t len = srv->total_read - sizeof(pSMBr->hdr.smb_buf_length);
+
if (get_bcc(buf) > sizeof(struct file_notify_information)) {
data_offset = le32_to_cpu(pSMBr->DataOffset);

+ if (data_offset >
+ len - sizeof(struct file_notify_information)) {
+ cifs_dbg(FYI, "invalid data_offset %u\n",
+ data_offset);
+ return true;
+ }
pnotify = (struct file_notify_information *)
((char *)&pSMBr->hdr.Protocol + data_offset);
cifs_dbg(FYI, "dnotify on %s Action: 0x%x\n",



2018-10-08 18:40:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 107/113] xen: avoid crash in disable_hotplug_cpu

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Olaf Hering <[email protected]>

[ Upstream commit 3366cdb6d350d95466ee430ac50f3c8415ca8f46 ]

The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:

BUG: unable to handle kernel NULL pointer dereference at 00000000000002d8
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-default #1 openSUSE Tumbleweed (unreleased)
Hardware name: Intel Corporation S5520UR/S5520UR, BIOS S5500.86B.01.00.0050.050620101605 05/06/2010
RIP: e030:device_offline+0x9/0xb0
Code: 77 24 00 e9 ce fe ff ff 48 8b 13 e9 68 ff ff ff 48 8b 13 e9 29 ff ff ff 48 8b 13 e9 ea fe ff ff 90 66 66 66 66 90 41 54 55 53 <f6> 87 d8 02 00 00 01 0f 85 88 00 00 00 48 c7 c2 20 09 60 81 31 f6
RSP: e02b:ffffc90040f27e80 EFLAGS: 00010203
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff8801f3800000 RSI: ffffc90040f27e70 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffff820e47b3 R09: 0000000000000000
R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffffff822e6d30
R13: dead000000000200 R14: dead000000000100 R15: ffffffff8158b4e0
FS: 00007ffa595158c0(0000) GS:ffff8801f39c0000(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000002d8 CR3: 00000001d9602000 CR4: 0000000000002660
Call Trace:
handle_vcpu_hotplug_event+0xb5/0xc0
xenwatch_thread+0x80/0x140
? wait_woken+0x80/0x80
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x40/0x40
ret_from_fork+0x3a/0x50

This happens because handle_vcpu_hotplug_event is called twice. In the
first iteration cpu_present is still true, in the second iteration
cpu_present is false which causes get_cpu_device to return NULL.
In case of cpu#0, cpu_online is apparently always true.

Fix this crash by checking if the cpu can be hotplugged, which is false
for a cpu that was just removed.

Also check if the cpu was actually offlined by device_remove, otherwise
leave the cpu_present state as it is.

Rearrange to code to do all work with device_hotplug_lock held.

Signed-off-by: Olaf Hering <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/cpu_hotplug.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)

--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -18,15 +18,16 @@ static void enable_hotplug_cpu(int cpu)

static void disable_hotplug_cpu(int cpu)
{
- if (cpu_online(cpu)) {
- lock_device_hotplug();
+ if (!cpu_is_hotpluggable(cpu))
+ return;
+ lock_device_hotplug();
+ if (cpu_online(cpu))
device_offline(get_cpu_device(cpu));
- unlock_device_hotplug();
- }
- if (cpu_present(cpu))
+ if (!cpu_online(cpu) && cpu_present(cpu)) {
xen_arch_unregister_cpu(cpu);
-
- set_cpu_present(cpu, false);
+ set_cpu_present(cpu, false);
+ }
+ unlock_device_hotplug();
}

static int vcpu_online(unsigned int cpu)



2018-10-08 19:14:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 099/113] dm thin metadata: try to avoid ever aborting transactions

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joe Thornber <[email protected]>

[ Upstream commit 3ab91828166895600efd9cdc3a0eb32001f7204a ]

Committing a transaction can consume some metadata of it's own, we now
reserve a small amount of metadata to cover this. Free metadata
reported by the kernel will not include this reserve.

If any of the reserve has been used after a commit we enter a new
internal state PM_OUT_OF_METADATA_SPACE. This is reported as
PM_READ_ONLY, so no userland changes are needed. If the metadata
device is resized the pool will move back to PM_WRITE.

These changes mean we never need to abort and rollback a transaction due
to running out of metadata space. This is particularly important
because there have been a handful of reports of data corruption against
DM thin-provisioning that can all be attributed to the thin-pool having
ran out of metadata space.

Signed-off-by: Joe Thornber <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/dm-thin-metadata.c | 36 ++++++++++++++++++++
drivers/md/dm-thin.c | 73 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 100 insertions(+), 9 deletions(-)

--- a/drivers/md/dm-thin-metadata.c
+++ b/drivers/md/dm-thin-metadata.c
@@ -190,6 +190,12 @@ struct dm_pool_metadata {
sector_t data_block_size;

/*
+ * We reserve a section of the metadata for commit overhead.
+ * All reported space does *not* include this.
+ */
+ dm_block_t metadata_reserve;
+
+ /*
* Set if a transaction has to be aborted but the attempt to roll back
* to the previous (good) transaction failed. The only pool metadata
* operation possible in this state is the closing of the device.
@@ -827,6 +833,22 @@ static int __commit_transaction(struct d
return dm_tm_commit(pmd->tm, sblock);
}

+static void __set_metadata_reserve(struct dm_pool_metadata *pmd)
+{
+ int r;
+ dm_block_t total;
+ dm_block_t max_blocks = 4096; /* 16M */
+
+ r = dm_sm_get_nr_blocks(pmd->metadata_sm, &total);
+ if (r) {
+ DMERR("could not get size of metadata device");
+ pmd->metadata_reserve = max_blocks;
+ } else {
+ sector_div(total, 10);
+ pmd->metadata_reserve = min(max_blocks, total);
+ }
+}
+
struct dm_pool_metadata *dm_pool_metadata_open(struct block_device *bdev,
sector_t data_block_size,
bool format_device)
@@ -860,6 +882,8 @@ struct dm_pool_metadata *dm_pool_metadat
return ERR_PTR(r);
}

+ __set_metadata_reserve(pmd);
+
return pmd;
}

@@ -1763,6 +1787,13 @@ int dm_pool_get_free_metadata_block_coun
down_read(&pmd->root_lock);
if (!pmd->fail_io)
r = dm_sm_get_nr_free(pmd->metadata_sm, result);
+
+ if (!r) {
+ if (*result < pmd->metadata_reserve)
+ *result = 0;
+ else
+ *result -= pmd->metadata_reserve;
+ }
up_read(&pmd->root_lock);

return r;
@@ -1875,8 +1906,11 @@ int dm_pool_resize_metadata_dev(struct d
int r = -EINVAL;

down_write(&pmd->root_lock);
- if (!pmd->fail_io)
+ if (!pmd->fail_io) {
r = __resize_space_map(pmd->metadata_sm, new_count);
+ if (!r)
+ __set_metadata_reserve(pmd);
+ }
up_write(&pmd->root_lock);

return r;
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -200,7 +200,13 @@ struct dm_thin_new_mapping;
enum pool_mode {
PM_WRITE, /* metadata may be changed */
PM_OUT_OF_DATA_SPACE, /* metadata may be changed, though data may not be allocated */
+
+ /*
+ * Like READ_ONLY, except may switch back to WRITE on metadata resize. Reported as READ_ONLY.
+ */
+ PM_OUT_OF_METADATA_SPACE,
PM_READ_ONLY, /* metadata may not be changed */
+
PM_FAIL, /* all I/O fails */
};

@@ -1301,7 +1307,35 @@ static void set_pool_mode(struct pool *p

static void requeue_bios(struct pool *pool);

-static void check_for_space(struct pool *pool)
+static bool is_read_only_pool_mode(enum pool_mode mode)
+{
+ return (mode == PM_OUT_OF_METADATA_SPACE || mode == PM_READ_ONLY);
+}
+
+static bool is_read_only(struct pool *pool)
+{
+ return is_read_only_pool_mode(get_pool_mode(pool));
+}
+
+static void check_for_metadata_space(struct pool *pool)
+{
+ int r;
+ const char *ooms_reason = NULL;
+ dm_block_t nr_free;
+
+ r = dm_pool_get_free_metadata_block_count(pool->pmd, &nr_free);
+ if (r)
+ ooms_reason = "Could not get free metadata blocks";
+ else if (!nr_free)
+ ooms_reason = "No free metadata blocks";
+
+ if (ooms_reason && !is_read_only(pool)) {
+ DMERR("%s", ooms_reason);
+ set_pool_mode(pool, PM_OUT_OF_METADATA_SPACE);
+ }
+}
+
+static void check_for_data_space(struct pool *pool)
{
int r;
dm_block_t nr_free;
@@ -1327,14 +1361,16 @@ static int commit(struct pool *pool)
{
int r;

- if (get_pool_mode(pool) >= PM_READ_ONLY)
+ if (get_pool_mode(pool) >= PM_OUT_OF_METADATA_SPACE)
return -EINVAL;

r = dm_pool_commit_metadata(pool->pmd);
if (r)
metadata_operation_failed(pool, "dm_pool_commit_metadata", r);
- else
- check_for_space(pool);
+ else {
+ check_for_metadata_space(pool);
+ check_for_data_space(pool);
+ }

return r;
}
@@ -1400,6 +1436,19 @@ static int alloc_data_block(struct thin_
return r;
}

+ r = dm_pool_get_free_metadata_block_count(pool->pmd, &free_blocks);
+ if (r) {
+ metadata_operation_failed(pool, "dm_pool_get_free_metadata_block_count", r);
+ return r;
+ }
+
+ if (!free_blocks) {
+ /* Let's commit before we use up the metadata reserve. */
+ r = commit(pool);
+ if (r)
+ return r;
+ }
+
return 0;
}

@@ -1431,6 +1480,7 @@ static int should_error_unserviceable_bi
case PM_OUT_OF_DATA_SPACE:
return pool->pf.error_if_no_space ? -ENOSPC : 0;

+ case PM_OUT_OF_METADATA_SPACE:
case PM_READ_ONLY:
case PM_FAIL:
return -EIO;
@@ -2401,8 +2451,9 @@ static void set_pool_mode(struct pool *p
error_retry_list(pool);
break;

+ case PM_OUT_OF_METADATA_SPACE:
case PM_READ_ONLY:
- if (old_mode != new_mode)
+ if (!is_read_only_pool_mode(old_mode))
notify_of_pool_mode_change(pool, "read-only");
dm_pool_metadata_read_only(pool->pmd);
pool->process_bio = process_bio_read_only;
@@ -3333,6 +3384,10 @@ static int maybe_resize_metadata_dev(str
DMINFO("%s: growing the metadata device from %llu to %llu blocks",
dm_device_name(pool->pool_md),
sb_metadata_dev_size, metadata_dev_size);
+
+ if (get_pool_mode(pool) == PM_OUT_OF_METADATA_SPACE)
+ set_pool_mode(pool, PM_WRITE);
+
r = dm_pool_resize_metadata_dev(pool->pmd, metadata_dev_size);
if (r) {
metadata_operation_failed(pool, "dm_pool_resize_metadata_dev", r);
@@ -3636,7 +3691,7 @@ static int pool_message(struct dm_target
struct pool_c *pt = ti->private;
struct pool *pool = pt->pool;

- if (get_pool_mode(pool) >= PM_READ_ONLY) {
+ if (get_pool_mode(pool) >= PM_OUT_OF_METADATA_SPACE) {
DMERR("%s: unable to service pool target messages in READ_ONLY or FAIL mode",
dm_device_name(pool->pool_md));
return -EOPNOTSUPP;
@@ -3710,6 +3765,7 @@ static void pool_status(struct dm_target
dm_block_t nr_blocks_data;
dm_block_t nr_blocks_metadata;
dm_block_t held_root;
+ enum pool_mode mode;
char buf[BDEVNAME_SIZE];
char buf2[BDEVNAME_SIZE];
struct pool_c *pt = ti->private;
@@ -3780,9 +3836,10 @@ static void pool_status(struct dm_target
else
DMEMIT("- ");

- if (pool->pf.mode == PM_OUT_OF_DATA_SPACE)
+ mode = get_pool_mode(pool);
+ if (mode == PM_OUT_OF_DATA_SPACE)
DMEMIT("out_of_data_space ");
- else if (pool->pf.mode == PM_READ_ONLY)
+ else if (is_read_only_pool_mode(mode))
DMEMIT("ro ");
else
DMEMIT("rw ");



2018-10-08 19:14:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 108/113] xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Josh Abraham <[email protected]>

[ Upstream commit 4dca864b59dd150a221730775e2f21f49779c135 ]

This patch removes duplicate macro useage in events_base.c.

It also fixes gcc warning:
variable ‘col’ set but not used [-Wunused-but-set-variable]

Signed-off-by: Joshua Abraham <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/xen/events/events_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -139,7 +139,7 @@ static int set_evtchn_to_irq(unsigned ev
clear_evtchn_to_irq_row(row);
}

- evtchn_to_irq[EVTCHN_ROW(evtchn)][EVTCHN_COL(evtchn)] = irq;
+ evtchn_to_irq[row][col] = irq;
return 0;
}




2018-10-08 19:14:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 103/113] r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kai-Heng Feng <[email protected]>

[ Upstream commit 6ad569019999300afd8e614d296fdc356550b77f ]

After system suspend, sometimes the r8169 doesn't work when ethernet
cable gets pluggued.

This issue happens because rtl_reset_work() doesn't get called from
rtl8169_runtime_resume(), after system suspend.

In rtl_task(), RTL_FLAG_TASK_* only gets cleared if this condition is
met:
if (!netif_running(dev) ||
!test_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags))
...

If RTL_FLAG_TASK_ENABLED was cleared during system suspend while
RTL_FLAG_TASK_RESET_PENDING was set, the next rtl_schedule_task() won't
schedule task as the flag is still there.

So in addition to clearing RTL_FLAG_TASK_ENABLED, also clears other
flags.

Cc: Heiner Kallweit <[email protected]>
Signed-off-by: Kai-Heng Feng <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/realtek/r8169.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -759,7 +759,7 @@ struct rtl8169_tc_offsets {
};

enum rtl_flag {
- RTL_FLAG_TASK_ENABLED,
+ RTL_FLAG_TASK_ENABLED = 0,
RTL_FLAG_TASK_SLOW_PENDING,
RTL_FLAG_TASK_RESET_PENDING,
RTL_FLAG_TASK_PHY_PENDING,
@@ -7618,7 +7618,8 @@ static int rtl8169_close(struct net_devi
rtl8169_update_counters(dev);

rtl_lock_work(tp);
- clear_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags);
+ /* Clear all task flags */
+ bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);

rtl8169_down(dev);
rtl_unlock_work(tp);
@@ -7795,7 +7796,9 @@ static void rtl8169_net_suspend(struct n

rtl_lock_work(tp);
napi_disable(&tp->napi);
- clear_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags);
+ /* Clear all task flags */
+ bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
+
rtl_unlock_work(tp);

rtl_pll_power_down(tp);



2018-10-08 19:14:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 104/113] s390/qeth: dont dump past end of unknown HW header

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julian Wiedmann <[email protected]>

[ Upstream commit 0ac1487c4b2de383b91ecad1be561b8f7a2c15f4 ]

For inbound data with an unsupported HW header format, only dump the
actual HW header. We have no idea how much payload follows it, and what
it contains. Worst case, we dump past the end of the Inbound Buffer and
access whatever is located next in memory.

Signed-off-by: Julian Wiedmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/s390/net/qeth_l2_main.c | 2 +-
drivers/s390/net/qeth_l3_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -523,7 +523,7 @@ static int qeth_l2_process_inbound_buffe
default:
dev_kfree_skb_any(skb);
QETH_CARD_TEXT(card, 3, "inbunkno");
- QETH_DBF_HEX(CTRL, 3, hdr, QETH_DBF_CTRL_LEN);
+ QETH_DBF_HEX(CTRL, 3, hdr, sizeof(*hdr));
continue;
}
work_done++;
--- a/drivers/s390/net/qeth_l3_main.c
+++ b/drivers/s390/net/qeth_l3_main.c
@@ -1902,7 +1902,7 @@ static int qeth_l3_process_inbound_buffe
default:
dev_kfree_skb_any(skb);
QETH_CARD_TEXT(card, 3, "inbunkno");
- QETH_DBF_HEX(CTRL, 3, hdr, QETH_DBF_CTRL_LEN);
+ QETH_DBF_HEX(CTRL, 3, hdr, sizeof(*hdr));
continue;
}
work_done++;



2018-10-08 19:15:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 109/113] smb2: fix missing files in root share directory listing

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Aurelien Aptel <[email protected]>

commit 0595751f267994c3c7027377058e4185b3a28e75 upstream.

When mounting a Windows share that is the root of a drive (eg. C$)
the server does not return . and .. directory entries. This results in
the smb2 code path erroneously skipping the 2 first entries.

Pseudo-code of the readdir() code path:

cifs_readdir(struct file, struct dir_context)
initiate_cifs_search <-- if no reponse cached yet
server->ops->query_dir_first

dir_emit_dots
dir_emit <-- adds "." and ".." if we're at pos=0

find_cifs_entry
initiate_cifs_search <-- if pos < start of current response
(restart search)
server->ops->query_dir_next <-- if pos > end of current response
(fetch next search res)

for(...) <-- loops over cur response entries
starting at pos
cifs_filldir <-- skip . and .., emit entry
cifs_fill_dirent
dir_emit
pos++

A) dir_emit_dots() always adds . & ..
and sets the current dir pos to 2 (0 and 1 are done).

Therefore we always want the index_to_find to be 2 regardless of if
the response has . and ..

B) smb1 code initializes index_of_last_entry with a +2 offset

in cifssmb.c CIFSFindFirst():
psrch_inf->index_of_last_entry = 2 /* skip . and .. */ +
psrch_inf->entries_in_buffer;

Later in find_cifs_entry() we want to find the next dir entry at pos=2
as a result of (A)

first_entry_in_buffer = cfile->srch_inf.index_of_last_entry -
cfile->srch_inf.entries_in_buffer;

This var is the dir pos that the first entry in the buffer will
have therefore it must be 2 in the first call.

If we don't offset index_of_last_entry by 2 (like in (B)),
first_entry_in_buffer=0 but we were instructed to get pos=2 so this
code in find_cifs_entry() skips the 2 first which is ok for non-root
shares, as it skips . and .. from the response but is not ok for root
shares where the 2 first are actual files

pos_in_buf = index_to_find - first_entry_in_buffer;
// pos_in_buf=2
// we skip 2 first response entries :(
for (i = 0; (i < (pos_in_buf)) && (cur_ent != NULL); i++) {
/* go entry by entry figuring out which is first */
cur_ent = nxt_dir_entry(cur_ent, end_of_smb,
cfile->srch_inf.info_level);
}

C) cifs_filldir() skips . and .. so we can safely ignore them for now.

Sample program:

int main(int argc, char **argv)
{
const char *path = argc >= 2 ? argv[1] : ".";
DIR *dh;
struct dirent *de;

printf("listing path <%s>\n", path);
dh = opendir(path);
if (!dh) {
printf("opendir error %d\n", errno);
return 1;
}

while (1) {
de = readdir(dh);
if (!de) {
if (errno) {
printf("readdir error %d\n", errno);
return 1;
}
printf("end of listing\n");
break;
}
printf("off=%lu <%s>\n", de->d_off, de->d_name);
}

return 0;
}

Before the fix with SMB1 on root shares:

<.> off=1
<..> off=2
<$Recycle.Bin> off=3
<bootmgr> off=4

and on non-root shares:

<.> off=1
<..> off=4 <-- after adding .., the offsets jumps to +2 because
<2536> off=5 we skipped . and .. from response buffer (C)
<411> off=6 but still incremented pos
<file> off=7
<fsx> off=8

Therefore the fix for smb2 is to mimic smb1 behaviour and offset the
index_of_last_entry by 2.

Test results comparing smb1 and smb2 before/after the fix on root
share, non-root shares and on large directories (ie. multi-response
dir listing):

PRE FIX
=======
pre-1-root VS pre-2-root:
ERR pre-2-root is missing [bootmgr, $Recycle.Bin]
pre-1-nonroot VS pre-2-nonroot:
OK~ same files, same order, different offsets
pre-1-nonroot-large VS pre-2-nonroot-large:
OK~ same files, same order, different offsets

POST FIX
========
post-1-root VS post-2-root:
OK same files, same order, same offsets
post-1-nonroot VS post-2-nonroot:
OK same files, same order, same offsets
post-1-nonroot-large VS post-2-nonroot-large:
OK same files, same order, same offsets

REGRESSION?
===========
pre-1-root VS post-1-root:
OK same files, same order, same offsets
pre-1-nonroot VS post-1-nonroot:
OK same files, same order, same offsets

BugLink: https://bugzilla.samba.org/show_bug.cgi?id=13107
Signed-off-by: Aurelien Aptel <[email protected]>
Signed-off-by: Paulo Alcantara <[email protected]>
Reviewed-by: Ronnie Sahlberg <[email protected]>
Signed-off-by: Steve French <[email protected]>
CC: Stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/smb2ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -914,7 +914,7 @@ smb2_query_dir_first(const unsigned int
}

srch_inf->entries_in_buffer = 0;
- srch_inf->index_of_last_entry = 0;
+ srch_inf->index_of_last_entry = 2;

rc = SMB2_query_directory(xid, tcon, fid->persistent_fid,
fid->volatile_fid, 0, srch_inf);



2018-10-08 19:15:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 083/113] net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jia-Ju Bai <[email protected]>

[ Upstream commit 16fe10cf92783ed9ceb182d6ea2b8adf5e8ec1b8 ]

The kernel module may sleep with holding a spinlock.

The function call paths (from bottom to top) in Linux-4.16 are:

[FUNC] usleep_range
drivers/net/ethernet/cadence/macb_main.c, 648:
usleep_range in macb_halt_tx
drivers/net/ethernet/cadence/macb_main.c, 730:
macb_halt_tx in macb_tx_error_task
drivers/net/ethernet/cadence/macb_main.c, 721:
_raw_spin_lock_irqsave in macb_tx_error_task

To fix this bug, usleep_range() is replaced with udelay().

This bug is found by my static analysis tool DSAC.

Signed-off-by: Jia-Ju Bai <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/cadence/macb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -523,7 +523,7 @@ static int macb_halt_tx(struct macb *bp)
if (!(status & MACB_BIT(TGO)))
return 0;

- usleep_range(10, 250);
+ udelay(250);
} while (time_before(halt_time, timeout));

return -ETIMEDOUT;



2018-10-08 19:15:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 079/113] cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Arunk Khandavalli <[email protected]>

[ Upstream commit 4f0223bfe9c3e62d8f45a85f1ef1b18a8a263ef9 ]

nl80211_update_ft_ies() tried to validate NL80211_ATTR_IE with
is_valid_ie_attr() before dereferencing it, but that helper function
returns true in case of NULL pointer (i.e., attribute not included).
This can result to dereferencing a NULL pointer. Fix that by explicitly
checking that NL80211_ATTR_IE is included.

Fixes: 355199e02b83 ("cfg80211: Extend support for IEEE 802.11r Fast BSS Transition")
Signed-off-by: Arunk Khandavalli <[email protected]>
Signed-off-by: Jouni Malinen <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10014,6 +10014,7 @@ static int nl80211_update_ft_ies(struct
return -EOPNOTSUPP;

if (!info->attrs[NL80211_ATTR_MDID] ||
+ !info->attrs[NL80211_ATTR_IE] ||
!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
return -EINVAL;




2018-10-08 19:16:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 078/113] mac80211: mesh: fix HWMP sequence numbering to follow standard

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yuan-Chi Pang <[email protected]>

[ Upstream commit 1f631c3201fe5491808df143d8fcba81b3197ffd ]

IEEE 802.11-2016 14.10.8.3 HWMP sequence numbering says:
If it is a target mesh STA, it shall update its own HWMP SN to
maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1
immediately before it generates a PREP element in response to a
PREQ element.

Signed-off-by: Yuan-Chi Pang <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/mesh_hwmp.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -552,6 +552,10 @@ static void hwmp_preq_frame_process(stru
forward = false;
reply = true;
target_metric = 0;
+
+ if (SN_GT(target_sn, ifmsh->sn))
+ ifmsh->sn = target_sn;
+
if (time_after(jiffies, ifmsh->last_sn_update +
net_traversal_jiffies(sdata)) ||
time_before(jiffies, ifmsh->last_sn_update)) {



2018-10-08 19:16:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 097/113] drm/nouveau/TBDdevinit: dont fail when PMU/PRE_OS is missing from VBIOS

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Skeggs <[email protected]>

[ Upstream commit 0a6986c6595e9afd20ff7280dab36431c1e467f8 ]

This Falcon application doesn't appear to be present on some newer
systems, so let's not fail init if we can't find it.

TBD: is there a way to determine whether it *should* be there?

Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm204.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm204.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm204.c
@@ -161,7 +161,8 @@ gm204_devinit_post(struct nvkm_devinit *
}

/* load and execute some other ucode image (bios therm?) */
- return pmu_load(init, 0x01, post, NULL, NULL);
+ pmu_load(init, 0x01, post, NULL, NULL);
+ return 0;
}

static const struct nvkm_devinit_func



2018-10-08 19:17:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 084/113] fs/cifs: dont translate SFM_SLASH (U+F026) to backslash

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jon Kuhn <[email protected]>

[ Upstream commit c15e3f19a6d5c89b1209dc94b40e568177cb0921 ]

When a Mac client saves an item containing a backslash to a file server
the backslash is represented in the CIFS/SMB protocol as as U+F026.
Before this change, listing a directory containing an item with a
backslash in its name will return that item with the backslash
represented with a true backslash character (U+005C) because
convert_sfm_character mapped U+F026 to U+005C when interpretting the
CIFS/SMB protocol response. However, attempting to open or stat the
path using a true backslash will result in an error because
convert_to_sfm_char does not map U+005C back to U+F026 causing the
CIFS/SMB request to be made with the backslash represented as U+005C.

This change simply prevents the U+F026 to U+005C conversion from
happenning. This is analogous to how the code does not do any
translation of UNI_SLASH (U+F000).

Signed-off-by: Jon Kuhn <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/cifs_unicode.c | 3 ---
1 file changed, 3 deletions(-)

--- a/fs/cifs/cifs_unicode.c
+++ b/fs/cifs/cifs_unicode.c
@@ -101,9 +101,6 @@ convert_sfm_char(const __u16 src_char, c
case SFM_LESSTHAN:
*target = '<';
break;
- case SFM_SLASH:
- *target = '\\';
- break;
case SFM_SPACE:
*target = ' ';
break;



2018-10-08 19:17:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 089/113] tools/vm/slabinfo.c: fix sign-compare warning

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Naoya Horiguchi <[email protected]>

[ Upstream commit 904506562e0856f2535d876407d087c9459d345b ]

Currently we get the following compiler warning:

slabinfo.c:854:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (s->object_size < min_objsize)
^

due to the mismatch of signed/unsigned comparison. ->object_size and
->slab_size are never expected to be negative, so let's define them as
unsigned int.

[[email protected]: convert everything - none of these can be negative]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Naoya Horiguchi <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/vm/slabinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -29,8 +29,8 @@ struct slabinfo {
int alias;
int refs;
int aliases, align, cache_dma, cpu_slabs, destroy_by_rcu;
- int hwcache_align, object_size, objs_per_slab;
- int sanity_checks, slab_size, store_user, trace;
+ unsigned int hwcache_align, object_size, objs_per_slab;
+ unsigned int sanity_checks, slab_size, store_user, trace;
int order, poison, reclaim_account, red_zone;
unsigned long partial, objects, slabs, objects_partial, objects_total;
unsigned long alloc_fastpath, alloc_slowpath;



2018-10-08 19:17:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 077/113] gpio: adp5588: Fix sleep-in-atomic-context bug

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michael Hennerich <[email protected]>

[ Upstream commit 6537886cdc9a637711fd6da980dbb87c2c87c9aa ]

This fixes:
[BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
in adp5588_gpio_write()
[BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
in adp5588_gpio_direction_input()

Reported-by: Jia-Ju Bai <[email protected]>
Signed-off-by: Michael Hennerich <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpio/gpio-adp5588.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)

--- a/drivers/gpio/gpio-adp5588.c
+++ b/drivers/gpio/gpio-adp5588.c
@@ -41,6 +41,8 @@ struct adp5588_gpio {
uint8_t int_en[3];
uint8_t irq_mask[3];
uint8_t irq_stat[3];
+ uint8_t int_input_en[3];
+ uint8_t int_lvl_cached[3];
};

static int adp5588_gpio_read(struct i2c_client *client, u8 reg)
@@ -177,12 +179,28 @@ static void adp5588_irq_bus_sync_unlock(
struct adp5588_gpio *dev = irq_data_get_irq_chip_data(d);
int i;

- for (i = 0; i <= ADP5588_BANK(ADP5588_MAXGPIO); i++)
+ for (i = 0; i <= ADP5588_BANK(ADP5588_MAXGPIO); i++) {
+ if (dev->int_input_en[i]) {
+ mutex_lock(&dev->lock);
+ dev->dir[i] &= ~dev->int_input_en[i];
+ dev->int_input_en[i] = 0;
+ adp5588_gpio_write(dev->client, GPIO_DIR1 + i,
+ dev->dir[i]);
+ mutex_unlock(&dev->lock);
+ }
+
+ if (dev->int_lvl_cached[i] != dev->int_lvl[i]) {
+ dev->int_lvl_cached[i] = dev->int_lvl[i];
+ adp5588_gpio_write(dev->client, GPIO_INT_LVL1 + i,
+ dev->int_lvl[i]);
+ }
+
if (dev->int_en[i] ^ dev->irq_mask[i]) {
dev->int_en[i] = dev->irq_mask[i];
adp5588_gpio_write(dev->client, GPIO_INT_EN1 + i,
dev->int_en[i]);
}
+ }

mutex_unlock(&dev->irq_lock);
}
@@ -225,9 +243,7 @@ static int adp5588_irq_set_type(struct i
else
return -EINVAL;

- adp5588_gpio_direction_input(&dev->gpio_chip, gpio);
- adp5588_gpio_write(dev->client, GPIO_INT_LVL1 + bank,
- dev->int_lvl[bank]);
+ dev->int_input_en[bank] |= bit;

return 0;
}



2018-10-08 19:17:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 075/113] mac80211: correct use of IEEE80211_VHT_CAP_RXSTBC_X

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Danek Duvall <[email protected]>

[ Upstream commit 67d1ba8a6dc83d90cd58b89fa6cbf9ae35a0cf7f ]

The mod mask for VHT capabilities intends to say that you can override
the number of STBC receive streams, and it does, but only by accident.
The IEEE80211_VHT_CAP_RXSTBC_X aren't bits to be set, but values (albeit
left-shifted). ORing the bits together gets the right answer, but we
should use the _MASK macro here instead.

Signed-off-by: Danek Duvall <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/main.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)

--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -460,10 +460,7 @@ static const struct ieee80211_vht_cap ma
cpu_to_le32(IEEE80211_VHT_CAP_RXLDPC |
IEEE80211_VHT_CAP_SHORT_GI_80 |
IEEE80211_VHT_CAP_SHORT_GI_160 |
- IEEE80211_VHT_CAP_RXSTBC_1 |
- IEEE80211_VHT_CAP_RXSTBC_2 |
- IEEE80211_VHT_CAP_RXSTBC_3 |
- IEEE80211_VHT_CAP_RXSTBC_4 |
+ IEEE80211_VHT_CAP_RXSTBC_MASK |
IEEE80211_VHT_CAP_TXSTBC |
IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |



2018-10-08 19:17:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 086/113] mac80211: fix a race between restart and CSA flows

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Emmanuel Grumbach <[email protected]>

[ Upstream commit f3ffb6c3a28963657eb8b02a795d75f2ebbd5ef4 ]

We hit a problem with iwlwifi that was caused by a bug in
mac80211. A bug in iwlwifi caused the firwmare to crash in
certain cases in channel switch. Because of that bug,
drv_pre_channel_switch would fail and trigger the restart
flow.
Now we had the hw restart worker which runs on the system's
workqueue and the csa_connection_drop_work worker that runs
on mac80211's workqueue that can run together. This is
obviously problematic since the restart work wants to
reconfigure the connection, while the csa_connection_drop_work
worker does the exact opposite: it tries to disconnect.

Fix this by cancelling the csa_connection_drop_work worker
in the restart worker.

Note that this can sound racy: we could have:

driver iface_work CSA_work restart_work
+++++++++++++++++++++++++++++++++++++++++++++
|
<--drv_cs ---|
<FW CRASH!>
-CS FAILED-->
| |
| cancel_work(CSA)
schedule |
CSA work |
| |
Race between those 2

But this is not possible because we flush the workqueue
in the restart worker before we cancel the CSA worker.
That would be bullet proof if we could guarantee that
we schedule the CSA worker only from the iface_work
which runs on the workqueue (and not on the system's
workqueue), but unfortunately we do have an instance
in which we schedule the CSA work outside the context
of the workqueue (ieee80211_chswitch_done).

Note also that we should probably cancel other workers
like beacon_connection_loss_work and possibly others
for different types of interfaces, at the very least,
IBSS should suffer from the exact same problem, but for
now, do the minimum to fix the actual bug that was actually
experienced and reproduced.

Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/main.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)

--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -253,8 +253,27 @@ static void ieee80211_restart_work(struc
"%s called with hardware scan in progress\n", __func__);

rtnl_lock();
- list_for_each_entry(sdata, &local->interfaces, list)
+ list_for_each_entry(sdata, &local->interfaces, list) {
+ /*
+ * XXX: there may be more work for other vif types and even
+ * for station mode: a good thing would be to run most of
+ * the iface type's dependent _stop (ieee80211_mg_stop,
+ * ieee80211_ibss_stop) etc...
+ * For now, fix only the specific bug that was seen: race
+ * between csa_connection_drop_work and us.
+ */
+ if (sdata->vif.type == NL80211_IFTYPE_STATION) {
+ /*
+ * This worker is scheduled from the iface worker that
+ * runs on mac80211's workqueue, so we can't be
+ * scheduling this worker after the cancel right here.
+ * The exception is ieee80211_chswitch_done.
+ * Then we can have a race...
+ */
+ cancel_work_sync(&sdata->u.mgd.csa_connection_drop_work);
+ }
flush_delayed_work(&sdata->dec_tailroom_needed_wk);
+ }
ieee80211_scan_cancel(local);
ieee80211_reconfig(local);
rtnl_unlock();



2018-10-08 19:17:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 054/113] USB: usbdevfs: sanitize flags more

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oliver Neukum <[email protected]>

commit 7a68d9fb851012829c29e770621905529bd9490b upstream.

Requesting a ZERO_PACKET or not is sensible only for output.
In the input direction the device decides.
Likewise accepting short packets makes sense only for input.

This allows operation with panic_on_warn without opening up
a local DOS.

Signed-off-by: Oliver Neukum <[email protected]>
Reported-by: [email protected]
Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/devio.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)

--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1289,10 +1289,13 @@ static int proc_do_submiturb(struct usb_
struct async *as = NULL;
struct usb_ctrlrequest *dr = NULL;
unsigned int u, totlen, isofrmlen;
- int i, ret, is_in, num_sgs = 0, ifnum = -1;
+ int i, ret, num_sgs = 0, ifnum = -1;
int number_of_packets = 0;
unsigned int stream_id = 0;
void *buf;
+ bool is_in;
+ bool allow_short = false;
+ bool allow_zero = false;
unsigned long mask = USBDEVFS_URB_SHORT_NOT_OK |
USBDEVFS_URB_BULK_CONTINUATION |
USBDEVFS_URB_NO_FSBR |
@@ -1326,6 +1329,8 @@ static int proc_do_submiturb(struct usb_
u = 0;
switch (uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
+ if (is_in)
+ allow_short = true;
if (!usb_endpoint_xfer_control(&ep->desc))
return -EINVAL;
/* min 8 byte setup packet */
@@ -1366,6 +1371,10 @@ static int proc_do_submiturb(struct usb_
break;

case USBDEVFS_URB_TYPE_BULK:
+ if (!is_in)
+ allow_zero = true;
+ else
+ allow_short = true;
switch (usb_endpoint_type(&ep->desc)) {
case USB_ENDPOINT_XFER_CONTROL:
case USB_ENDPOINT_XFER_ISOC:
@@ -1386,6 +1395,10 @@ static int proc_do_submiturb(struct usb_
if (!usb_endpoint_xfer_int(&ep->desc))
return -EINVAL;
interrupt_urb:
+ if (!is_in)
+ allow_zero = true;
+ else
+ allow_short = true;
break;

case USBDEVFS_URB_TYPE_ISO:
@@ -1512,11 +1525,11 @@ static int proc_do_submiturb(struct usb_
u = (is_in ? URB_DIR_IN : URB_DIR_OUT);
if (uurb->flags & USBDEVFS_URB_ISO_ASAP)
u |= URB_ISO_ASAP;
- if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in)
+ if (allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
u |= URB_SHORT_NOT_OK;
if (uurb->flags & USBDEVFS_URB_NO_FSBR)
u |= URB_NO_FSBR;
- if (uurb->flags & USBDEVFS_URB_ZERO_PACKET)
+ if (allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
u |= URB_ZERO_PACKET;
if (uurb->flags & USBDEVFS_URB_NO_INTERRUPT)
u |= URB_NO_INTERRUPT;



2018-10-08 19:17:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 050/113] USB: fix error handling in usb_driver_claim_interface()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Stern <[email protected]>

commit bd729f9d67aa9a303d8925bb8c4f06af25f407d1 upstream.

The syzbot fuzzing project found a use-after-free bug in the USB
core. The bug was caused by usbfs not unbinding from an interface
when the USB device file was closed, which led another process to
attempt the unbind later on, after the private data structure had been
deallocated.

The reason usbfs did not unbind the interface at the appropriate time
was because it thought the interface had never been claimed in the
first place. This was caused by the fact that
usb_driver_claim_interface() does not clean up properly when
device_bind_driver() returns an error. Although the error code gets
passed back to the caller, the iface->dev.driver pointer remains set
and iface->condition remains equal to USB_INTERFACE_BOUND.

This patch adds proper error handling to usb_driver_claim_interface().

Signed-off-by: Alan Stern <[email protected]>
Reported-by: [email protected]
CC: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/driver.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)

--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -562,6 +562,21 @@ int usb_driver_claim_interface(struct us
if (!lpm_disable_error)
usb_unlocked_enable_lpm(udev);

+ if (retval) {
+ dev->driver = NULL;
+ usb_set_intfdata(iface, NULL);
+ iface->needs_remote_wakeup = 0;
+ iface->condition = USB_INTERFACE_UNBOUND;
+
+ /*
+ * Unbound interfaces are always runtime-PM-disabled
+ * and runtime-PM-suspended
+ */
+ if (driver->supports_autosuspend)
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ }
+
return retval;
}
EXPORT_SYMBOL_GPL(usb_driver_claim_interface);



2018-10-08 19:19:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 064/113] thermal: of-thermal: disable passive polling when thermal zone is disabled

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anson Huang <[email protected]>

[ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ]

When thermal zone is in passive mode, disabling its mode from
sysfs is NOT taking effect at all, it is still polling the
temperature of the disabled thermal zone and handling all thermal
trips, it makes user confused. The disabling operation should
disable the thermal zone behavior completely, for both active and
passive mode, this patch clears the passive_delay when thermal
zone is disabled and restores it when it is enabled.

Signed-off-by: Anson Huang <[email protected]>
Signed-off-by: Eduardo Valentin <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/thermal/of-thermal.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -284,10 +284,13 @@ static int of_thermal_set_mode(struct th

mutex_lock(&tz->lock);

- if (mode == THERMAL_DEVICE_ENABLED)
+ if (mode == THERMAL_DEVICE_ENABLED) {
tz->polling_delay = data->polling_delay;
- else
+ tz->passive_delay = data->passive_delay;
+ } else {
tz->polling_delay = 0;
+ tz->passive_delay = 0;
+ }

mutex_unlock(&tz->lock);




2018-10-08 19:20:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 023/113] s390/extmem: fix gcc 8 stringop-overflow warning

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vasily Gorbik <[email protected]>

[ Upstream commit 6b2ddf33baec23dace85bd647e3fc4ac070963e8 ]

arch/s390/mm/extmem.c: In function '__segment_load':
arch/s390/mm/extmem.c:436:2: warning: 'strncat' specified bound 7 equals
source length [-Wstringop-overflow=]
strncat(seg->res_name, " (DCSS)", 7);

What gcc complains about here is the misuse of strncat function, which
in this case does not limit a number of bytes taken from "src", so it is
in the end the same as strcat(seg->res_name, " (DCSS)");

Keeping in mind that a res_name is 15 bytes, strncat in this case
would overflow the buffer and write 0 into alignment byte between the
fields in the struct. To avoid that increasing res_name size to 16,
and reusing strlcat.

Reviewed-by: Heiko Carstens <[email protected]>
Signed-off-by: Vasily Gorbik <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/s390/mm/extmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/s390/mm/extmem.c
+++ b/arch/s390/mm/extmem.c
@@ -79,7 +79,7 @@ struct qin64 {
struct dcss_segment {
struct list_head list;
char dcss_name[8];
- char res_name[15];
+ char res_name[16];
unsigned long start_addr;
unsigned long end;
atomic_t ref_count;
@@ -434,7 +434,7 @@ __segment_load (char *name, int do_nonsh
memcpy(&seg->res_name, seg->dcss_name, 8);
EBCASC(seg->res_name, 8);
seg->res_name[8] = '\0';
- strncat(seg->res_name, " (DCSS)", 7);
+ strlcat(seg->res_name, " (DCSS)", sizeof(seg->res_name));
seg->res->name = seg->res_name;
rc = seg->vm_segtype;
if (rc == SEG_TYPE_SC ||



2018-10-08 19:20:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 036/113] HID: hid-ntrig: add error handling for sysfs_create_group

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zhouyang Jia <[email protected]>

[ Upstream commit 44d4d51de9a3534a2b63d69efda02a10e66541e4 ]

When sysfs_create_group fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling sysfs_create_group.

Signed-off-by: Zhouyang Jia <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-ntrig.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/hid/hid-ntrig.c
+++ b/drivers/hid/hid-ntrig.c
@@ -955,6 +955,8 @@ static int ntrig_probe(struct hid_device

ret = sysfs_create_group(&hdev->dev.kobj,
&ntrig_attribute_group);
+ if (ret)
+ hid_err(hdev, "cannot create sysfs group\n");

return 0;
err_free:



2018-10-08 19:20:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 031/113] ALSA: hda: Add AZX_DCAPS_PM_RUNTIME for AMD Raven Ridge

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kai-Heng Feng <[email protected]>

[ Upstream commit 1adca4b0cd65c14cb8b8c9c257720385869c3d5f ]

This patch can make audio controller in AMD Raven Ridge gets runtime
suspended to D3, to save ~1W power when it's not in use.

Cc: Vijendar Mukunda <[email protected]>
Signed-off-by: Kai-Heng Feng <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/hda_intel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2360,7 +2360,8 @@ static const struct pci_device_id azx_id
.driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
/* AMD Raven */
{ PCI_DEVICE(0x1022, 0x15e3),
- .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
+ .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
+ AZX_DCAPS_PM_RUNTIME },
/* ATI HDMI */
{ PCI_DEVICE(0x1002, 0x0002),
.driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS },



2018-10-08 19:21:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 020/113] usb: wusbcore: security: cast sizeof to int for comparison

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julia Lawall <[email protected]>

[ Upstream commit d3ac5598c5010a8999978ebbcca3b1c6188ca36b ]

Comparing an int to a size, which is unsigned, causes the int to become
unsigned, giving the wrong result. usb_get_descriptor can return a
negative error code.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
int x;
expression e,e1;
identifier f;
@@

*x = f(...);
... when != x = e1
when != if (x < 0 || ...) { ... return ...; }
*x < sizeof(e)
// </smpl>

Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/wusbcore/security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -230,7 +230,7 @@ int wusb_dev_sec_add(struct wusbhc *wusb

result = usb_get_descriptor(usb_dev, USB_DT_SECURITY,
0, secd, sizeof(*secd));
- if (result < sizeof(*secd)) {
+ if (result < (int)sizeof(*secd)) {
dev_err(dev, "Can't read security descriptor or "
"not enough data: %d\n", result);
goto out;



2018-10-08 19:21:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 038/113] EDAC, i7core: Fix memleaks and use-after-free on probe and remove

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

[ Upstream commit 6c974d4dfafe5e9ee754f2a6fba0eb1864f1649e ]

Make sure to free and deregister the addrmatch and chancounts devices
allocated during probe in all error paths. Also fix use-after-free in a
probe error path and in the remove success path where the devices were
being put before before deregistration.

Signed-off-by: Johan Hovold <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: linux-edac <[email protected]>
Fixes: 356f0a30860d ("i7core_edac: change the mem allocation scheme to make Documentation/kobject.txt happy")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/edac/i7core_edac.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)

--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1187,15 +1187,14 @@ static int i7core_create_sysfs_devices(s

rc = device_add(pvt->addrmatch_dev);
if (rc < 0)
- return rc;
+ goto err_put_addrmatch;

if (!pvt->is_registered) {
pvt->chancounts_dev = kzalloc(sizeof(*pvt->chancounts_dev),
GFP_KERNEL);
if (!pvt->chancounts_dev) {
- put_device(pvt->addrmatch_dev);
- device_del(pvt->addrmatch_dev);
- return -ENOMEM;
+ rc = -ENOMEM;
+ goto err_del_addrmatch;
}

pvt->chancounts_dev->type = &all_channel_counts_type;
@@ -1209,9 +1208,18 @@ static int i7core_create_sysfs_devices(s

rc = device_add(pvt->chancounts_dev);
if (rc < 0)
- return rc;
+ goto err_put_chancounts;
}
return 0;
+
+err_put_chancounts:
+ put_device(pvt->chancounts_dev);
+err_del_addrmatch:
+ device_del(pvt->addrmatch_dev);
+err_put_addrmatch:
+ put_device(pvt->addrmatch_dev);
+
+ return rc;
}

static void i7core_delete_sysfs_devices(struct mem_ctl_info *mci)
@@ -1221,11 +1229,11 @@ static void i7core_delete_sysfs_devices(
edac_dbg(1, "\n");

if (!pvt->is_registered) {
- put_device(pvt->chancounts_dev);
device_del(pvt->chancounts_dev);
+ put_device(pvt->chancounts_dev);
}
- put_device(pvt->addrmatch_dev);
device_del(pvt->addrmatch_dev);
+ put_device(pvt->addrmatch_dev);
}

/****************************************************************************



2018-10-08 19:22:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 012/113] media: exynos4-is: Prevent NULL pointer dereference in __isp_video_try_fmt()

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sylwester Nawrocki <[email protected]>

[ Upstream commit 7c1b9a5aeed91bef98988ac0fcf38c8c1f4f9a3a ]

This patch fixes potential NULL pointer dereference as indicated
by the following static checker warning:

drivers/media/platform/exynos4-is/fimc-isp-video.c:408 isp_video_try_fmt_mplane()
error: NULL dereference inside function '__isp_video_try_fmt(isp, &f->fmt.pix_mp, (0))()'.

Fixes: 34947b8aebe3: ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")

Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/exynos4-is/fimc-isp-video.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -391,12 +391,17 @@ static void __isp_video_try_fmt(struct f
struct v4l2_pix_format_mplane *pixm,
const struct fimc_fmt **fmt)
{
- *fmt = fimc_isp_find_format(&pixm->pixelformat, NULL, 2);
+ const struct fimc_fmt *__fmt;
+
+ __fmt = fimc_isp_find_format(&pixm->pixelformat, NULL, 2);
+
+ if (fmt)
+ *fmt = __fmt;

pixm->colorspace = V4L2_COLORSPACE_SRGB;
pixm->field = V4L2_FIELD_NONE;
- pixm->num_planes = (*fmt)->memplanes;
- pixm->pixelformat = (*fmt)->fourcc;
+ pixm->num_planes = __fmt->memplanes;
+ pixm->pixelformat = __fmt->fourcc;
/*
* TODO: double check with the docmentation these width/height
* constraints are correct.



2018-10-08 23:24:43

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/113] 4.4.160-stable review

On 10/08/2018 12:30 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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 Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.160-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
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


2018-10-09 01:30:16

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/113] 4.4.160-stable review

On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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 Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.160-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
>

Merged, compiled with -Werror, and installed onto my Pixel 2 XL.

No initial issues noticed in dmesg or general usage.

Thanks!
Nathan

2018-10-09 06:34:50

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Mon, Oct 08, 2018 at 08:31:34PM +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Stephen Boyd <[email protected]>
>
> [ Upstream commit b55326dc969ea2d704a008d9a97583b128f54f4f ]
>
> The interrupt controller hardware in this pin controller has two status
> enable bits. The first "normal" status enable bit enables or disables
> the summary interrupt line being raised when a gpio interrupt triggers
> and the "raw" status enable bit allows or prevents the hardware from
> latching an interrupt into the status register for a gpio interrupt.
> Currently we just toggle the "normal" status enable bit in the mask and
> unmask ops so that the summary irq interrupt going to the CPU's
> interrupt controller doesn't trigger for the masked gpio interrupt.
>
> For a level triggered interrupt, the flow would be as follows: the pin
> controller sees the interrupt, latches the status into the status
> register, raises the summary irq to the CPU, summary irq handler runs
> and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
> interrupt, the interrupt handler runs, and finally unmask the interrupt.
> When the interrupt handler completes, we expect that the interrupt line
> level will go back to the deasserted state so the genirq code can unmask
> the interrupt without it triggering again.
>
> If we only mask the interrupt by clearing the "normal" status enable bit
> then we'll ack the interrupt but it will continue to show up as pending
> in the status register because the raw status bit is enabled, the
> hardware hasn't deasserted the line, and thus the asserted state latches
> into the status register again. When the hardware deasserts the
> interrupt the pin controller still thinks there is a pending unserviced
> level interrupt because it latched it earlier. This behavior causes
> software to see an extra interrupt for level type interrupts each time
> the interrupt is handled.
>
> Let's fix this by clearing the raw status enable bit for level type
> interrupts so that the hardware stops latching the status of the
> interrupt after we ack it. We don't do this for edge type interrupts
> because it seems that toggling the raw status enable bit for edge type
> interrupts causes spurious edge interrupts.
>
> Signed-off-by: Stephen Boyd <[email protected]>
> Reviewed-by: Douglas Anderson <[email protected]>
> Reviewed-by: Bjorn Andersson <[email protected]>
> Signed-off-by: Linus Walleij <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -577,6 +577,29 @@ static void msm_gpio_irq_mask(struct irq
> spin_lock_irqsave(&pctrl->lock, flags);
>
> val = readl(pctrl->regs + g->intr_cfg_reg);
> + /*
> + * There are two bits that control interrupt forwarding to the CPU. The
> + * RAW_STATUS_EN bit causes the level or edge sensed on the line to be
> + * latched into the interrupt status register when the hardware detects
> + * an irq that it's configured for (either edge for edge type or level
> + * for level type irq). The 'non-raw' status enable bit causes the
> + * hardware to assert the summary interrupt to the CPU if the latched
> + * status bit is set. There's a bug though, the edge detection logic
> + * seems to have a problem where toggling the RAW_STATUS_EN bit may
> + * cause the status bit to latch spuriously when there isn't any edge
> + * so we can't touch that bit for edge type irqs and we have to keep
> + * the bit set anyway so that edges are latched while the line is masked.
> + *
> + * To make matters more complicated, leaving the RAW_STATUS_EN bit
> + * enabled all the time causes level interrupts to re-latch into the
> + * status register because the level is still present on the line after
> + * we ack it. We clear the raw status enable bit during mask here and
> + * set the bit on unmask so the interrupt can't latch into the hardware
> + * while it's masked.
> + */
> + if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
> + val &= ~BIT(g->intr_raw_status_bit);
> +
> val &= ~BIT(g->intr_enable_bit);
> writel(val, pctrl->regs + g->intr_cfg_reg);
>
> @@ -598,6 +621,7 @@ static void msm_gpio_irq_unmask(struct i
> spin_lock_irqsave(&pctrl->lock, flags);
>
> val = readl(pctrl->regs + g->intr_cfg_reg);
> + val |= BIT(g->intr_raw_status_bit);
> val |= BIT(g->intr_enable_bit);
> writel(val, pctrl->regs + g->intr_cfg_reg);
>
>
>

Sigh, sorry, I caught this after I sent my initial all good email but
this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
apps that want to use it ask to enable it). I can't say why, I'm more
than happy to debug but I'm assuming it's some voodoo that Qualcomm has
done out of tree. I'll leave it up to you how to proceed given that I
can't run mainline :(

Nathan

2018-10-09 09:24:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Mon, Oct 08, 2018 at 11:33:38PM -0700, Nathan Chancellor wrote:
> On Mon, Oct 08, 2018 at 08:31:34PM +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Stephen Boyd <[email protected]>
> >
> > [ Upstream commit b55326dc969ea2d704a008d9a97583b128f54f4f ]
> >
> > The interrupt controller hardware in this pin controller has two status
> > enable bits. The first "normal" status enable bit enables or disables
> > the summary interrupt line being raised when a gpio interrupt triggers
> > and the "raw" status enable bit allows or prevents the hardware from
> > latching an interrupt into the status register for a gpio interrupt.
> > Currently we just toggle the "normal" status enable bit in the mask and
> > unmask ops so that the summary irq interrupt going to the CPU's
> > interrupt controller doesn't trigger for the masked gpio interrupt.
> >
> > For a level triggered interrupt, the flow would be as follows: the pin
> > controller sees the interrupt, latches the status into the status
> > register, raises the summary irq to the CPU, summary irq handler runs
> > and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
> > interrupt, the interrupt handler runs, and finally unmask the interrupt.
> > When the interrupt handler completes, we expect that the interrupt line
> > level will go back to the deasserted state so the genirq code can unmask
> > the interrupt without it triggering again.
> >
> > If we only mask the interrupt by clearing the "normal" status enable bit
> > then we'll ack the interrupt but it will continue to show up as pending
> > in the status register because the raw status bit is enabled, the
> > hardware hasn't deasserted the line, and thus the asserted state latches
> > into the status register again. When the hardware deasserts the
> > interrupt the pin controller still thinks there is a pending unserviced
> > level interrupt because it latched it earlier. This behavior causes
> > software to see an extra interrupt for level type interrupts each time
> > the interrupt is handled.
> >
> > Let's fix this by clearing the raw status enable bit for level type
> > interrupts so that the hardware stops latching the status of the
> > interrupt after we ack it. We don't do this for edge type interrupts
> > because it seems that toggling the raw status enable bit for edge type
> > interrupts causes spurious edge interrupts.
> >
> > Signed-off-by: Stephen Boyd <[email protected]>
> > Reviewed-by: Douglas Anderson <[email protected]>
> > Reviewed-by: Bjorn Andersson <[email protected]>
> > Signed-off-by: Linus Walleij <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/pinctrl/qcom/pinctrl-msm.c | 24 ++++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> > @@ -577,6 +577,29 @@ static void msm_gpio_irq_mask(struct irq
> > spin_lock_irqsave(&pctrl->lock, flags);
> >
> > val = readl(pctrl->regs + g->intr_cfg_reg);
> > + /*
> > + * There are two bits that control interrupt forwarding to the CPU. The
> > + * RAW_STATUS_EN bit causes the level or edge sensed on the line to be
> > + * latched into the interrupt status register when the hardware detects
> > + * an irq that it's configured for (either edge for edge type or level
> > + * for level type irq). The 'non-raw' status enable bit causes the
> > + * hardware to assert the summary interrupt to the CPU if the latched
> > + * status bit is set. There's a bug though, the edge detection logic
> > + * seems to have a problem where toggling the RAW_STATUS_EN bit may
> > + * cause the status bit to latch spuriously when there isn't any edge
> > + * so we can't touch that bit for edge type irqs and we have to keep
> > + * the bit set anyway so that edges are latched while the line is masked.
> > + *
> > + * To make matters more complicated, leaving the RAW_STATUS_EN bit
> > + * enabled all the time causes level interrupts to re-latch into the
> > + * status register because the level is still present on the line after
> > + * we ack it. We clear the raw status enable bit during mask here and
> > + * set the bit on unmask so the interrupt can't latch into the hardware
> > + * while it's masked.
> > + */
> > + if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
> > + val &= ~BIT(g->intr_raw_status_bit);
> > +
> > val &= ~BIT(g->intr_enable_bit);
> > writel(val, pctrl->regs + g->intr_cfg_reg);
> >
> > @@ -598,6 +621,7 @@ static void msm_gpio_irq_unmask(struct i
> > spin_lock_irqsave(&pctrl->lock, flags);
> >
> > val = readl(pctrl->regs + g->intr_cfg_reg);
> > + val |= BIT(g->intr_raw_status_bit);
> > val |= BIT(g->intr_enable_bit);
> > writel(val, pctrl->regs + g->intr_cfg_reg);
> >
> >
> >
>
> Sigh, sorry, I caught this after I sent my initial all good email but
> this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> apps that want to use it ask to enable it). I can't say why, I'm more
> than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> done out of tree. I'll leave it up to you how to proceed given that I
> can't run mainline :(

Ugh, I hate the qualcomm changes...

Given the mess that all of the msm driver changes have, I'll go drop
this patch from the stable tree as I don't want to deal with the
fall-out for when people merge this to their device-specific trees.

thanks for testing and letting me know about this.

greg k-h

2018-10-09 16:58:37

by Bjorn Andersson

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Tue 09 Oct 02:23 PDT 2018, Greg Kroah-Hartman wrote:

> On Mon, Oct 08, 2018 at 11:33:38PM -0700, Nathan Chancellor wrote:
> > On Mon, Oct 08, 2018 at 08:31:34PM +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Stephen Boyd <[email protected]>
> > >
> > > [ Upstream commit b55326dc969ea2d704a008d9a97583b128f54f4f ]
> > >
> > > The interrupt controller hardware in this pin controller has two status
> > > enable bits. The first "normal" status enable bit enables or disables
> > > the summary interrupt line being raised when a gpio interrupt triggers
> > > and the "raw" status enable bit allows or prevents the hardware from
> > > latching an interrupt into the status register for a gpio interrupt.
> > > Currently we just toggle the "normal" status enable bit in the mask and
> > > unmask ops so that the summary irq interrupt going to the CPU's
> > > interrupt controller doesn't trigger for the masked gpio interrupt.
> > >
> > > For a level triggered interrupt, the flow would be as follows: the pin
> > > controller sees the interrupt, latches the status into the status
> > > register, raises the summary irq to the CPU, summary irq handler runs
> > > and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
> > > interrupt, the interrupt handler runs, and finally unmask the interrupt.
> > > When the interrupt handler completes, we expect that the interrupt line
> > > level will go back to the deasserted state so the genirq code can unmask
> > > the interrupt without it triggering again.
> > >
> > > If we only mask the interrupt by clearing the "normal" status enable bit
> > > then we'll ack the interrupt but it will continue to show up as pending
> > > in the status register because the raw status bit is enabled, the
> > > hardware hasn't deasserted the line, and thus the asserted state latches
> > > into the status register again. When the hardware deasserts the
> > > interrupt the pin controller still thinks there is a pending unserviced
> > > level interrupt because it latched it earlier. This behavior causes
> > > software to see an extra interrupt for level type interrupts each time
> > > the interrupt is handled.
> > >
> > > Let's fix this by clearing the raw status enable bit for level type
> > > interrupts so that the hardware stops latching the status of the
> > > interrupt after we ack it. We don't do this for edge type interrupts
> > > because it seems that toggling the raw status enable bit for edge type
> > > interrupts causes spurious edge interrupts.
> > >
> > > Signed-off-by: Stephen Boyd <[email protected]>
> > > Reviewed-by: Douglas Anderson <[email protected]>
> > > Reviewed-by: Bjorn Andersson <[email protected]>
> > > Signed-off-by: Linus Walleij <[email protected]>
> > > Signed-off-by: Sasha Levin <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > drivers/pinctrl/qcom/pinctrl-msm.c | 24 ++++++++++++++++++++++++
> > > 1 file changed, 24 insertions(+)
> > >
> > > --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> > > +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> > > @@ -577,6 +577,29 @@ static void msm_gpio_irq_mask(struct irq
> > > spin_lock_irqsave(&pctrl->lock, flags);
> > >
> > > val = readl(pctrl->regs + g->intr_cfg_reg);
> > > + /*
> > > + * There are two bits that control interrupt forwarding to the CPU. The
> > > + * RAW_STATUS_EN bit causes the level or edge sensed on the line to be
> > > + * latched into the interrupt status register when the hardware detects
> > > + * an irq that it's configured for (either edge for edge type or level
> > > + * for level type irq). The 'non-raw' status enable bit causes the
> > > + * hardware to assert the summary interrupt to the CPU if the latched
> > > + * status bit is set. There's a bug though, the edge detection logic
> > > + * seems to have a problem where toggling the RAW_STATUS_EN bit may
> > > + * cause the status bit to latch spuriously when there isn't any edge
> > > + * so we can't touch that bit for edge type irqs and we have to keep
> > > + * the bit set anyway so that edges are latched while the line is masked.
> > > + *
> > > + * To make matters more complicated, leaving the RAW_STATUS_EN bit
> > > + * enabled all the time causes level interrupts to re-latch into the
> > > + * status register because the level is still present on the line after
> > > + * we ack it. We clear the raw status enable bit during mask here and
> > > + * set the bit on unmask so the interrupt can't latch into the hardware
> > > + * while it's masked.
> > > + */
> > > + if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
> > > + val &= ~BIT(g->intr_raw_status_bit);
> > > +
> > > val &= ~BIT(g->intr_enable_bit);
> > > writel(val, pctrl->regs + g->intr_cfg_reg);
> > >
> > > @@ -598,6 +621,7 @@ static void msm_gpio_irq_unmask(struct i
> > > spin_lock_irqsave(&pctrl->lock, flags);
> > >
> > > val = readl(pctrl->regs + g->intr_cfg_reg);
> > > + val |= BIT(g->intr_raw_status_bit);
> > > val |= BIT(g->intr_enable_bit);
> > > writel(val, pctrl->regs + g->intr_cfg_reg);
> > >
> > >
> > >
> >
> > Sigh, sorry, I caught this after I sent my initial all good email but
> > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> > apps that want to use it ask to enable it). I can't say why, I'm more
> > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> > done out of tree. I'll leave it up to you how to proceed given that I
> > can't run mainline :(

The patch corrects an issue that all level interrupts where delivered
twice, so if that breaks NFC then there's something quite broken in that
driver - or more likely something else broke.

Can you please do some level of investigation to see where in the stack
this broke, even if you can't run mainline.

>
> Ugh, I hate the qualcomm changes...
>

Noted...

Regards,
Bjorn

> Given the mess that all of the msm driver changes have, I'll go drop
> this patch from the stable tree as I don't want to deal with the
> fall-out for when people merge this to their device-specific trees.
>
> thanks for testing and letting me know about this.
>

2018-10-09 21:19:16

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/113] 4.4.160-stable review

On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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 Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
>

Build results:
total: 150 pass: 150 fail: 0
Qemu test results:
total: 286 pass: 286 fail: 0

The previously reported failure of
powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs
is no longer reported because CONFIG_OF_UNITTEST is now disabled.
This applies to all reports.

Thanks,
Guenter

2018-10-10 04:34:48

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/113] 4.4.160-stable review

On Tue, 9 Oct 2018 at 00:03, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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 Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.160-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

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.4.160-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: b5eb3855f86e32f79c8034c539bdaafa45832e8b
git describe: v4.4.159-114-gb5eb3855f86e
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.159-114-gb5eb3855f86e


No regressions (compared to build v4.4.159-114-g20e5d5bcb76b)


No fixes (compared to build v4.4.159-114-g20e5d5bcb76b)

2018-10-10 05:53:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/113] 4.4.160-stable review

On Tue, Oct 09, 2018 at 02:05:01PM -0700, Guenter Roeck wrote:
> On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.160 release.
> > There are 113 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 Oct 10 17:55:13 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 150 pass: 150 fail: 0
> Qemu test results:
> total: 286 pass: 286 fail: 0
>
> The previously reported failure of
> powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs
> is no longer reported because CONFIG_OF_UNITTEST is now disabled.
> This applies to all reports.

That's one way to fix the failing test :)

Seriously, hopefully Rob's fix for this lands soon.

Thanks for testing all of these and letting me know,

greg k-h

2018-10-10 06:57:35

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/113] 4.4.160-stable review


On 08/10/18 19:30, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 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 Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
All tests are passing for Tegra ...

Test results for stable-v4.4:
6 builds: 6 pass, 0 fail
12 boots: 12 pass, 0 fail

Linux version: 4.4.160-rc1-gb5eb385
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2018-10-10 07:13:54

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
<[email protected]> wrote:

> Sigh, sorry, I caught this after I sent my initial all good email but
> this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> apps that want to use it ask to enable it). I can't say why, I'm more
> than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> done out of tree. I'll leave it up to you how to proceed given that I
> can't run mainline :(

Which NFC driver is this?
Just want to make sure it looks sane.

Yours,
Linus Walleij

2018-10-10 07:54:22

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> <[email protected]> wrote:
>
> > Sigh, sorry, I caught this after I sent my initial all good email but
> > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> > apps that want to use it ask to enable it). I can't say why, I'm more
> > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> > done out of tree. I'll leave it up to you how to proceed given that I
> > can't run mainline :(
>
> Which NFC driver is this?
> Just want to make sure it looks sane.
>
> Yours,
> Linus Walleij

Hi Linus and Bjorn,

These two files should be it I believe:
https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/nq-nci.c
https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/ese/pn81a.c

Sorry I didn't get around to digging into this further today, I will try
to get to it in the morning.

Cheers,
Nathan

2018-10-10 12:12:49

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
<[email protected]> wrote:
> On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > <[email protected]> wrote:
> >
> > > Sigh, sorry, I caught this after I sent my initial all good email but
> > > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> > > apps that want to use it ask to enable it). I can't say why, I'm more
> > > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> > > done out of tree. I'll leave it up to you how to proceed given that I
> > > can't run mainline :(
> >
> > Which NFC driver is this?
> > Just want to make sure it looks sane.
> >
> > Yours,
> > Linus Walleij
>
> Hi Linus and Bjorn,
>
> These two files should be it I believe:
> https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/nq-nci.c
> https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/ese/pn81a.c
>
> Sorry I didn't get around to digging into this further today, I will try
> to get to it in the morning.

I'm confused. These are not in the mainline kernel and presumably
not in the stable kernel either.

So when you say "this commit breaks NFC on my Pixel 2 XL" you
mean that when you apply this commit to the android msm kernel,
which has a few other stable fixes backported, it breaks?

I know we have some kind of semi-tolerance for outoftree code
and we should preferrably try not to break it, especially not on
stable kernels, but the responsibility is sometimes just
overwhelming, sorry :(

Yours,
Linus Walleij

2018-10-10 12:46:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> <[email protected]> wrote:
> > On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > > <[email protected]> wrote:
> > >
> > > > Sigh, sorry, I caught this after I sent my initial all good email but
> > > > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> > > > apps that want to use it ask to enable it). I can't say why, I'm more
> > > > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> > > > done out of tree. I'll leave it up to you how to proceed given that I
> > > > can't run mainline :(
> > >
> > > Which NFC driver is this?
> > > Just want to make sure it looks sane.
> > >
> > > Yours,
> > > Linus Walleij
> >
> > Hi Linus and Bjorn,
> >
> > These two files should be it I believe:
> > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/nq-nci.c
> > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/ese/pn81a.c
> >
> > Sorry I didn't get around to digging into this further today, I will try
> > to get to it in the morning.
>
> I'm confused. These are not in the mainline kernel and presumably
> not in the stable kernel either.
>
> So when you say "this commit breaks NFC on my Pixel 2 XL" you
> mean that when you apply this commit to the android msm kernel,
> which has a few other stable fixes backported, it breaks?

If these drivers are obviously broken, I have no objection to merging
patches like this and telling qcom to fix their code. But if the issue
is more subtle, like change in behavior that is unanticipated, then I am
a bit more reluctant to take patches that break working systems.

It would be nice to figure out what is going wrong here as I think the
drivers above are being submitted upstream right now, correct?

thanks,

greg k-h

2018-10-10 14:41:11

by Sasha Levin

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
>On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
>> On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
>> <[email protected]> wrote:
>> > On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
>> > > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
>> > > <[email protected]> wrote:
>> > >
>> > > > Sigh, sorry, I caught this after I sent my initial all good email but
>> > > > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
>> > > > apps that want to use it ask to enable it). I can't say why, I'm more
>> > > > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
>> > > > done out of tree. I'll leave it up to you how to proceed given that I
>> > > > can't run mainline :(
>> > >
>> > > Which NFC driver is this?
>> > > Just want to make sure it looks sane.
>> > >
>> > > Yours,
>> > > Linus Walleij
>> >
>> > Hi Linus and Bjorn,
>> >
>> > These two files should be it I believe:
>> > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/nq-nci.c
>> > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/ese/pn81a.c
>> >
>> > Sorry I didn't get around to digging into this further today, I will try
>> > to get to it in the morning.
>>
>> I'm confused. These are not in the mainline kernel and presumably
>> not in the stable kernel either.
>>
>> So when you say "this commit breaks NFC on my Pixel 2 XL" you
>> mean that when you apply this commit to the android msm kernel,
>> which has a few other stable fixes backported, it breaks?
>
>If these drivers are obviously broken, I have no objection to merging
>patches like this and telling qcom to fix their code. But if the issue
>is more subtle, like change in behavior that is unanticipated, then I am
>a bit more reluctant to take patches that break working systems.

I think that this is a dangerous precedent where we won't take a patch
that actually fixes in-tree code because it breaks out-of-tree code.

I understand your concern: it's possible that this patch is actually
broken, and we only see the breakage, by chance, with out-of-tree code.
We also don't want to subtly break out-of-tree users for no good reason.

Maybe a better solution is to give a courtesy heads-up to Qualcomm and
queue this patch to the next release (or maybe the one after the next).
If they can show that the patch is broken we can go ahead and revert/fix
it, but if it's not - it won't be indefinitely stuck out of the stable
tree while we try debugging Qualcomm's out-of-tree code.


--
Thanks,
Sasha

2018-10-10 15:04:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

On Wed, Oct 10, 2018 at 10:39:59AM -0400, Sasha Levin wrote:
> On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
> > On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> > > On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> > > <[email protected]> wrote:
> > > > On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > > > > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > > > > <[email protected]> wrote:
> > > > >
> > > > > > Sigh, sorry, I caught this after I sent my initial all good email but
> > > > > > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> > > > > > apps that want to use it ask to enable it). I can't say why, I'm more
> > > > > > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> > > > > > done out of tree. I'll leave it up to you how to proceed given that I
> > > > > > can't run mainline :(
> > > > >
> > > > > Which NFC driver is this?
> > > > > Just want to make sure it looks sane.
> > > > >
> > > > > Yours,
> > > > > Linus Walleij
> > > >
> > > > Hi Linus and Bjorn,
> > > >
> > > > These two files should be it I believe:
> > > > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/nq-nci.c
> > > > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/ese/pn81a.c
> > > >
> > > > Sorry I didn't get around to digging into this further today, I will try
> > > > to get to it in the morning.
> > >
> > > I'm confused. These are not in the mainline kernel and presumably
> > > not in the stable kernel either.
> > >
> > > So when you say "this commit breaks NFC on my Pixel 2 XL" you
> > > mean that when you apply this commit to the android msm kernel,
> > > which has a few other stable fixes backported, it breaks?
> >
> > If these drivers are obviously broken, I have no objection to merging
> > patches like this and telling qcom to fix their code. But if the issue
> > is more subtle, like change in behavior that is unanticipated, then I am
> > a bit more reluctant to take patches that break working systems.
>
> I think that this is a dangerous precedent where we won't take a patch
> that actually fixes in-tree code because it breaks out-of-tree code.

Sorry, I don't mean for it to look that way at all. That's not what I
was meaning to imply.

> I understand your concern: it's possible that this patch is actually
> broken, and we only see the breakage, by chance, with out-of-tree code.
> We also don't want to subtly break out-of-tree users for no good reason.
>
> Maybe a better solution is to give a courtesy heads-up to Qualcomm and
> queue this patch to the next release (or maybe the one after the next).
> If they can show that the patch is broken we can go ahead and revert/fix
> it, but if it's not - it won't be indefinitely stuck out of the stable
> tree while we try debugging Qualcomm's out-of-tree code.

I would like to see what the developers here can find out first about
the out-of-tree code to see where the fault lies. I have no problem
breaking out-of-tree code if it is obviously wrong, but the interaction
with the pinctl subsytem and various older drivers is very touchy at
times, and we have had to revert things to keep everyone happy.

So there is some history here, and I want to make sure who is to blame
first. I lay odds on the msm out of tree driver :)

thanks,

gre k-h