2018-03-19 20:28:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 000/134] 4.4.123-stable review

This is the start of the stable review cycle for the 4.4.123 release.
There are 134 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 Mar 21 17:18:04 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.123-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.123-rc1

Jann Horn <[email protected]>
bpf: fix incorrect sign extension in check_alu_op()

Srinath Mannam <[email protected]>
usb: gadget: bdc: 64-bit pointer capability check

Wei Yongjun <[email protected]>
USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()

Nikolay Borisov <[email protected]>
btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device

Hans van Kranenburg <[email protected]>
btrfs: alloc_chunk: fix DUP stripe size handling

Adam Ford <[email protected]>
ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

Johannes Thumshirn <[email protected]>
scsi: sg: only check for dxfer_len greater than 256M

Johannes Thumshirn <[email protected]>
scsi: sg: fix static checker warning in sg_is_valid_dxfer

Johannes Thumshirn <[email protected]>
scsi: sg: fix SG_DXFER_FROM_DEV transfers

Ard Biesheuvel <[email protected]>
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis

Tejun Heo <[email protected]>
fs/aio: Use RCU accessors for kioctx_table->table[]

Tejun Heo <[email protected]>
fs/aio: Add explicit RCU grace period when freeing kioctx

Al Viro <[email protected]>
lock_parent() needs to recheck if dentry got __dentry_kill'ed under it

Eric W. Biederman <[email protected]>
fs: Teach path_connected to handle nfs filesystems with multiple roots.

Michel Dänzer <[email protected]>
drm/amdgpu/dce: Don't turn off DP sink when disconnected

Takashi Iwai <[email protected]>
ALSA: seq: Clear client entry before deleting else at closing

Takashi Iwai <[email protected]>
ALSA: seq: Fix possible UAF in snd_seq_check_queue()

Takashi Iwai <[email protected]>
ALSA: hda - Revert power_save option default value

Takashi Iwai <[email protected]>
ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()

Toshi Kani <[email protected]>
x86/mm: Fix vmalloc_fault to use pXd_large

Andy Lutomirski <[email protected]>
x86/vm86/32: Fix POPF emulation

Andy Lutomirski <[email protected]>
selftests/x86/entry_from_vm86: Add test cases for POPF

Ricardo Neri <[email protected]>
selftests/x86: Add tests for the STR and SLDT instructions

Ricardo Neri <[email protected]>
selftests/x86: Add tests for User-Mode Instruction Prevention

Andy Lutomirski <[email protected]>
selftests/x86/entry_from_vm86: Exit with 1 if we fail

Mimi Zohar <[email protected]>
ima: relax requiring a file signature for new files with zero length

SeongJae Park <[email protected]>
rcutorture/configinit: Fix build directory error message

Mahesh Bandewar <[email protected]>
ipvlan: add L2 check for packets arriving via virtual devices

Dan Carpenter <[email protected]>
ASoC: nuc900: Fix a loop timeout test

Luca Coelho <[email protected]>
mac80211: remove BUG() when interface type is invalid

Adiel Aloni <[email protected]>
mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED

Chris Wilson <[email protected]>
agp/intel: Flush all chipset writes after updating the GGTT

Yong Zhao <[email protected]>
drm/amdkfd: Fix memory leaks in kfd topology

Stephen Hemminger <[email protected]>
veth: set peer GSO values

Dan Carpenter <[email protected]>
media: cpia2: Fix a couple off by one bugs

Xose Vazquez Perez <[email protected]>
scsi: dh: add new rdac devices

Xose Vazquez Perez <[email protected]>
scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

Bart Van Assche <[email protected]>
scsi: core: scsi_get_device_flags_keyed(): Always return device flags

Tobias Jordan <[email protected]>
spi: sun6i: disable/unprepare clocks on remove

Julien BOIBESSOT <[email protected]>
tools/usbip: fixes build with musl libc toolchain

Ben Greear <[email protected]>
ath10k: fix invalid STS_CAP_OFFSET_MASK

Srinivas Kandagatla <[email protected]>
clk: qcom: msm8916: fix mnd_width for codec_digcodec

Rafael J. Wysocki <[email protected]>
cpufreq: Fix governor module removal race

Manikanta Pubbisetty <[email protected]>
ath10k: update tdls teardown state to target

Jagdish Gediya <[email protected]>
mtd: nand: ifc: update bufnum mask for ver >= 2.0.0

Andrew F. Davis <[email protected]>
ARM: dts: omap3-n900: Fix the audio CODEC's reset pin

Andrew F. Davis <[email protected]>
ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin

Miquel Raynal <[email protected]>
mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()

Lorenzo Colitti <[email protected]>
net: xfrm: allow clearing socket xfrm policies.

Luis R. Rodriguez <[email protected]>
test_firmware: fix setting old custom fw path back on exit

Paul E. McKenney <[email protected]>
sched: Stop resched_cpu() from sending IPIs to offline CPUs

Paul E. McKenney <[email protected]>
sched: Stop switched_to_rt() from sending IPIs to offline CPUs

Simon Shields <[email protected]>
ARM: dts: exynos: Correct Trats2 panel reset line

Jiri Kosina <[email protected]>
HID: elo: clear BTN_LEFT mapping

Ville Syrjälä <[email protected]>
video/hdmi: Allow "empty" HDMI infoframes

Jani Nikula <[email protected]>
drm/edid: set ELD connector type in drm_edid_to_eld()

Dedy Lansky <[email protected]>
wil6210: fix memory access violation in wil_memcpy_from/toio_32

Laxman Dewangan <[email protected]>
pwm: tegra: Increase precision in PWM rate calculation

Masami Hiramatsu <[email protected]>
kprobes/x86: Set kprobes pages read-only

Masami Hiramatsu <[email protected]>
kprobes/x86: Fix kprobe-booster not to boost far call instructions

Hannes Reinecke <[email protected]>
scsi: sg: close race condition in sg_remove_sfp_usercontext()

Johannes Thumshirn <[email protected]>
scsi: sg: check for valid direction before starting the request

David Carrillo-Cisneros <[email protected]>
perf session: Don't rely on evlist in pipe mode

David Carrillo-Cisneros <[email protected]>
perf inject: Copy events when reordering events in pipe mode

Mark Rutland <[email protected]>
drivers/perf: arm_pmu: handle no platform_device

Yuyang Du <[email protected]>
usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()

John Stultz <[email protected]>
usb: dwc2: Make sure we disconnect the gadget state

NeilBrown <[email protected]>
md/raid6: Fix anomily when recovering a single device in RAID6.

Vincent Stehlé <[email protected]>
regulator: isl9305: fix array size

Aleksandar Markovic <[email protected]>
MIPS: r2-on-r6-emu: Clear BLTZALL and BGEZALL debugfs counters

Leonid Yegoshin <[email protected]>
MIPS: r2-on-r6-emu: Fix BLEZL and BGTZL identification

David Daney <[email protected]>
MIPS: BPF: Fix multiple problems in JIT skb access helpers.

David Daney <[email protected]>
MIPS: BPF: Quit clobbering callee saved registers in JIT code.

Mike Leach <[email protected]>
coresight: Fixes coresight DT parse to get correct output port ID.

Christopher James Halse Rogers <[email protected]>
drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)

Christopher James Halse Rogers <[email protected]>
drm/radeon: Fail fb creation from imported dma-bufs.

Liam Beguin <[email protected]>
video: ARM CLCD: fix dma allocation size

Nate Watterson <[email protected]>
iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range

John Johansen <[email protected]>
apparmor: Make path_max parameter readonly

Mauricio Faria de Oliveira <[email protected]>
scsi: ses: don't get power status of SES device slot on probe

Phil Turnbull <[email protected]>
fm10k: correctly check if interface is removed

Takashi Sakamoto <[email protected]>
ALSA: firewire-digi00x: handle all MIDI messages on streaming packets

Jan Kara <[email protected]>
reiserfs: Make cancel_old_flush() reliable

Geert Uytterhoeven <[email protected]>
ARM: dts: koelsch: Correct clock frequency of X2 DU clock input

Andrew Lunn <[email protected]>
net/faraday: Add missing include of of.h

Anton Blanchard <[email protected]>
powerpc: Avoid taking a data miss on every userspace instruction miss

Geert Uytterhoeven <[email protected]>
ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks

Geert Uytterhoeven <[email protected]>
ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks

Dan Carpenter <[email protected]>
NFC: nfcmrvl: double free on error path

Tobias Klauser <[email protected]>
NFC: nfcmrvl: Include unaligned.h instead of access_ok.h

Felix Manlunas <[email protected]>
vxlan: vxlan dev should inherit lowerdev's gso_max_size

Sinclair Yeh <[email protected]>
drm/vmwgfx: Fixes to vmwgfx_fb

Samuel Thibault <[email protected]>
braille-console: Fix value returned by _braille_console_setup

Aneesh Kumar K.V <[email protected]>
powerpc/mm/hugetlb: Filter out hugepage size not supported by page table layout

Eric Dumazet <[email protected]>
bonding: refine bond_fold_stats() wrap detection

Jaegeuk Kim <[email protected]>
f2fs: relax node version check for victim data in gc

Roger Quadros <[email protected]>
ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

Shaohua Li <[email protected]>
blk-throttle: make sure expire time isn't too big

Kirill A. Shutemov <[email protected]>
mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative()

Shikhar Dogra <[email protected]>
driver: (adm1275) set the m,b and R coefficients correctly for power

Jiada Wang <[email protected]>
dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

Gao Feng <[email protected]>
tcp: sysctl: Fix a race to avoid unexpected 0 window from space

Akinobu Mita <[email protected]>
spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer

Kuninori Morimoto <[email protected]>
ASoC: rcar: ssi: don't set SSICR.CKDV = 000 with SSIWSR.CONT

Davide Caratti <[email protected]>
sched: act_csum: don't mangle TCP and UDP GSO packets

Javier Martinez Canillas <[email protected]>
Input: qt1070 - add OF device ID table

Tom Hromatka <[email protected]>
sysrq: Reset the watchdog timers while displaying high-resolution timers

David Engraf <[email protected]>
timers, sched_clock: Update timeout for clock wrap

Janusz Krzysztofik <[email protected]>
media: i2c/soc_camera: fix ov6650 sensor getting wrong clock

Brian King <[email protected]>
scsi: ipr: Fix missed EH wakeup

Anton Sviridenko <[email protected]>
solo6x10: release vb2 buffers in solo_stop_streaming()

Rob Herring <[email protected]>
of: fix of_device_get_modalias returned length when truncating buffers

Andreas Pape <[email protected]>
batman-adv: handle race condition for claims between gateways

Linus Walleij <[email protected]>
ARM: dts: Adjust moxart IRQ controller and flags

Andrey Vagin <[email protected]>
net/8021q: create device with all possible features in wanted_features

Tomasz Kramkowski <[email protected]>
HID: clamp input to logical range if no null state

Kefeng Wang <[email protected]>
perf probe: Return errno when not hitting any event

Mohammed Shafi Shajakhan <[email protected]>
ath10k: disallow DFS simulation if DFS channel is not enabled

Chris Wilson <[email protected]>
drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)

Quan Nguyen <[email protected]>
drivers: net: xgene: Fix hardware checksum setting

Stephane Eranian <[email protected]>
perf tools: Make perf_event__synthesize_mmap_events() scale

Lihong Yang <[email protected]>
i40e: fix ethtool to get EEPROM data from X722 interface

Aaron Salter <[email protected]>
i40e: Acquire NVM lock before reads on all devices

Changbin Du <[email protected]>
perf sort: Fix segfault with basic block 'cycles' sort dimension

Alexander Potapenko <[email protected]>
selinux: check for address length in selinux_socket_bind()

Prarit Bhargava <[email protected]>
PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

Thomas Petazzoni <[email protected]>
net: mvpp2: set dma mask and coherent dma mask on PPv2.2

Mohammed Shafi Shajakhan <[email protected]>
ath10k: fix a warning during channel switch with multiple vaps

Gabriel Krisman Bertazi <[email protected]>
drm: qxl: Don't alloc fbdev if emulation is not supported

Valtteri Heikkilä <[email protected]>
HID: reject input outside logical range only if null state is set

Colin Ian King <[email protected]>
staging: wilc1000: add check for kmalloc allocation failure.

Varsha Rao <[email protected]>
staging: speakup: Replace BUG_ON() with WARN_ON().

H. Nikolaus Schaller <[email protected]>
Input: tsc2007 - check for presence and power down tsc2007 during probe

Hou Tao <[email protected]>
blkcg: fix double free of new_blkg in blkcg_init_queue


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

Diffstat:

Makefile | 4 +-
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++
arch/arm/boot/dts/moxart-uc7112lx.dts | 2 +-
arch/arm/boot/dts/moxart.dtsi | 17 +--
arch/arm/boot/dts/omap3-n900.dts | 4 +-
arch/arm/boot/dts/r8a7790.dtsi | 7 +-
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 7 +-
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 +
arch/mips/kernel/mips-r2-to-r6-emul.c | 16 ++-
arch/mips/net/bpf_jit.c | 16 ++-
arch/mips/net/bpf_jit_asm.S | 23 ++--
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/mm/hugetlbpage.c | 18 ++++
arch/x86/kernel/kprobes/core.c | 6 ++
arch/x86/kernel/kprobes/opt.c | 3 +
arch/x86/kernel/vm86_32.c | 3 +-
arch/x86/mm/fault.c | 6 +-
block/blk-cgroup.c | 4 +-
block/blk-throttle.c | 11 ++
drivers/char/agp/intel-gtt.c | 2 +
drivers/clk/qcom/gcc-msm8916.c | 1 +
drivers/cpufreq/cpufreq.c | 6 ++
drivers/dma/imx-sdma.c | 17 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 31 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++
drivers/gpu/drm/drm_edid.c | 9 +-
drivers/gpu/drm/drm_irq.c | 14 ++-
drivers/gpu/drm/qxl/qxl_fb.c | 9 +-
drivers/gpu/drm/radeon/radeon_display.c | 6 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +-
drivers/hid/hid-elo.c | 6 ++
drivers/hid/hid-input.c | 20 ++--
drivers/hwmon/pmbus/adm1275.c | 4 +-
drivers/hwtracing/coresight/of_coresight.c | 2 +-
drivers/input/keyboard/qt1070.c | 9 ++
drivers/input/touchscreen/tsc2007.c | 8 ++
drivers/iommu/iova.c | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 9 +-
drivers/md/raid5.c | 13 ++-
drivers/media/i2c/soc_camera/ov6650.c | 2 +-
drivers/media/pci/solo6x10/solo6x10-v4l2.c | 11 ++
drivers/media/usb/cpia2/cpia2_v4l.c | 4 +-
drivers/misc/enclosure.c | 7 +-
drivers/mtd/nand/fsl_ifc_nand.c | 7 ++
drivers/mtd/nand/nand_base.c | 9 +-
drivers/net/bonding/bond_main.c | 11 +-
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
drivers/net/ethernet/faraday/ftgmac100.c | 1 +
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 5 +
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 12 +--
drivers/net/ethernet/marvell/mvpp2.c | 14 +++
drivers/net/ipvlan/ipvlan_core.c | 4 +
drivers/net/veth.c | 3 +
drivers/net/vxlan.c | 5 +
drivers/net/wireless/ath/ath10k/debug.c | 9 ++
drivers/net/wireless/ath/ath10k/mac.c | 12 ++-
drivers/net/wireless/ath/ath10k/wmi.h | 3 +-
drivers/net/wireless/ath/wil6210/main.c | 20 +++-
drivers/net/wireless/mac80211_hwsim.c | 17 +--
drivers/nfc/nfcmrvl/fw_dnld.c | 2 +-
drivers/nfc/nfcmrvl/spi.c | 5 +-
drivers/of/device.c | 2 +-
drivers/pci/pci-driver.c | 2 -
drivers/perf/arm_pmu.c | 12 ++-
drivers/pwm/pwm-tegra.c | 7 +-
drivers/scsi/ipr.c | 16 ++-
drivers/scsi/scsi_devinfo.c | 9 +-
drivers/scsi/scsi_dh.c | 5 +-
drivers/scsi/ses.c | 1 -
drivers/scsi/sg.c | 35 +++---
drivers/spi/spi-omap2-mcspi.c | 9 +-
drivers/spi/spi-sun6i.c | 2 +-
drivers/staging/speakup/kobjects.c | 8 +-
drivers/staging/wilc1000/host_interface.c | 2 +
drivers/usb/dwc2/hcd.c | 1 +
drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +-
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
drivers/usb/gadget/udc/dummy_hcd.c | 20 ++--
drivers/video/fbdev/amba-clcd.c | 4 +-
drivers/video/hdmi.c | 51 +++++----
fs/aio.c | 44 +++++---
fs/btrfs/volumes.c | 12 ++-
fs/dcache.c | 11 +-
fs/f2fs/gc.c | 6 +-
fs/namei.c | 5 +-
fs/nfs/super.c | 2 +
fs/reiserfs/journal.c | 2 +-
fs/reiserfs/reiserfs.h | 1 +
fs/reiserfs/super.c | 21 ++--
include/linux/fs.h | 1 +
include/linux/pagemap.h | 4 +-
include/linux/platform_data/isl9305.h | 2 +-
include/net/tcp.h | 8 +-
kernel/bpf/verifier.c | 3 +-
kernel/printk/braille.c | 15 +--
kernel/printk/braille.h | 13 ++-
kernel/sched/core.c | 3 +-
kernel/sched/rt.c | 2 +-
kernel/time/sched_clock.c | 5 +
kernel/time/timer_list.c | 6 ++
net/8021q/vlan_dev.c | 3 +-
net/batman-adv/bridge_loop_avoidance.c | 20 +++-
net/mac80211/iface.c | 2 +-
net/sched/act_csum.c | 12 +++
net/xfrm/xfrm_policy.c | 2 +-
net/xfrm/xfrm_state.c | 7 ++
security/apparmor/lsm.c | 2 +-
security/integrity/ima/ima_appraise.c | 3 +-
security/selinux/hooks.c | 8 ++
sound/core/oss/pcm_oss.c | 10 +-
sound/core/seq/seq_clientmgr.c | 4 +-
sound/core/seq/seq_prioq.c | 28 ++---
sound/core/seq/seq_prioq.h | 6 +-
sound/core/seq/seq_queue.c | 28 ++---
sound/firewire/digi00x/amdtp-dot.c | 55 ++++++----
sound/pci/hda/hda_intel.c | 9 +-
sound/soc/nuc900/nuc900-ac97.c | 4 +-
sound/soc/sh/rcar/ssi.c | 9 ++
tools/perf/builtin-probe.c | 6 +-
tools/perf/util/event.c | 4 +-
tools/perf/util/ordered-events.c | 3 +-
tools/perf/util/session.c | 17 ++-
tools/perf/util/sort.c | 5 +
tools/testing/selftests/firmware/fw_filesystem.sh | 5 +-
.../testing/selftests/rcutorture/bin/configinit.sh | 2 +-
tools/testing/selftests/x86/entry_from_vm86.c | 117 ++++++++++++++++++++-
tools/usb/usbip/src/usbipd.c | 2 +-
133 files changed, 910 insertions(+), 338 deletions(-)




2018-03-19 18:14:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 011/134] perf sort: Fix segfault with basic block cycles sort dimension

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

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

From: Changbin Du <[email protected]>


[ Upstream commit 4b0b3aa6a2756e6115fdf275c521e4552a7082f3 ]

Skip the sample which doesn't have branch_info to avoid segmentation
fault:

The fault can be reproduced by:

perf record -a
perf report -F cycles

Signed-off-by: Changbin Du <[email protected]>
Tested-by: Arnaldo Carvalho de Melo <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Fixes: 0e332f033a82 ("perf tools: Add support for cycles, weight branch_info field")
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/util/sort.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -604,6 +604,9 @@ static int hist_entry__mispredict_snprin
static int64_t
sort__cycles_cmp(struct hist_entry *left, struct hist_entry *right)
{
+ if (!left->branch_info || !right->branch_info)
+ return cmp_null(left->branch_info, right->branch_info);
+
return left->branch_info->flags.cycles -
right->branch_info->flags.cycles;
}
@@ -611,6 +614,8 @@ sort__cycles_cmp(struct hist_entry *left
static int hist_entry__cycles_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
+ if (!he->branch_info)
+ return scnprintf(bf, size, "%-.*s", width, "N/A");
if (he->branch_info->flags.cycles == 0)
return repsep_snprintf(bf, size, "%-*s", width, "-");
return repsep_snprintf(bf, size, "%-*hd", width,



2018-03-19 18:14:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 017/134] ath10k: disallow DFS simulation if DFS channel is not enabled

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

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

From: Mohammed Shafi Shajakhan <[email protected]>


[ Upstream commit ca07baab0b1e627ae1d4a55d190fb1c9d32a3445 ]

If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall
not be available for use even though the hardware may have the capability
to support DFS. With this configuration (DFS disabled in hostapd) trying to
bring up ath10k device in DFS channel for AP mode fails and trying to
simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining
invalid channel and this should be avoided in the driver itself rather than
false propogating RADAR detection to mac80211/cfg80211. Fix this by
checking for the first vif 'is_started' state(should work for client mode
as well) as all the vifs shall be configured for the same channel

sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar

WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[<c022f2d4>] (warn_slowpath_null) from
[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
[<c0242320>] (process_one_work+0x20c/0x32c)

WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc
Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
[<c022f2d4>] (warn_slowpath_null) from
[<bf72dab8>] (cfg80211_radar_event+0x24/0x60 [cfg80211])
[<bf72dab8>] (cfg80211_radar_event [cfg80211]) from
[<bf7813e0>] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
[<bf7813e0>] (ieee80211_dfs_radar_detected_work [mac80211]) from
[<c0242320>] (process_one_work+0x20c/0x32c)

Signed-off-by: Mohammed Shafi Shajakhan <[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/debug.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1892,6 +1892,15 @@ static ssize_t ath10k_write_simulate_rad
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
+ struct ath10k_vif *arvif;
+
+ /* Just check for for the first vif alone, as all the vifs will be
+ * sharing the same channel and if the channel is disabled, all the
+ * vifs will share the same 'is_started' state.
+ */
+ arvif = list_first_entry(&ar->arvifs, typeof(*arvif), list);
+ if (!arvif->is_started)
+ return -EINVAL;

ieee80211_radar_detected(ar->hw);




2018-03-19 18:14:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 025/134] scsi: ipr: Fix missed EH wakeup

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

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

From: Brian King <[email protected]>


[ Upstream commit 66a0d59cdd12546ddf01d229de28b07ccf6d637f ]

Following a command abort or device reset, ipr's EH handlers wait for
the commands getting aborted to get sent back from the adapter prior to
returning from the EH handler. This fixes up some cases where the
completion handler was not getting called, which would have resulted in
the EH thread waiting until it timed out, greatly extending EH time.

Signed-off-by: Brian King <[email protected]>
Reviewed-by: Wendy Xiong <[email protected]>
Tested-by: Wendy Xiong <[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/ipr.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)

--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -835,8 +835,10 @@ static void ipr_sata_eh_done(struct ipr_

qc->err_mask |= AC_ERR_OTHER;
sata_port->ioasa.status |= ATA_BUSY;
- list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
ata_qc_complete(qc);
+ if (ipr_cmd->eh_comp)
+ complete(ipr_cmd->eh_comp);
+ list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
}

/**
@@ -5864,8 +5866,10 @@ static void ipr_erp_done(struct ipr_cmnd
res->in_erp = 0;
}
scsi_dma_unmap(ipr_cmd->scsi_cmd);
- list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
scsi_cmd->scsi_done(scsi_cmd);
+ if (ipr_cmd->eh_comp)
+ complete(ipr_cmd->eh_comp);
+ list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
}

/**
@@ -6255,8 +6259,10 @@ static void ipr_erp_start(struct ipr_ioa
}

scsi_dma_unmap(ipr_cmd->scsi_cmd);
- list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
scsi_cmd->scsi_done(scsi_cmd);
+ if (ipr_cmd->eh_comp)
+ complete(ipr_cmd->eh_comp);
+ list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
}

/**
@@ -6282,8 +6288,10 @@ static void ipr_scsi_done(struct ipr_cmn
scsi_dma_unmap(scsi_cmd);

spin_lock_irqsave(ipr_cmd->hrrq->lock, lock_flags);
- list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
scsi_cmd->scsi_done(scsi_cmd);
+ if (ipr_cmd->eh_comp)
+ complete(ipr_cmd->eh_comp);
+ list_add_tail(&ipr_cmd->queue, &ipr_cmd->hrrq->hrrq_free_q);
spin_unlock_irqrestore(ipr_cmd->hrrq->lock, lock_flags);
} else {
spin_lock_irqsave(ioa_cfg->host->host_lock, lock_flags);



2018-03-19 18:14:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 019/134] HID: clamp input to logical range if no null state

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

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

From: Tomasz Kramkowski <[email protected]>


[ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ]

This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.

This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."

This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.

This patch expands on commit 3f3752705dbd ("HID: reject input outside
logical range only if null state is set").

[1]: http://lkml.kernel.org/r/[email protected]
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp

Signed-off-by: Tomasz Kramkowski <[email protected]>
Acked-by: Benjamin Tissoires <[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-input.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)

--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1128,19 +1128,26 @@ void hidinput_hid_event(struct hid_devic

/*
* Ignore out-of-range values as per HID specification,
- * section 5.10 and 6.2.25.
+ * section 5.10 and 6.2.25, when NULL state bit is present.
+ * When it's not, clamp the value to match Microsoft's input
+ * driver as mentioned in "Required HID usages for digitizers":
+ * https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85).asp
*
* The logical_minimum < logical_maximum check is done so that we
* don't unintentionally discard values sent by devices which
* don't specify logical min and max.
*/
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
- (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
- (field->logical_minimum < field->logical_maximum) &&
- (value < field->logical_minimum ||
- value > field->logical_maximum)) {
- dbg_hid("Ignoring out-of-range value %x\n", value);
- return;
+ (field->logical_minimum < field->logical_maximum)) {
+ if (field->flags & HID_MAIN_ITEM_NULL_STATE &&
+ (value < field->logical_minimum ||
+ value > field->logical_maximum)) {
+ dbg_hid("Ignoring out-of-range value %x\n", value);
+ return;
+ }
+ value = clamp(value,
+ field->logical_minimum,
+ field->logical_maximum);
}

/*



2018-03-19 18:14:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 024/134] [media] solo6x10: release vb2 buffers in solo_stop_streaming()

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

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

From: Anton Sviridenko <[email protected]>


[ Upstream commit 6e4c8480bd2eb95309ad3c875e11d2cad98f9188 ]

Fixes warning that appears in dmesg after closing V4L2 userspace
application that plays video from the display device
(first device from V4L2 device nodes provided by solo, usually /dev/video0
when no other V4L2 devices are present). Encoder device nodes are not
affected. Can be reproduced by starting and closing

ffplay -f video4linux2 /dev/video0

[ 8130.281251] ------------[ cut here ]------------
[ 8130.281256] WARNING: CPU: 1 PID: 20414 at drivers/media/v4l2-core/videobuf2-core.c:1651 __vb2_queue_cancel+0x14b/0x230
[ 8130.281257] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat solo6x10 x86_pkg_temp_thermal vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O)
[ 8130.281264] CPU: 1 PID: 20414 Comm: ffplay Tainted: G O 4.10.0-gentoo #1
[ 8130.281264] Hardware name: ASUS All Series/B85M-E, BIOS 2301 03/30/2015
[ 8130.281265] Call Trace:
[ 8130.281267] dump_stack+0x4f/0x72
[ 8130.281270] __warn+0xc7/0xf0
[ 8130.281271] warn_slowpath_null+0x18/0x20
[ 8130.281272] __vb2_queue_cancel+0x14b/0x230
[ 8130.281273] vb2_core_streamoff+0x23/0x90
[ 8130.281275] vb2_streamoff+0x24/0x50
[ 8130.281276] vb2_ioctl_streamoff+0x3d/0x50
[ 8130.281278] v4l_streamoff+0x15/0x20
[ 8130.281279] __video_do_ioctl+0x25e/0x2f0
[ 8130.281280] video_usercopy+0x279/0x520
[ 8130.281282] ? v4l_enum_fmt+0x1330/0x1330
[ 8130.281285] ? unmap_region+0xdf/0x110
[ 8130.281285] video_ioctl2+0x10/0x20
[ 8130.281286] v4l2_ioctl+0xce/0xe0
[ 8130.281289] do_vfs_ioctl+0x8b/0x5b0
[ 8130.281290] ? __fget+0x72/0xa0
[ 8130.281291] SyS_ioctl+0x74/0x80
[ 8130.281294] entry_SYSCALL_64_fastpath+0x13/0x94
[ 8130.281295] RIP: 0033:0x7ff86fee6b27
[ 8130.281296] RSP: 002b:00007ffe467f6a08 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 8130.281297] RAX: ffffffffffffffda RBX: 00000000d1a4d788 RCX: 00007ff86fee6b27
[ 8130.281297] RDX: 00007ffe467f6a14 RSI: 0000000040045613 RDI: 0000000000000006
[ 8130.281298] RBP: 000000000373f8d0 R08: 00000000ffffffff R09: 00007ff860001140
[ 8130.281298] R10: 0000000000000243 R11: 0000000000000246 R12: 0000000000000000
[ 8130.281299] R13: 00000000000000a0 R14: 00007ffe467f6530 R15: 0000000001f32228
[ 8130.281300] ---[ end trace 00695dc96be646e7 ]---

Signed-off-by: Anton Sviridenko <[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/pci/solo6x10/solo6x10-v4l2.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c
@@ -342,6 +342,17 @@ static void solo_stop_streaming(struct v
struct solo_dev *solo_dev = vb2_get_drv_priv(q);

solo_stop_thread(solo_dev);
+
+ spin_lock(&solo_dev->slock);
+ while (!list_empty(&solo_dev->vidq_active)) {
+ struct solo_vb2_buf *buf = list_entry(
+ solo_dev->vidq_active.next,
+ struct solo_vb2_buf, list);
+
+ list_del(&buf->list);
+ vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+ }
+ spin_unlock(&solo_dev->slock);
INIT_LIST_HEAD(&solo_dev->vidq_active);
}




2018-03-19 18:14:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 030/134] sched: act_csum: dont mangle TCP and UDP GSO packets

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

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

From: Davide Caratti <[email protected]>


[ Upstream commit add641e7dee31b36aee83412c29e39dd1f5e0c9c ]

after act_csum computes the checksum on skbs carrying GSO TCP/UDP packets,
subsequent segmentation fails because skb_needs_check(skb, true) returns
true. Because of that, skb_warn_bad_offload() is invoked and the following
message is displayed:

WARNING: CPU: 3 PID: 28 at net/core/dev.c:2553 skb_warn_bad_offload+0xf0/0xfd
<...>

[<ffffffff8171f486>] skb_warn_bad_offload+0xf0/0xfd
[<ffffffff8161304c>] __skb_gso_segment+0xec/0x110
[<ffffffff8161340d>] validate_xmit_skb+0x12d/0x2b0
[<ffffffff816135d2>] validate_xmit_skb_list+0x42/0x70
[<ffffffff8163c560>] sch_direct_xmit+0xd0/0x1b0
[<ffffffff8163c760>] __qdisc_run+0x120/0x270
[<ffffffff81613b3d>] __dev_queue_xmit+0x23d/0x690
[<ffffffff81613fa0>] dev_queue_xmit+0x10/0x20

Since GSO is able to compute checksum on individual segments of such skbs,
we can simply skip mangling the packet.

Signed-off-by: Davide Caratti <[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]>
---
net/sched/act_csum.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -175,6 +175,9 @@ static int tcf_csum_ipv4_tcp(struct sk_b
struct tcphdr *tcph;
const struct iphdr *iph;

+ if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4)
+ return 1;
+
tcph = tcf_csum_skb_nextlayer(skb, ihl, ipl, sizeof(*tcph));
if (tcph == NULL)
return 0;
@@ -196,6 +199,9 @@ static int tcf_csum_ipv6_tcp(struct sk_b
struct tcphdr *tcph;
const struct ipv6hdr *ip6h;

+ if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
+ return 1;
+
tcph = tcf_csum_skb_nextlayer(skb, ihl, ipl, sizeof(*tcph));
if (tcph == NULL)
return 0;
@@ -219,6 +225,9 @@ static int tcf_csum_ipv4_udp(struct sk_b
const struct iphdr *iph;
u16 ul;

+ if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ return 1;
+
/*
* Support both UDP and UDPLITE checksum algorithms, Don't use
* udph->len to get the real length without any protocol check,
@@ -272,6 +281,9 @@ static int tcf_csum_ipv6_udp(struct sk_b
const struct ipv6hdr *ip6h;
u16 ul;

+ if (skb_is_gso(skb) && skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
+ return 1;
+
/*
* Support both UDP and UDPLITE checksum algorithms, Don't use
* udph->len to get the real length without any protocol check,



2018-03-19 18:14:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 006/134] drm: qxl: Dont alloc fbdev if emulation is not supported

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

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

From: Gabriel Krisman Bertazi <[email protected]>


[ Upstream commit 861078381ba56b56808113736000d9e7ead349c8 ]

If fbdev emulation is disabled, the QXL shutdown path will try to clean
a framebuffer that wasn't initialized, hitting the Oops below. The
problem is that even when FBDEV_EMULATION is disabled we allocate the
qfbdev strutucture, but we don't initialize it. The fix is to stop
allocating the memory, since it won't be used. This allows the existing
verification in the cleanup hook to do it's job preventing the oops.

Now that we don't allocate the unused fbdev structure, we need to be
careful when dereferencing it in the PM suspend hook.

[ 24.284684] BUG: unable to handle kernel NULL pointer dereference at 00000000000002e0
[ 24.285627] IP: mutex_lock+0x18/0x30
[ 24.286049] PGD 78cdf067
[ 24.286050] PUD 7940f067
[ 24.286344] PMD 0
[ 24.286649]
[ 24.287072] Oops: 0002 [#1] SMP
[ 24.287422] Modules linked in: qxl
[ 24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97
[ 24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 24.289681] task: ffff88007c4c0000 task.stack: ffffc90001b58000
[ 24.290354] RIP: 0010:mutex_lock+0x18/0x30
[ 24.290812] RSP: 0018:ffffc90001b5bcb0 EFLAGS: 00010246
[ 24.291401] RAX: 0000000000000000 RBX: 00000000000002e0 RCX: 0000000000000000
[ 24.292209] RDX: ffff88007c4c0000 RSI: 0000000000000001 RDI: 00000000000002e0
[ 24.292987] RBP: ffffc90001b5bcb8 R08: fffffffffffffffe R09: 0000000000000001
[ 24.293797] R10: ffff880078d80b80 R11: 0000000000011400 R12: 0000000000000000
[ 24.294601] R13: 00000000000002e0 R14: ffffffffa0009c28 R15: 0000000000000060
[ 24.295439] FS: 00007f30e3acbb40(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 24.296364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.296997] CR2: 00000000000002e0 CR3: 0000000078c7b000 CR4: 00000000000006f0
[ 24.297813] Call Trace:
[ 24.298097] drm_framebuffer_cleanup+0x1f/0x70
[ 24.298612] qxl_fbdev_fini+0x68/0x90 [qxl]
[ 24.299074] qxl_modeset_fini+0xd/0x30 [qxl]
[ 24.299562] qxl_pci_remove+0x22/0x50 [qxl]
[ 24.300025] pci_device_remove+0x34/0xb0
[ 24.300507] device_release_driver_internal+0x150/0x200
[ 24.301082] device_release_driver+0xd/0x10
[ 24.301587] unbind_store+0x108/0x150
[ 24.301993] drv_attr_store+0x20/0x30
[ 24.302402] sysfs_kf_write+0x32/0x40
[ 24.302827] kernfs_fop_write+0x108/0x190
[ 24.303269] __vfs_write+0x23/0x120
[ 24.303678] ? security_file_permission+0x36/0xb0
[ 24.304193] ? rw_verify_area+0x49/0xb0
[ 24.304636] vfs_write+0xb0/0x190
[ 24.305004] SyS_write+0x41/0xa0
[ 24.305362] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 24.305887] RIP: 0033:0x7f30e31d9620
[ 24.306285] RSP: 002b:00007ffc54b47e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 24.307128] RAX: ffffffffffffffda RBX: 00007f30e3497600 RCX: 00007f30e31d9620
[ 24.307928] RDX: 000000000000000d RSI: 0000000000da2008 RDI: 0000000000000001
[ 24.308727] RBP: 000000000070bc60 R08: 00007f30e3498760 R09: 00007f30e3acbb40
[ 24.309504] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000001
[ 24.310295] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffc54b47f34
[ 24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e>
48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3
[ 24.313182] RIP: mutex_lock+0x18/0x30 RSP: ffffc90001b5bcb0
[ 24.313811] CR2: 00000000000002e0
[ 24.314208] ---[ end trace 29669c1593cae14b ]---

Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/qxl/qxl_fb.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -494,9 +494,11 @@ static const struct drm_fb_helper_funcs

int qxl_fbdev_init(struct qxl_device *qdev)
{
+ int ret = 0;
+
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct qxl_fbdev *qfbdev;
int bpp_sel = 32; /* TODO: parameter from somewhere? */
- int ret;

qfbdev = kzalloc(sizeof(struct qxl_fbdev), GFP_KERNEL);
if (!qfbdev)
@@ -531,6 +533,8 @@ fini:
drm_fb_helper_fini(&qfbdev->helper);
free:
kfree(qfbdev);
+#endif
+
return ret;
}

@@ -546,6 +550,9 @@ void qxl_fbdev_fini(struct qxl_device *q

void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state)
{
+ if (!qdev->mode_info.qfbdev)
+ return;
+
drm_fb_helper_set_suspend(&qdev->mode_info.qfbdev->helper, state);
}




2018-03-19 18:15:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 023/134] of: fix of_device_get_modalias returned length when truncating buffers

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

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

From: Rob Herring <[email protected]>


[ Upstream commit bcf54d5385abaea9c8026aae6f4eeb348671a52d ]

If the length of the modalias is greater than the buffer size, then the
modalias is truncated. However the untruncated length is returned which
will cause an error. Fix this to return the truncated length. If an error
in the case was desired, then then we should just return -ENOMEM.

The reality is no device will ever have 4KB of compatible strings to hit
this case.

Signed-off-by: Rob Herring <[email protected]>
Cc: Frank Rowand <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/of/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -223,7 +223,7 @@ ssize_t of_device_get_modalias(struct de
str[i] = '_';
}

- return tsize;
+ return repend;
}
EXPORT_SYMBOL_GPL(of_device_get_modalias);




2018-03-19 18:15:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 028/134] sysrq: Reset the watchdog timers while displaying high-resolution timers

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

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

From: Tom Hromatka <[email protected]>


[ Upstream commit 0107042768658fea9f5f5a9c00b1c90f5dab6a06 ]

On systems with a large number of CPUs, running sysrq-<q> can cause
watchdog timeouts. There are two slow sections of code in the sysrq-<q>
path in timer_list.c.

1. print_active_timers() - This function is called by print_cpu() and
contains a slow goto loop. On a machine with hundreds of CPUs, this
loop took approximately 100ms for the first CPU in a NUMA node.
(Subsequent CPUs in the same node ran much quicker.) The total time
to print all of the CPUs is ultimately long enough to trigger the
soft lockup watchdog.

2. print_tickdevice() - This function outputs a large amount of textual
information. This function also took approximately 100ms per CPU.

Since sysrq-<q> is not a performance critical path, there should be no
harm in touching the nmi watchdog in both slow sections above. Touching
it in just one location was insufficient on systems with hundreds of
CPUs as occasional timeouts were still observed during testing.

This issue was observed on an Oracle T7 machine with 128 CPUs, but I
anticipate it may affect other systems with similarly large numbers of
CPUs.

Signed-off-by: Tom Hromatka <[email protected]>
Reviewed-by: Rob Gardner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/time/timer_list.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/kernel/time/timer_list.c
+++ b/kernel/time/timer_list.c
@@ -16,6 +16,7 @@
#include <linux/sched.h>
#include <linux/seq_file.h>
#include <linux/kallsyms.h>
+#include <linux/nmi.h>

#include <asm/uaccess.h>

@@ -96,6 +97,9 @@ print_active_timers(struct seq_file *m,

next_one:
i = 0;
+
+ touch_nmi_watchdog();
+
raw_spin_lock_irqsave(&base->cpu_base->lock, flags);

curr = timerqueue_getnext(&base->active);
@@ -207,6 +211,8 @@ print_tickdevice(struct seq_file *m, str
{
struct clock_event_device *dev = td->evtdev;

+ touch_nmi_watchdog();
+
SEQ_printf(m, "Tick Device: mode: %d\n", td->mode);
if (cpu < 0)
SEQ_printf(m, "Broadcast device\n");



2018-03-19 18:15:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 027/134] timers, sched_clock: Update timeout for clock wrap

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

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

From: David Engraf <[email protected]>


[ Upstream commit 1b8955bc5ac575009835e371ae55e7f3af2197a9 ]

The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/time/sched_clock.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void),

update_clock_read_data(&rd);

+ if (sched_clock_timer.function != NULL) {
+ /* update timeout for clock wrap */
+ hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+ }
+
r = rate;
if (r >= 4000000) {
r /= 1000000;



2018-03-19 18:15:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 026/134] [media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock

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

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

From: Janusz Krzysztofik <[email protected]>


[ Upstream commit 54449af0e0b2ea43a8166611c95b730c850c3184 ]

After changes to v4l2_clk API introduced in v4.1 by commits a37462b919
'[media] V4L: remove clock name from v4l2_clk API' and 4f528afcfb
'[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor
stopped responding because v4l2_clk_get(), still called with
depreciated V4L2 clock name "mclk", started to return respective CCF
clock instead of the V4l2 one registered by soc_camera. Fix it by
calling v4l2_clk_get() with NULL clock name.

Created and tested on Amstrad Delta against Linux-4.7-rc3 with
omap1_camera fixes.

Signed-off-by: Janusz Krzysztofik <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[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/ov6650.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/i2c/soc_camera/ov6650.c
+++ b/drivers/media/i2c/soc_camera/ov6650.c
@@ -1033,7 +1033,7 @@ static int ov6650_probe(struct i2c_clien
priv->code = MEDIA_BUS_FMT_YUYV8_2X8;
priv->colorspace = V4L2_COLORSPACE_JPEG;

- priv->clk = v4l2_clk_get(&client->dev, "mclk");
+ priv->clk = v4l2_clk_get(&client->dev, NULL);
if (IS_ERR(priv->clk)) {
ret = PTR_ERR(priv->clk);
goto eclkget;



2018-03-19 18:15:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 004/134] staging: wilc1000: add check for kmalloc allocation failure.

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

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

From: Colin Ian King <[email protected]>


[ Upstream commit 6cc0c259d034c6ab48f4e12f505213988e73d380 ]

Add a sanity check that wid.val has been allocated, fixes a null
pointer deference on stamac when calling ether_add_copy.

Detected by CoverityScan, CID#1369537 ("Dereference null return value")

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/wilc1000/host_interface.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2179,6 +2179,8 @@ static s32 Handle_Get_InActiveTime(struc
wid.type = WID_STR;
wid.size = ETH_ALEN;
wid.val = kmalloc(wid.size, GFP_KERNEL);
+ if (!wid.val)
+ return -ENOMEM;

stamac = wid.val;
memcpy(stamac, strHostIfStaInactiveT->mac, ETH_ALEN);



2018-03-19 18:15:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 065/134] MIPS: r2-on-r6-emu: Clear BLTZALL and BGEZALL debugfs counters

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

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

From: Aleksandar Markovic <[email protected]>


[ Upstream commit 411dac79cc2ed80f7e348ccc23eb4d8b0ba9f6d5 ]

Add missing clearing of BLTZALL and BGEZALL emulation counters in
function mipsr2_stats_clear_show().

Previously, it was not possible to reset BLTZALL and BGEZALL
emulation counters - their value remained the same even after
explicit request via debugfs. As far as other related counters
are concerned, they all seem to be properly cleared.

This change affects debugfs operation only, core R2 emulation
functionality is not affected.

Signed-off-by: Aleksandar Markovic <[email protected]>
Reviewed-by: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15517/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/kernel/mips-r2-to-r6-emul.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -2340,6 +2340,8 @@ static int mipsr2_stats_clear_show(struc
__this_cpu_write((mipsr2bremustats).bgezl, 0);
__this_cpu_write((mipsr2bremustats).bltzll, 0);
__this_cpu_write((mipsr2bremustats).bgezll, 0);
+ __this_cpu_write((mipsr2bremustats).bltzall, 0);
+ __this_cpu_write((mipsr2bremustats).bgezall, 0);
__this_cpu_write((mipsr2bremustats).bltzal, 0);
__this_cpu_write((mipsr2bremustats).bgezal, 0);
__this_cpu_write((mipsr2bremustats).beql, 0);



2018-03-19 18:15:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 058/134] video: ARM CLCD: fix dma allocation size

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

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

From: Liam Beguin <[email protected]>


[ Upstream commit 9a1c779e6b06855e41099caa6f15b3b584dfa88c ]

This patch forces the frambuffer size to be aligned on kernel pages.

During the board startup, the splash screed did appear;
the "ts_test" program or our application were not able to start.

The following error message was reported:
error: failed to map framebuffer device to memory.
LinuxFB: driver cannot connect

The issue was discovered, on the LPC32xx platform, during the migration
of the LCD definition from the board file to the device tree.

Signed-off-by: Liam Beguin <[email protected]>
Signed-off-by: Sylvain Lemieux <[email protected]>
Cc: Vladimir Zapolskiy <[email protected]>
Cc: Russell King <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/fbdev/amba-clcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -759,8 +759,8 @@ static int clcdfb_of_dma_setup(struct cl
if (err)
return err;

- framesize = fb->panel->mode.xres * fb->panel->mode.yres *
- fb->panel->bpp / 8;
+ framesize = PAGE_ALIGN(fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8);
fb->fb.screen_base = dma_alloc_coherent(&fb->dev->dev, framesize,
&dma, GFP_KERNEL);
if (!fb->fb.screen_base)



2018-03-19 18:16:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 069/134] usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()

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

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

From: Yuyang Du <[email protected]>


[ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ]

This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add
SuperSpeed support").

In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear
the right bit regardless of what the wValue is.

Acked-by: Alan Stern <[email protected]>
Signed-off-by: Yuyang Du <[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/dummy_hcd.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)

--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -2105,16 +2105,13 @@ static int dummy_hub_control(
}
break;
case USB_PORT_FEAT_POWER:
- if (hcd->speed == HCD_USB3) {
- if (dum_hcd->port_status & USB_PORT_STAT_POWER)
- dev_dbg(dummy_dev(dum_hcd),
- "power-off\n");
- } else
- if (dum_hcd->port_status &
- USB_SS_PORT_STAT_POWER)
- dev_dbg(dummy_dev(dum_hcd),
- "power-off\n");
- /* FALLS THROUGH */
+ dev_dbg(dummy_dev(dum_hcd), "power-off\n");
+ if (hcd->speed == HCD_USB3)
+ dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER;
+ else
+ dum_hcd->port_status &= ~USB_PORT_STAT_POWER;
+ set_link_state(dum_hcd);
+ break;
default:
dum_hcd->port_status &= ~(1 << wValue);
set_link_state(dum_hcd);
@@ -2285,14 +2282,13 @@ static int dummy_hub_control(
if ((dum_hcd->port_status &
USB_SS_PORT_STAT_POWER) != 0) {
dum_hcd->port_status |= (1 << wValue);
- set_link_state(dum_hcd);
}
} else
if ((dum_hcd->port_status &
USB_PORT_STAT_POWER) != 0) {
dum_hcd->port_status |= (1 << wValue);
- set_link_state(dum_hcd);
}
+ set_link_state(dum_hcd);
}
break;
case GetPortErrorCount:



2018-03-19 18:16:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 035/134] driver: (adm1275) set the m,b and R coefficients correctly for power

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

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

From: Shikhar Dogra <[email protected]>


[ Upstream commit 6faecba0b3da7b617bf72bef422bf0d3bb6dfe7d ]

Seems like coefficient values for m, b and R under power have been
put in the wrong order. Rearranging them properly to get correct
values of coefficients for power.

For specs, please refer to table 7 (page 35) on
http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.pdf

Fixes: 904b296f308d ("hwmon: (adm1275) Introduce configuration data structure for coeffcients")
Signed-off-by: Shikhar Dogra <[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/pmbus/adm1275.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -95,8 +95,8 @@ static const struct coefficients adm1075
[0] = { 27169, 0, -1 }, /* voltage */
[1] = { 806, 20475, -1 }, /* current, irange25 */
[2] = { 404, 20475, -1 }, /* current, irange50 */
- [3] = { 0, -1, 8549 }, /* power, irange25 */
- [4] = { 0, -1, 4279 }, /* power, irange50 */
+ [3] = { 8549, 0, -1 }, /* power, irange25 */
+ [4] = { 4279, 0, -1 }, /* power, irange50 */
};

static const struct coefficients adm1275_coefficients[] = {



2018-03-19 18:16:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 081/134] HID: elo: clear BTN_LEFT mapping

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

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

From: Jiri Kosina <[email protected]>


[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]

ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.

Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.

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-elo.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct h
{
struct input_dev *input = hidinput->input;

+ /*
+ * ELO devices have one Button usage in GenDesk field, which makes
+ * hid-input map it to BTN_LEFT; that confuses userspace, which then
+ * considers the device to be a mouse/touchpad instead of touchscreen.
+ */
+ clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);



2018-03-19 18:17:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 090/134] mtd: nand: ifc: update bufnum mask for ver >= 2.0.0

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

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

From: Jagdish Gediya <[email protected]>


[ Upstream commit bccb06c353af3764ca86d9da47652458e6c2eb41 ]

Bufnum mask is used to calculate page position in the internal SRAM.

As IFC version 2.0.0 has 16KB of internal SRAM as compared to older
versions which had 8KB. Hence bufnum mask needs to be updated.

Signed-off-by: Jagdish Gediya <[email protected]>
Signed-off-by: Prabhakar Kushwaha <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/nand/fsl_ifc_nand.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -988,6 +988,13 @@ static int fsl_ifc_chip_init(struct fsl_
if (ctrl->version == FSL_IFC_VERSION_1_1_0)
fsl_ifc_sram_init(priv);

+ /*
+ * As IFC version 2.0.0 has 16KB of internal SRAM as compared to older
+ * versions which had 8KB. Hence bufnum mask needs to be updated.
+ */
+ if (ctrl->version >= FSL_IFC_VERSION_2_0_0)
+ priv->bufnum_mask = (priv->bufnum_mask * 2) + 1;
+
return 0;
}




2018-03-19 18:17:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 039/134] f2fs: relax node version check for victim data in gc

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

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

From: Jaegeuk Kim <[email protected]>


[ Upstream commit c13ff37e359bb3eacf4e1760dcea8d9760aa7459 ]

- has_not_enough_free_secs
node_secs: 0 dent_secs: 0 freed:0 free_segments:103 reserved:104

- f2fs_gc
- get_victim_by_default
alloc_mode 0, gc_mode 1, max_search 2672, offset 4654, ofs_unit 1

- do_garbage_collect
start_segno 3976, end_segno 3977 type 0

- is_alive
nid 22797, blkaddr 2131882, ofs_in_node 0, version 0x8/0x0

- gc_data_segment 766, segno 3976, block 512/426 not alive

So, this patch fixes subtle corrupted case where node version does not match
to summary version which results in infinite loop by gc.

Reported-by: Yunlei He <[email protected]>
Signed-off-by: Jaegeuk Kim <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -522,8 +522,10 @@ static bool is_alive(struct f2fs_sb_info
get_node_info(sbi, nid, dni);

if (sum->version != dni->version) {
- f2fs_put_page(node_page, 1);
- return false;
+ f2fs_msg(sbi->sb, KERN_WARNING,
+ "%s: valid data with mismatched node version.",
+ __func__);
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
}

*nofs = ofs_of_node(node_page);



2018-03-19 18:17:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 093/134] clk: qcom: msm8916: fix mnd_width for codec_digcodec

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

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

From: Srinivas Kandagatla <[email protected]>


[ Upstream commit d8e488e8242ecf129eebc440c92d800a99ca109d ]

This patch fixes missing mnd_width for codec_digital clk, this is now set to
8 inline with datasheet.

Fixes: 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support")
Signed-off-by: Srinivas Kandagatla <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/qcom/gcc-msm8916.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -1437,6 +1437,7 @@ static const struct freq_tbl ftbl_codec_

static struct clk_rcg2 codec_digcodec_clk_src = {
.cmd_rcgr = 0x1c09c,
+ .mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll1_emclk_sleep_map,
.freq_tbl = ftbl_codec_clk,



2018-03-19 18:17:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 097/134] scsi: core: scsi_get_device_flags_keyed(): Always return device flags

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

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

From: Bart Van Assche <[email protected]>


[ Upstream commit a44c9d36509c83cf64f33b93f6ab2e63822c01eb ]

Since scsi_get_device_flags_keyed() callers do not check whether or not
the returned value is an error code, change that function such that it
returns a flags value even if the 'key' argument is invalid. Note:
since commit 28a0bc4120d3 ("scsi: sd: Implement blacklist option for
WRITE SAME w/ UNMAP") bit 31 is a valid device information flag so
checking whether bit 31 is set in the return value is not sufficient to
tell the difference between an error code and a flags value.

Signed-off-by: Bart Van Assche <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Cc: Johannes Thumshirn <[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/scsi_devinfo.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -589,17 +589,12 @@ int scsi_get_device_flags_keyed(struct s
int key)
{
struct scsi_dev_info_list *devinfo;
- int err;

devinfo = scsi_dev_info_list_find(vendor, model, key);
if (!IS_ERR(devinfo))
return devinfo->flags;

- err = PTR_ERR(devinfo);
- if (err != -ENOENT)
- return err;
-
- /* nothing found, return nothing */
+ /* key or device not found: return nothing */
if (key != SCSI_DEVINFO_GLOBAL)
return 0;




2018-03-19 18:18:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 105/134] mac80211: remove BUG() when interface type is invalid

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

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

From: Luca Coelho <[email protected]>


[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]

In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens when an interface is being set up. Calling BUG() is too
extreme for this and a WARN_ON() would be better used instead. Change
that.

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/iface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1441,7 +1441,7 @@ static void ieee80211_setup_sdata(struct
break;
case NL80211_IFTYPE_UNSPECIFIED:
case NUM_NL80211_IFTYPES:
- BUG();
+ WARN_ON(1);
break;
}




2018-03-19 18:18:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 121/134] fs: Teach path_connected to handle nfs filesystems with multiple roots.

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

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

From: Eric W. Biederman <[email protected]>

commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream.

On nfsv2 and nfsv3 the nfs server can export subsets of the same
filesystem and report the same filesystem identifier, so that the nfs
client can know they are the same filesystem. The subsets can be from
disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no
way to find the common root of all directory trees exported form the
server with the same filesystem identifier.

The practical result is that in struct super s_root for nfs s_root is
not necessarily the root of the filesystem. The nfs mount code sets
s_root to the root of the first subset of the nfs filesystem that the
kernel mounts.

This effects the dcache invalidation code in generic_shutdown_super
currently called shrunk_dcache_for_umount and that code for years
has gone through an additional list of dentries that might be dentry
trees that need to be freed to accomodate nfs.

When I wrote path_connected I did not realize nfs was so special, and
it's hueristic for avoiding calling is_subdir can fail.

The practical case where this fails is when there is a move of a
directory from the subtree exposed by one nfs mount to the subtree
exposed by another nfs mount. This move can happen either locally or
remotely. With the remote case requiring that the move directory be cached
before the move and that after the move someone walks the path
to where the move directory now exists and in so doing causes the
already cached directory to be moved in the dcache through the magic
of d_splice_alias.

If someone whose working directory is in the move directory or a
subdirectory and now starts calling .. from the initial mount of nfs
(where s_root == mnt_root), then path_connected as a heuristic will
not bother with the is_subdir check. As s_root really is not the root
of the nfs filesystem this heuristic is wrong, and the path may
actually not be connected and path_connected can fail.

The is_subdir function might be cheap enough that we can call it
unconditionally. Verifying that will take some benchmarking and
the result may not be the same on all kernels this fix needs
to be backported to. So I am avoiding that for now.

Filesystems with snapshots such as nilfs and btrfs do something
similar. But as the directory tree of the snapshots are disjoint
from one another and from the main directory tree rename won't move
things between them and this problem will not occur.

Cc: [email protected]
Reported-by: Al Viro <[email protected]>
Fixes: 397d425dc26d ("vfs: Test for and handle paths that are unreachable from their mnt_root")
Signed-off-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/namei.c | 5 +++--
fs/nfs/super.c | 2 ++
include/linux/fs.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)

--- a/fs/namei.c
+++ b/fs/namei.c
@@ -570,9 +570,10 @@ static int __nd_alloc_stack(struct namei
static bool path_connected(const struct path *path)
{
struct vfsmount *mnt = path->mnt;
+ struct super_block *sb = mnt->mnt_sb;

- /* Only bind mounts can have disconnected paths */
- if (mnt->mnt_root == mnt->mnt_sb->s_root)
+ /* Bind mounts and multi-root filesystems can have disconnected paths */
+ if (!(sb->s_iflags & SB_I_MULTIROOT) && (mnt->mnt_root == sb->s_root))
return true;

return is_subdir(path->dentry, mnt->mnt_root);
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2581,6 +2581,8 @@ struct dentry *nfs_fs_mount_common(struc
/* initial superblock/root creation */
mount_info->fill_super(s, mount_info);
nfs_get_cache_cookie(s, mount_info->parsed, mount_info->cloned);
+ if (!(server->flags & NFS_MOUNT_UNSHARED))
+ s->s_iflags |= SB_I_MULTIROOT;
}

mntroot = nfs_get_root(s, mount_info->mntfh, dev_name);
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1295,6 +1295,7 @@ struct mm_struct;
/* sb->s_iflags */
#define SB_I_CGROUPWB 0x00000001 /* cgroup-aware writeback enabled */
#define SB_I_NOEXEC 0x00000002 /* Ignore executables on this fs */
+#define SB_I_MULTIROOT 0x00000008 /* Multiple roots to the dentry tree */

/* Possible states of 'frozen' field */
enum {



2018-03-19 18:18:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 124/134] fs/aio: Use RCU accessors for kioctx_table->table[]

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

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

From: Tejun Heo <[email protected]>

commit d0264c01e7587001a8c4608a5d1818dba9a4c11a upstream.

While converting ioctx index from a list to a table, db446a08c23d
("aio: convert the ioctx list to table lookup v3") missed tagging
kioctx_table->table[] as an array of RCU pointers and using the
appropriate RCU accessors. This introduces a small window in the
lookup path where init and access may race.

Mark kioctx_table->table[] with __rcu and use the approriate RCU
accessors when using the field.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Jann Horn <[email protected]>
Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3")
Cc: Benjamin LaHaise <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: [email protected] # v3.12+
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/aio.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)

--- a/fs/aio.c
+++ b/fs/aio.c
@@ -68,9 +68,9 @@ struct aio_ring {
#define AIO_RING_PAGES 8

struct kioctx_table {
- struct rcu_head rcu;
- unsigned nr;
- struct kioctx *table[];
+ struct rcu_head rcu;
+ unsigned nr;
+ struct kioctx __rcu *table[];
};

struct kioctx_cpu {
@@ -327,7 +327,7 @@ static int aio_ring_mremap(struct vm_are
for (i = 0; i < table->nr; i++) {
struct kioctx *ctx;

- ctx = table->table[i];
+ ctx = rcu_dereference(table->table[i]);
if (ctx && ctx->aio_ring_file == file) {
if (!atomic_read(&ctx->dead)) {
ctx->user_id = ctx->mmap_base = vma->vm_start;
@@ -651,9 +651,9 @@ static int ioctx_add_table(struct kioctx
while (1) {
if (table)
for (i = 0; i < table->nr; i++)
- if (!table->table[i]) {
+ if (!rcu_access_pointer(table->table[i])) {
ctx->id = i;
- table->table[i] = ctx;
+ rcu_assign_pointer(table->table[i], ctx);
spin_unlock(&mm->ioctx_lock);

/* While kioctx setup is in progress,
@@ -828,8 +828,8 @@ static int kill_ioctx(struct mm_struct *
}

table = rcu_dereference_raw(mm->ioctx_table);
- WARN_ON(ctx != table->table[ctx->id]);
- table->table[ctx->id] = NULL;
+ WARN_ON(ctx != rcu_access_pointer(table->table[ctx->id]));
+ RCU_INIT_POINTER(table->table[ctx->id], NULL);
spin_unlock(&mm->ioctx_lock);

/* free_ioctx_reqs() will do the necessary RCU synchronization */
@@ -874,7 +874,8 @@ void exit_aio(struct mm_struct *mm)

skipped = 0;
for (i = 0; i < table->nr; ++i) {
- struct kioctx *ctx = table->table[i];
+ struct kioctx *ctx =
+ rcu_dereference_protected(table->table[i], true);

if (!ctx) {
skipped++;
@@ -1063,7 +1064,7 @@ static struct kioctx *lookup_ioctx(unsig
if (!table || id >= table->nr)
goto out;

- ctx = table->table[id];
+ ctx = rcu_dereference(table->table[id]);
if (ctx && ctx->user_id == ctx_id) {
percpu_ref_get(&ctx->users);
ret = ctx;



2018-03-19 18:19:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 131/134] btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device

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

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

From: Nikolay Borisov <[email protected]>

commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream.

Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced
btrfs_free_stale_device which iterates the device lists for all
registered btrfs filesystems and deletes those devices which aren't
mounted. In a btrfs_devices structure has only 1 device attached to it
and it is unused then btrfs_free_stale_devices will proceed to also free
the btrfs_fs_devices struct itself. Currently this leads to a use after
free since list_for_each_entry will try to perform a check on the
already freed memory to see if it has to terminate the loop.

The fix is to use 'break' when we know we are freeing the current
fs_devs.

Fixes: 4fde46f0cc71 ("Btrfs: free the stale device")
Signed-off-by: Nikolay Borisov <[email protected]>
Reviewed-by: Anand Jain <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -568,6 +568,7 @@ void btrfs_free_stale_device(struct btrf
btrfs_sysfs_remove_fsid(fs_devs);
list_del(&fs_devs->list);
free_fs_devices(fs_devs);
+ break;
} else {
fs_devs->num_devices--;
list_del(&dev->dev_list);



2018-03-19 18:19:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 111/134] selftests/x86: Add tests for User-Mode Instruction Prevention

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

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

From: Ricardo Neri <[email protected]>

commit 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e upstream.

Certain user space programs that run on virtual-8086 mode may utilize
instructions protected by the User-Mode Instruction Prevention (UMIP)
security feature present in new Intel processors: SGDT, SIDT and SMSW. In
such a case, a general protection fault is issued if UMIP is enabled. When
such a fault happens, the kernel traps it and emulates the results of
these instructions with dummy values. The purpose of this new
test is to verify whether the impacted instructions can be executed
without causing such #GP. If no #GP exceptions occur, we expect to exit
virtual-8086 mode from INT3.

The instructions protected by UMIP are executed in representative use
cases:

a) displacement-only memory addressing
b) register-indirect memory addressing
c) results stored directly in operands

Unfortunately, it is not possible to check the results against a set of
expected values because no emulation will occur in systems that do not
have the UMIP feature. Instead, results are printed for verification. A
simple verification is done to ensure that results of all tests are
identical.

Signed-off-by: Ricardo Neri <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Chen Yucong <[email protected]>
Cc: Chris Metcalf <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Huang Rui <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ravi V. Shankar <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/1509935277-22138-12-git-send-email-ricardo.neri-calderon@linux.intel.com
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/testing/selftests/x86/entry_from_vm86.c | 73 +++++++++++++++++++++++++-
1 file changed, 72 insertions(+), 1 deletion(-)

--- a/tools/testing/selftests/x86/entry_from_vm86.c
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -95,6 +95,22 @@ asm (
"int3\n\t"
"vmcode_int80:\n\t"
"int $0x80\n\t"
+ "vmcode_umip:\n\t"
+ /* addressing via displacements */
+ "smsw (2052)\n\t"
+ "sidt (2054)\n\t"
+ "sgdt (2060)\n\t"
+ /* addressing via registers */
+ "mov $2066, %bx\n\t"
+ "smsw (%bx)\n\t"
+ "mov $2068, %bx\n\t"
+ "sidt (%bx)\n\t"
+ "mov $2074, %bx\n\t"
+ "sgdt (%bx)\n\t"
+ /* register operands, only for smsw */
+ "smsw %ax\n\t"
+ "mov %ax, (2080)\n\t"
+ "int3\n\t"
".size vmcode, . - vmcode\n\t"
"end_vmcode:\n\t"
".code32\n\t"
@@ -103,7 +119,7 @@ asm (

extern unsigned char vmcode[], end_vmcode[];
extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[],
- vmcode_sti[], vmcode_int3[], vmcode_int80[];
+ vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[];

/* Returns false if the test was skipped. */
static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -160,6 +176,58 @@ static bool do_test(struct vm86plus_stru
return true;
}

+void do_umip_tests(struct vm86plus_struct *vm86, unsigned char *test_mem)
+{
+ struct table_desc {
+ unsigned short limit;
+ unsigned long base;
+ } __attribute__((packed));
+
+ /* Initialize variables with arbitrary values */
+ struct table_desc gdt1 = { .base = 0x3c3c3c3c, .limit = 0x9999 };
+ struct table_desc gdt2 = { .base = 0x1a1a1a1a, .limit = 0xaeae };
+ struct table_desc idt1 = { .base = 0x7b7b7b7b, .limit = 0xf1f1 };
+ struct table_desc idt2 = { .base = 0x89898989, .limit = 0x1313 };
+ unsigned short msw1 = 0x1414, msw2 = 0x2525, msw3 = 3737;
+
+ /* UMIP -- exit with INT3 unless kernel emulation did not trap #GP */
+ do_test(vm86, vmcode_umip - vmcode, VM86_TRAP, 3, "UMIP tests");
+
+ /* Results from displacement-only addressing */
+ msw1 = *(unsigned short *)(test_mem + 2052);
+ memcpy(&idt1, test_mem + 2054, sizeof(idt1));
+ memcpy(&gdt1, test_mem + 2060, sizeof(gdt1));
+
+ /* Results from register-indirect addressing */
+ msw2 = *(unsigned short *)(test_mem + 2066);
+ memcpy(&idt2, test_mem + 2068, sizeof(idt2));
+ memcpy(&gdt2, test_mem + 2074, sizeof(gdt2));
+
+ /* Results when using register operands */
+ msw3 = *(unsigned short *)(test_mem + 2080);
+
+ printf("[INFO]\tResult from SMSW:[0x%04x]\n", msw1);
+ printf("[INFO]\tResult from SIDT: limit[0x%04x]base[0x%08lx]\n",
+ idt1.limit, idt1.base);
+ printf("[INFO]\tResult from SGDT: limit[0x%04x]base[0x%08lx]\n",
+ gdt1.limit, gdt1.base);
+
+ if (msw1 != msw2 || msw1 != msw3)
+ printf("[FAIL]\tAll the results of SMSW should be the same.\n");
+ else
+ printf("[PASS]\tAll the results from SMSW are identical.\n");
+
+ if (memcmp(&gdt1, &gdt2, sizeof(gdt1)))
+ printf("[FAIL]\tAll the results of SGDT should be the same.\n");
+ else
+ printf("[PASS]\tAll the results from SGDT are identical.\n");
+
+ if (memcmp(&idt1, &idt2, sizeof(idt1)))
+ printf("[FAIL]\tAll the results of SIDT should be the same.\n");
+ else
+ printf("[PASS]\tAll the results from SIDT are identical.\n");
+}
+
int main(void)
{
struct vm86plus_struct v86;
@@ -218,6 +286,9 @@ int main(void)
v86.regs.eax = (unsigned int)-1;
do_test(&v86, vmcode_int80 - vmcode, VM86_INTx, 0x80, "int80");

+ /* UMIP -- should exit with INTx 0x80 unless UMIP was not disabled */
+ do_umip_tests(&v86, addr);
+
/* Execute a null pointer */
v86.regs.cs = 0;
v86.regs.ss = 0;



2018-03-19 18:19:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 078/134] wil6210: fix memory access violation in wil_memcpy_from/toio_32

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

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

From: Dedy Lansky <[email protected]>


[ Upstream commit 0f6edfe2bbbb59d161580cb4870fcc46f5490f85 ]

In case count is not multiple of 4, there is a read access in
wil_memcpy_toio_32() from outside src buffer boundary.
In wil_memcpy_fromio_32(), in case count is not multiple of 4, there is
a write access to outside dst io memory boundary.

Fix these issues with proper handling of the last 1 to 4 copied bytes.

Signed-off-by: Dedy Lansky <[email protected]>
Signed-off-by: Maya Erez <[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/wil6210/main.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -125,9 +125,15 @@ void wil_memcpy_fromio_32(void *dst, con
u32 *d = dst;
const volatile u32 __iomem *s = src;

- /* size_t is unsigned, if (count%4 != 0) it will wrap */
- for (count += 4; count > 4; count -= 4)
+ for (; count >= 4; count -= 4)
*d++ = __raw_readl(s++);
+
+ if (unlikely(count)) {
+ /* count can be 1..3 */
+ u32 tmp = __raw_readl(s);
+
+ memcpy(d, &tmp, count);
+ }
}

void wil_memcpy_toio_32(volatile void __iomem *dst, const void *src,
@@ -136,8 +142,16 @@ void wil_memcpy_toio_32(volatile void __
volatile u32 __iomem *d = dst;
const u32 *s = src;

- for (count += 4; count > 4; count -= 4)
+ for (; count >= 4; count -= 4)
__raw_writel(*s++, d++);
+
+ if (unlikely(count)) {
+ /* count can be 1..3 */
+ u32 tmp = 0;
+
+ memcpy(&tmp, s, count);
+ __raw_writel(tmp, d);
+ }
}

static void wil_disconnect_cid(struct wil6210_priv *wil, int cid,



2018-03-19 18:20:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 133/134] usb: gadget: bdc: 64-bit pointer capability check

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

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

From: Srinath Mannam <[email protected]>

commit c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 upstream.

Corrected the register to check the 64-bit pointer
capability state. 64-bit pointer implementation capability
was checking in wrong register, which causes the BDC
enumeration failure in 64-bit memory address.

Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for
Broadcom USB3.0 device controller IP BDC")

Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: Srinath Mannam <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -475,7 +475,7 @@ static int bdc_probe(struct platform_dev
bdc->dev = dev;
dev_dbg(bdc->dev, "bdc->regs: %p irq=%d\n", bdc->regs, bdc->irq);

- temp = bdc_readl(bdc->regs, BDC_BDCSC);
+ temp = bdc_readl(bdc->regs, BDC_BDCCAP1);
if ((temp & BDC_P64) &&
!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
dev_dbg(bdc->dev, "Using 64-bit address\n");



2018-03-19 20:06:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 108/134] rcutorture/configinit: Fix build directory error message

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

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

From: SeongJae Park <[email protected]>


[ Upstream commit 2adfa4210f8f35cdfb4e08318cc06b99752964c2 ]

The 'configinit.sh' script checks the format of optional argument for the
build directory, printing an error message if the format is not valid.
However, the error message uses the wrong variable, indicating an empty
string even though the user entered a non-empty (but erroneous) string.
This commit fixes the script to use the correct variable.

Fixes: c87b9c601ac8 ("rcutorture: Add KVM-based test framework")

Signed-off-by: SeongJae Park <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/testing/selftests/rcutorture/bin/configinit.sh
+++ b/tools/testing/selftests/rcutorture/bin/configinit.sh
@@ -51,7 +51,7 @@ then
mkdir $builddir
fi
else
- echo Bad build directory: \"$builddir\"
+ echo Bad build directory: \"$buildloc\"
exit 2
fi
fi



2018-03-19 20:06:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 114/134] x86/vm86/32: Fix POPF emulation

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

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

From: Andy Lutomirski <[email protected]>

commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream.

POPF would trap if VIP was set regardless of whether IF was set. Fix it.

Suggested-by: Stas Sergeev <[email protected]>
Reported-by: Bart Oldeman <[email protected]>
Signed-off-by: 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]>
Cc: [email protected]
Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86")
Link: http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.1521003603.git.luto@kernel.org
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/vm86_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -715,7 +715,8 @@ void handle_vm86_fault(struct kernel_vm8
return;

check_vip:
- if (VEFLAGS & X86_EFLAGS_VIP) {
+ if ((VEFLAGS & (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) ==
+ (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) {
save_v86_state(regs, VM86_STI);
return;
}



2018-03-19 20:06:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 113/134] selftests/x86/entry_from_vm86: Add test cases for POPF

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

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

From: Andy Lutomirski <[email protected]>

commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream.

POPF is currently broken -- add tests to catch the error. This
results in:

[RUN] POPF with VIP set and IF clear from vm86 mode
[INFO] Exited vm86 mode due to STI
[FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf)

because POPF currently fails to check IF before reporting a pending
interrupt.

This patch also makes the FAIL message a bit more informative.

Reported-by: Bart Oldeman <[email protected]>
Signed-off-by: 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: Stas Sergeev <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.1521003603.git.luto@kernel.org
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/testing/selftests/x86/entry_from_vm86.c | 30 +++++++++++++++++++++++---
1 file changed, 27 insertions(+), 3 deletions(-)

--- a/tools/testing/selftests/x86/entry_from_vm86.c
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -95,6 +95,10 @@ asm (
"int3\n\t"
"vmcode_int80:\n\t"
"int $0x80\n\t"
+ "vmcode_popf_hlt:\n\t"
+ "push %ax\n\t"
+ "popf\n\t"
+ "hlt\n\t"
"vmcode_umip:\n\t"
/* addressing via displacements */
"smsw (2052)\n\t"
@@ -124,8 +128,8 @@ asm (

extern unsigned char vmcode[], end_vmcode[];
extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[],
- vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[],
- vmcode_umip_str[], vmcode_umip_sldt[];
+ vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[],
+ vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[];

/* Returns false if the test was skipped. */
static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_stru
(VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) {
printf("[OK]\tReturned correctly\n");
} else {
- printf("[FAIL]\tIncorrect return reason\n");
+ printf("[FAIL]\tIncorrect return reason (started at eip = 0x%lx, ended at eip = 0x%lx)\n", eip, v86->regs.eip);
nerrs++;
}

@@ -264,6 +268,9 @@ int main(void)
v86.regs.ds = load_addr / 16;
v86.regs.es = load_addr / 16;

+ /* Use the end of the page as our stack. */
+ v86.regs.esp = 4096;
+
assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */

/* #BR -- should deliver SIG??? */
@@ -295,6 +302,23 @@ int main(void)
v86.regs.eflags &= ~X86_EFLAGS_IF;
do_test(&v86, vmcode_sti - vmcode, VM86_STI, 0, "STI with VIP set");

+ /* POPF with VIP set but IF clear: should not trap */
+ v86.regs.eflags = X86_EFLAGS_VIP;
+ v86.regs.eax = 0;
+ do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP set and IF clear");
+
+ /* POPF with VIP set and IF set: should trap */
+ v86.regs.eflags = X86_EFLAGS_VIP;
+ v86.regs.eax = X86_EFLAGS_IF;
+ do_test(&v86, vmcode_popf_hlt - vmcode, VM86_STI, 0, "POPF with VIP and IF set");
+
+ /* POPF with VIP clear and IF set: should not trap */
+ v86.regs.eflags = 0;
+ v86.regs.eax = X86_EFLAGS_IF;
+ do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP clear and IF set");
+
+ v86.regs.eflags = 0;
+
/* INT3 -- should cause #BP */
do_test(&v86, vmcode_int3 - vmcode, VM86_TRAP, 3, "INT3");




2018-03-19 20:06:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 134/134] bpf: fix incorrect sign extension in check_alu_op()

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

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

From: Jann Horn <[email protected]>

commit 95a762e2c8c942780948091f8f2a4f32fce1ac6f upstream.

Distinguish between
BPF_ALU64|BPF_MOV|BPF_K (load 32-bit immediate, sign-extended to 64-bit)
and BPF_ALU|BPF_MOV|BPF_K (load 32-bit immediate, zero-padded to 64-bit);
only perform sign extension in the first case.

This patch differs from the mainline one because the verifier's internals
have changed in the meantime. Mainline tracks register values as 64-bit
values; however, 4.4 still stores tracked register values as 32-bit
values with sign extension. Therefore, in the case of a 32-bit op with
negative immediate, the value can't be tracked; leave the register as
UNKNOWN_VALUE (set by the preceding check_reg_arg() call).


I have manually tested this patch on top of 4.4.122. For the following BPF
bytecode:

BPF_MOV64_IMM(BPF_REG_1, 1),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 1, 1),
BPF_EXIT_INSN(),

BPF_MOV32_IMM(BPF_REG_1, 1),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 1, 1),
BPF_EXIT_INSN(),

BPF_MOV64_IMM(BPF_REG_1, -1),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, -1, 1),
BPF_EXIT_INSN(),

BPF_MOV32_IMM(BPF_REG_1, -1),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, -1, 2),
BPF_MOV32_IMM(BPF_REG_0, 42),
BPF_EXIT_INSN(),

BPF_MOV32_IMM(BPF_REG_0, 43),
BPF_EXIT_INSN()

Verifier output on 4.4.122 without this patch:

0: (b7) r1 = 1
1: (15) if r1 == 0x1 goto pc+1
3: (b4) (u32) r1 = (u32) 1
4: (15) if r1 == 0x1 goto pc+1
6: (b7) r1 = -1
7: (15) if r1 == 0xffffffff goto pc+1
9: (b4) (u32) r1 = (u32) -1
10: (15) if r1 == 0xffffffff goto pc+2
13: (b4) (u32) r0 = (u32) 43
14: (95) exit

Verifier output on 4.4.122+ with this patch:

0: (b7) r1 = 1
1: (15) if r1 == 0x1 goto pc+1
3: (b4) (u32) r1 = (u32) 1
4: (15) if r1 == 0x1 goto pc+1
6: (b7) r1 = -1
7: (15) if r1 == 0xffffffff goto pc+1
9: (b4) (u32) r1 = (u32) -1
10: (15) if r1 == 0xffffffff goto pc+2
R1=inv R10=fp
11: (b4) (u32) r0 = (u32) 42
12: (95) exit

from 10 to 13: R1=imm-1 R10=fp
13: (b4) (u32) r0 = (u32) 43
14: (95) exit


Signed-off-by: Jann Horn <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/bpf/verifier.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1135,7 +1135,8 @@ static int check_alu_op(struct verifier_
regs[insn->dst_reg].type = UNKNOWN_VALUE;
regs[insn->dst_reg].map_ptr = NULL;
}
- } else {
+ } else if (BPF_CLASS(insn->code) == BPF_ALU64 ||
+ insn->imm >= 0) {
/* case: R = imm
* remember the value we stored into this reg
*/



2018-03-19 20:08:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 130/134] btrfs: alloc_chunk: fix DUP stripe size handling

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

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

From: Hans van Kranenburg <[email protected]>

commit 92e222df7b8f05c565009c7383321b593eca488b upstream.

In case of using DUP, we search for enough unallocated disk space on a
device to hold two stripes.

The devices_info[ndevs-1].max_avail that holds the amount of unallocated
space found is directly assigned to stripe_size, while it's actually
twice the stripe size.

Later on in the code, an unconditional division of stripe_size by
dev_stripes corrects the value, but in the meantime there's a check to
see if the stripe_size does not exceed max_chunk_size. Since during this
check stripe_size is twice the amount as intended, the check will reduce
the stripe_size to max_chunk_size if the actual correct to be used
stripe_size is more than half the amount of max_chunk_size.

The unconditional division later tries to correct stripe_size, but will
actually make sure we can't allocate more than half the max_chunk_size.

Fix this by moving the division by dev_stripes before the max chunk size
check, so it always contains the right value, instead of putting a duct
tape division in further on to get it fixed again.

Since in all other cases than DUP, dev_stripes is 1, this change only
affects DUP.

Other attempts in the past were made to fix this:
* 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried
to fix the same problem, but still resulted in part of the code acting
on a wrongly doubled stripe_size value.
* 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally
broke this fix again.

The real problem was already introduced with the rest of the code in
73c5de0051.

The user visible result however will be that the max chunk size for DUP
will suddenly double, while it's actually acting according to the limits
in the code again like it was 5 years ago.

Reported-by: Naohiro Aota <[email protected]>
Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html
Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation")
Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6")
Signed-off-by: Hans van Kranenburg <[email protected]>
Reviewed-by: David Sterba <[email protected]>
[ update comment ]
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/volumes.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)

--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4638,10 +4638,13 @@ static int __btrfs_alloc_chunk(struct bt
if (devs_max && ndevs > devs_max)
ndevs = devs_max;
/*
- * the primary goal is to maximize the number of stripes, so use as many
- * devices as possible, even if the stripes are not maximum sized.
+ * The primary goal is to maximize the number of stripes, so use as
+ * many devices as possible, even if the stripes are not maximum sized.
+ *
+ * The DUP profile stores more than one stripe per device, the
+ * max_avail is the total size so we have to adjust.
*/
- stripe_size = devices_info[ndevs-1].max_avail;
+ stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes);
num_stripes = ndevs * dev_stripes;

/*
@@ -4681,8 +4684,6 @@ static int __btrfs_alloc_chunk(struct bt
stripe_size = devices_info[ndevs-1].max_avail;
}

- stripe_size = div_u64(stripe_size, dev_stripes);
-
/* align to BTRFS_STRIPE_LEN */
stripe_size = div_u64(stripe_size, raid_stripe_len);
stripe_size *= raid_stripe_len;



2018-03-19 20:10:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 123/134] fs/aio: Add explicit RCU grace period when freeing kioctx

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

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

From: Tejun Heo <[email protected]>

commit a6d7cff472eea87d96899a20fa718d2bab7109f3 upstream.

While fixing refcounting, e34ecee2ae79 ("aio: Fix a trinity splat")
incorrectly removed explicit RCU grace period before freeing kioctx.
The intention seems to be depending on the internal RCU grace periods
of percpu_ref; however, percpu_ref uses a different flavor of RCU,
sched-RCU. This can lead to kioctx being freed while RCU read
protected dereferences are still in progress.

Fix it by updating free_ioctx() to go through call_rcu() explicitly.

v2: Comment added to explain double bouncing.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Jann Horn <[email protected]>
Fixes: e34ecee2ae79 ("aio: Fix a trinity splat")
Cc: Kent Overstreet <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: [email protected] # v3.13+
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/aio.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)

--- a/fs/aio.c
+++ b/fs/aio.c
@@ -115,7 +115,8 @@ struct kioctx {
struct page **ring_pages;
long nr_pages;

- struct work_struct free_work;
+ struct rcu_head free_rcu;
+ struct work_struct free_work; /* see free_ioctx() */

/*
* signals when all in-flight requests are done
@@ -573,6 +574,12 @@ static int kiocb_cancel(struct aio_kiocb
return cancel(&kiocb->common);
}

+/*
+ * free_ioctx() should be RCU delayed to synchronize against the RCU
+ * protected lookup_ioctx() and also needs process context to call
+ * aio_free_ring(), so the double bouncing through kioctx->free_rcu and
+ * ->free_work.
+ */
static void free_ioctx(struct work_struct *work)
{
struct kioctx *ctx = container_of(work, struct kioctx, free_work);
@@ -586,6 +593,14 @@ static void free_ioctx(struct work_struc
kmem_cache_free(kioctx_cachep, ctx);
}

+static void free_ioctx_rcufn(struct rcu_head *head)
+{
+ struct kioctx *ctx = container_of(head, struct kioctx, free_rcu);
+
+ INIT_WORK(&ctx->free_work, free_ioctx);
+ schedule_work(&ctx->free_work);
+}
+
static void free_ioctx_reqs(struct percpu_ref *ref)
{
struct kioctx *ctx = container_of(ref, struct kioctx, reqs);
@@ -594,8 +609,8 @@ static void free_ioctx_reqs(struct percp
if (ctx->rq_wait && atomic_dec_and_test(&ctx->rq_wait->count))
complete(&ctx->rq_wait->comp);

- INIT_WORK(&ctx->free_work, free_ioctx);
- schedule_work(&ctx->free_work);
+ /* Synchronize against RCU protected table->table[] dereferences */
+ call_rcu(&ctx->free_rcu, free_ioctx_rcufn);
}

/*
@@ -817,7 +832,7 @@ static int kill_ioctx(struct mm_struct *
table->table[ctx->id] = NULL;
spin_unlock(&mm->ioctx_lock);

- /* percpu_ref_kill() will do the necessary call_rcu() */
+ /* free_ioctx_reqs() will do the necessary RCU synchronization */
wake_up_all(&ctx->wait);

/*



2018-03-19 20:11:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 077/134] pwm: tegra: Increase precision in PWM rate calculation

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

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

From: Laxman Dewangan <[email protected]>


[ Upstream commit 250b76f43f57d578ebff5e7211eb2c73aa5cd6ca ]

The rate of the PWM calculated as follows:

hz = NSEC_PER_SEC / period_ns;
rate = (rate + (hz / 2)) / hz;

This has the precision loss in lower PWM rate.

Change this to have more precision as:

hz = DIV_ROUND_CLOSEST_ULL(NSEC_PER_SEC * 100, period_ns);
rate = DIV_ROUND_CLOSEST(rate * 100, hz)

Example:

1. period_ns = 16672000, PWM clock rate is 200 KHz.

Based on old formula
hz = NSEC_PER_SEC / period_ns
= 1000000000ul/16672000
= 59 (59.98)
rate = (200K + 59/2)/59 = 3390

Based on new method:
hz = 5998
rate = DIV_ROUND_CLOSE(200000*100, 5998) = 3334

If we measure the PWM signal rate, we will get more accurate
period with rate value of 3334 instead of 3390.

2. period_ns = 16803898, PWM clock rate is 200 KHz.

Based on old formula:
hz = 59, rate = 3390

Based on new formula:
hz = 5951, rate = 3360

The PWM signal rate of 3360 is more near to requested period
than 3333.

Signed-off-by: Laxman Dewangan <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pwm/pwm-tegra.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -69,6 +69,7 @@ static int tegra_pwm_config(struct pwm_c
struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
unsigned long long c;
unsigned long rate, hz;
+ unsigned long long ns100 = NSEC_PER_SEC;
u32 val = 0;
int err;

@@ -87,9 +88,11 @@ static int tegra_pwm_config(struct pwm_c
* cycles at the PWM clock rate will take period_ns nanoseconds.
*/
rate = clk_get_rate(pc->clk) >> PWM_DUTY_WIDTH;
- hz = NSEC_PER_SEC / period_ns;

- rate = (rate + (hz / 2)) / hz;
+ /* Consider precision in PWM_SCALE_WIDTH rate calculation */
+ ns100 *= 100;
+ hz = DIV_ROUND_CLOSEST_ULL(ns100, period_ns);
+ rate = DIV_ROUND_CLOSEST(rate * 100, hz);

/*
* Since the actual PWM divider is the register's frequency divider



2018-03-19 20:11:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 071/134] perf inject: Copy events when reordering events in pipe mode

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

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

From: David Carrillo-Cisneros <[email protected]>


[ Upstream commit 1e0d4f0200e4dbdfc38d818f329d8a0955f7c6f5 ]

__perf_session__process_pipe_events reuses the same memory buffer to
process all events in the pipe.

When reordering is needed (e.g. -b option), events are not immediately
flushed, but kept around until reordering is possible, causing
memory corruption.

The problem is usually observed by a "Unknown sample error" output. It
can easily be reproduced by:

perf record -o - noploop | perf inject -b > output

Committer testing:

Before:

$ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null
stress: info: [8297] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [8297] successful run completed in 2s
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
Warning:
Found 1 unknown events!

Is this an older tool processing a perf.data file generated by a more recent tool?

If that is not the case, consider reporting to [email protected].

$

After:

$ perf record -o - stress -t 2 -c 2 | perf inject -b > /dev/null
stress: info: [9027] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [9027] successful run completed in 2s
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.000 MB - ]
no symbols found in /usr/bin/stress, maybe install a debug package?
no symbols found in /usr/bin/stress, maybe install a debug package?
$

Signed-off-by: David Carrillo-Cisneros <[email protected]>
Tested-by: Arnaldo Carvalho de Melo <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: He Kuang <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Paul Turner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Simon Que <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Wang Nan <[email protected]>
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/util/ordered-events.c | 3 ++-
tools/perf/util/session.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)

--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -79,7 +79,7 @@ static union perf_event *dup_event(struc

static void free_dup_event(struct ordered_events *oe, union perf_event *event)
{
- if (oe->copy_on_queue) {
+ if (event && oe->copy_on_queue) {
oe->cur_alloc_size -= event->header.size;
free(event);
}
@@ -150,6 +150,7 @@ void ordered_events__delete(struct order
list_move(&event->list, &oe->cache);
oe->nr_events--;
free_dup_event(oe, event->event);
+ event->event = NULL;
}

int ordered_events__queue(struct ordered_events *oe, union perf_event *event,
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1437,6 +1437,7 @@ static int __perf_session__process_pipe_
buf = malloc(cur_size);
if (!buf)
return -errno;
+ ordered_events__set_copy_on_queue(oe, true);
more:
event = buf;
err = readn(fd, event, sizeof(struct perf_event_header));



2018-03-19 20:11:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 109/134] ima: relax requiring a file signature for new files with zero length

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

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

From: Mimi Zohar <[email protected]>


[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]

Custom policies can require file signatures based on LSM labels. These
files are normally created and only afterwards labeled, requiring them
to be signed.

Instead of requiring file signatures based on LSM labels, entire
filesystems could require file signatures. In this case, we need the
ability of writing new files without requiring file signatures.

The definition of a "new" file was originally defined as any file with
a length of zero. Subsequent patches redefined a "new" file to be based
on the FILE_CREATE open flag. By combining the open flag with a file
size of zero, this patch relaxes the file signature requirement.

Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
Signed-off-by: Mimi Zohar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/integrity/ima/ima_appraise.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -206,7 +206,8 @@ int ima_appraise_measurement(int func, s
if (opened & FILE_CREATED)
iint->flags |= IMA_NEW_FILE;
if ((iint->flags & IMA_NEW_FILE) &&
- !(iint->flags & IMA_DIGSIG_REQUIRED))
+ (!(iint->flags & IMA_DIGSIG_REQUIRED) ||
+ (inode->i_size == 0)))
status = INTEGRITY_PASS;
goto out;
}



2018-03-19 20:13:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 103/134] agp/intel: Flush all chipset writes after updating the GGTT

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

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

From: Chris Wilson <[email protected]>


[ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ]

Before accessing the GGTT we must flush the PTE writes and make them
visible to the chipset, or else the indirect access may end up in the
wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes
after updating a single PTE"), we noticed corruption of the uploads for
pwrite and for capturing GPU error states, but it was presumed that the
explicit calls to intel_gtt_chipset_flush() were sufficient for the
execbuffer path. However, we have not been flushing the chipset between
the PTE writes and access via the GTT itself.

For simplicity, do the flush after any PTE update rather than try and
batch the flushes on a just-in-time basis.

References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: [email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/agp/intel-gtt.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -859,6 +859,8 @@ void intel_gtt_insert_sg_entries(struct
}
}
wmb();
+ if (intel_private.driver->chipset_flush)
+ intel_private.driver->chipset_flush();
}
EXPORT_SYMBOL(intel_gtt_insert_sg_entries);




2018-03-19 20:14:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 075/134] kprobes/x86: Fix kprobe-booster not to boost far call instructions

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

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

From: Masami Hiramatsu <[email protected]>


[ Upstream commit bd0b90676c30fe640e7ead919b3e38846ac88ab7 ]

Fix the kprobe-booster not to boost far call instruction,
because a call may store the address in the single-step
execution buffer to the stack, which should be modified
after single stepping.

Currently, this instruction will be filtered as not
boostable in resume_execution(), so this is not a
critical issue.

Signed-off-by: Masami Hiramatsu <[email protected]>
Cc: Ananth N Mavinakayanahalli <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Anil S Keshavamurthy <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David S . Miller <[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]>
Cc: Ye Xiaolong <[email protected]>
Link: http://lkml.kernel.org/r/149076340615.22469.14066273186134229909.stgit@devbox
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/kprobes/core.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -196,6 +196,8 @@ retry:
return (opcode != 0x62 && opcode != 0x67);
case 0x70:
return 0; /* can't boost conditional jump */
+ case 0x90:
+ return opcode != 0x9a; /* can't boost call far */
case 0xc0:
/* can't boost software-interruptions */
return (0xc1 < opcode && opcode < 0xcc) || opcode == 0xcf;



2018-03-19 20:15:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 101/134] veth: set peer GSO values

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

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

From: Stephen Hemminger <[email protected]>


[ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ]

When new veth is created, and GSO values have been configured
on one device, clone those values to the peer.

For example:
# ip link add dev vm1 gso_max_size 65530 type veth peer name vm2

This should create vm1 <--> vm2 with both having GSO maximum
size set to 65530.

Signed-off-by: Stephen Hemminger <[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/veth.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -399,6 +399,9 @@ static int veth_newlink(struct net *src_
if (ifmp && (dev->ifindex != 0))
peer->ifindex = ifmp->ifi_index;

+ peer->gso_max_size = dev->gso_max_size;
+ peer->gso_max_segs = dev->gso_max_segs;
+
err = register_netdevice(peer);
put_net(net);
net = NULL;



2018-03-19 20:16:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 106/134] ASoC: nuc900: Fix a loop timeout test

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

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

From: Dan Carpenter <[email protected]>


[ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ]

We should be finishing the loop with timeout set to zero but because
this is a post-op we finish with timeout == -1.

Fixes: 1082e2703a2d ("ASoC: NUC900/audio: add nuc900 audio driver support")
Signed-off-by: Dan Carpenter <[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/nuc900/nuc900-ac97.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/soc/nuc900/nuc900-ac97.c
+++ b/sound/soc/nuc900/nuc900-ac97.c
@@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(s

/* polling the AC_R_FINISH */
while (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_R_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);

if (!timeout) {
@@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd

/* polling the AC_W_FINISH */
while ((AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON) & AC_W_FINISH)
- && timeout--)
+ && --timeout)
mdelay(1);

if (!timeout)



2018-03-19 20:17:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 098/134] scsi: devinfo: apply to HP XP the same flags as Hitachi VSP

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

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

From: Xose Vazquez Perez <[email protected]>


[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]

Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI
OPEN-V blacklist entry") modified some Hitachi entries:

HITACHI is always supporting VPD pages, even though it's claiming to
support SCSI Revision 3 only.

The same should have been done also for HP-rebranded.

[mkp: checkpatch and tweaked commit message]

Cc: Hannes Reinecke <[email protected]>
Cc: Takahiro Yasui <[email protected]>
Cc: Matthias Rudolph <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: James E.J. Bottomley <[email protected]>
Cc: SCSI ML <[email protected]>
Signed-off-by: Xose Vazquez Perez <[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/scsi_devinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -180,7 +180,7 @@ static struct {
{"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */
- {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */
+ {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */
{"HP", "NetRAID-4M", NULL, BLIST_FORCELUN},
{"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD},
{"HP", "C1557A", NULL, BLIST_FORCELUN},



2018-03-19 20:17:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 091/134] ath10k: update tdls teardown state to target

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

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

From: Manikanta Pubbisetty <[email protected]>


[ Upstream commit 424ea0d174e82365f85c6770225dba098b8f1d5f ]

It is required to update the teardown state of the peer when
a tdls link with that peer is terminated. This information is
useful for the target to perform some cleanups wrt the tdls peer.

Without proper cleanup, target assumes that the peer is connected and
blocks future connection requests, updating the teardown state of the
peer addresses the problem.

Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.

Signed-off-by: Manikanta Pubbisetty <[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/mac.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5497,6 +5497,16 @@ static int ath10k_sta_state(struct ieee8
"mac vdev %d peer delete %pM (sta gone)\n",
arvif->vdev_id, sta->addr);

+ if (sta->tdls) {
+ ret = ath10k_mac_tdls_peer_update(ar, arvif->vdev_id,
+ sta,
+ WMI_TDLS_PEER_STATE_TEARDOWN);
+ if (ret)
+ ath10k_warn(ar, "failed to update tdls peer state for %pM state %d: %i\n",
+ sta->addr,
+ WMI_TDLS_PEER_STATE_TEARDOWN, ret);
+ }
+
ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
if (ret)
ath10k_warn(ar, "failed to delete peer %pM for vdev %d: %i\n",



2018-03-19 20:17:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 094/134] ath10k: fix invalid STS_CAP_OFFSET_MASK

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

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

From: Ben Greear <[email protected]>


[ Upstream commit 8cec57f5277ef0e354e37a0bf909dc71bc1f865b ]

The 10.4 firmware defines this as a 3-bit field, as does the
mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF
at least in the firmware header I have seen. This patch
fixes the ath10k wmi header to match the firmware.

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/wmi.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4826,7 +4826,8 @@ enum wmi_10_4_vdev_param {
#define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)

#define WMI_TXBF_STS_CAP_OFFSET_LSB 4
-#define WMI_TXBF_STS_CAP_OFFSET_MASK 0xf0
+#define WMI_TXBF_STS_CAP_OFFSET_MASK 0x70
+#define WMI_TXBF_CONF_IMPLICIT_BF BIT(7)
#define WMI_BF_SOUND_DIM_OFFSET_LSB 8
#define WMI_BF_SOUND_DIM_OFFSET_MASK 0xf00




2018-03-19 20:18:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 073/134] scsi: sg: check for valid direction before starting the request

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

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

From: Johannes Thumshirn <[email protected]>


[ Upstream commit 28676d869bbb5257b5f14c0c95ad3af3a7019dd5 ]

Check for a valid direction before starting the request, otherwise we
risk running into an assertion in the scsi midlayer checking for valid
requests.

[mkp: fixed typo]

Signed-off-by: Johannes Thumshirn <[email protected]>
Link: http://www.spinics.net/lists/linux-scsi/msg104400.html
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: Hannes Reinecke <[email protected]>
Tested-by: Johannes Thumshirn <[email protected]>
Reviewed-by: Christoph Hellwig <[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/sg.c | 46 ++++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -674,18 +674,14 @@ sg_write(struct file *filp, const char _
* is a non-zero input_size, so emit a warning.
*/
if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) {
- static char cmd[TASK_COMM_LEN];
- if (strcmp(current->comm, cmd)) {
- printk_ratelimited(KERN_WARNING
- "sg_write: data in/out %d/%d bytes "
- "for SCSI command 0x%x-- guessing "
- "data in;\n program %s not setting "
- "count and/or reply_len properly\n",
- old_hdr.reply_len - (int)SZ_SG_HEADER,
- input_size, (unsigned int) cmnd[0],
- current->comm);
- strcpy(cmd, current->comm);
- }
+ printk_ratelimited(KERN_WARNING
+ "sg_write: data in/out %d/%d bytes "
+ "for SCSI command 0x%x-- guessing "
+ "data in;\n program %s not setting "
+ "count and/or reply_len properly\n",
+ old_hdr.reply_len - (int)SZ_SG_HEADER,
+ input_size, (unsigned int) cmnd[0],
+ current->comm);
}
k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
return (k < 0) ? k : count;
@@ -764,6 +760,29 @@ sg_new_write(Sg_fd *sfp, struct file *fi
return count;
}

+static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
+{
+ switch (hp->dxfer_direction) {
+ case SG_DXFER_NONE:
+ if (hp->dxferp || hp->dxfer_len > 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
+ case SG_DXFER_FROM_DEV:
+ case SG_DXFER_TO_FROM_DEV:
+ if (!hp->dxferp || hp->dxfer_len == 0)
+ return false;
+ return true;
+ case SG_DXFER_UNKNOWN:
+ if ((!hp->dxferp && hp->dxfer_len) ||
+ (hp->dxferp && hp->dxfer_len == 0))
+ return false;
+ return true;
+ default:
+ return false;
+ }
+}
+
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -784,6 +803,9 @@ sg_common_write(Sg_fd * sfp, Sg_request
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));

+ if (!sg_is_valid_dxfer(hp))
+ return -EINVAL;
+
k = sg_start_req(srp, cmnd);
if (k) {
SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,



2018-03-19 20:18:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 089/134] ARM: dts: omap3-n900: Fix the audio CODECs reset pin

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

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

From: "Andrew F. Davis" <[email protected]>


[ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]

The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.

Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support")

Signed-off-by: Andrew F. Davis <[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/omap3-n900.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -488,7 +488,7 @@
tlv320aic3x: tlv320aic3x@18 {
compatible = "ti,tlv320aic3x";
reg = <0x18>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
ai3x-gpio-func = <
0 /* AIC3X_GPIO1_FUNC_DISABLED */
5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -505,7 +505,7 @@
tlv320aic3x_aux: tlv320aic3x@19 {
compatible = "ti,tlv320aic3x";
reg = <0x19>;
- gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
+ reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */

AVDD-supply = <&vmmc2>;
DRVDD-supply = <&vmmc2>;



2018-03-19 20:19:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 088/134] ARM: dts: am335x-pepper: Fix the audio CODECs reset pin

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

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

From: "Andrew F. Davis" <[email protected]>


[ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]

The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.

Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")

Signed-off-by: Andrew F. Davis <[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/am335x-pepper.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -139,7 +139,7 @@
&audio_codec {
status = "okay";

- gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
AVDD-supply = <&ldo3_reg>;
IOVDD-supply = <&ldo3_reg>;
DRVDD-supply = <&ldo3_reg>;



2018-03-19 20:19:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 083/134] sched: Stop switched_to_rt() from sending IPIs to offline CPUs

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

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

From: "Paul E. McKenney" <[email protected]>


[ Upstream commit 2fe2582649aa2355f79acddb86bd4d6c5363eb63 ]

The rcutorture test suite occasionally provokes a splat due to invoking
rt_mutex_lock() which needs to boost the priority of a task currently
sitting on a runqueue that belongs to an offline CPU:

WARNING: CPU: 0 PID: 12 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40
Modules linked in:
CPU: 0 PID: 12 Comm: rcub/7 Not tainted 4.14.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: ffff9ed3de5f8cc0 task.stack: ffffbbf80012c000
RIP: 0010:native_smp_send_reschedule+0x37/0x40
RSP: 0018:ffffbbf80012fd10 EFLAGS: 00010082
RAX: 000000000000002f RBX: ffff9ed3dd9cb300 RCX: 0000000000000004
RDX: 0000000080000004 RSI: 0000000000000086 RDI: 00000000ffffffff
RBP: ffffbbf80012fd10 R08: 000000000009da7a R09: 0000000000007b9d
R10: 0000000000000001 R11: ffffffffbb57c2cd R12: 000000000000000d
R13: ffff9ed3de5f8cc0 R14: 0000000000000061 R15: ffff9ed3ded59200
FS: 0000000000000000(0000) GS:ffff9ed3dea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000080686f0 CR3: 000000001b9e0000 CR4: 00000000000006f0
Call Trace:
resched_curr+0x61/0xd0
switched_to_rt+0x8f/0xa0
rt_mutex_setprio+0x25c/0x410
task_blocks_on_rt_mutex+0x1b3/0x1f0
rt_mutex_slowlock+0xa9/0x1e0
rt_mutex_lock+0x29/0x30
rcu_boost_kthread+0x127/0x3c0
kthread+0x104/0x140
? rcu_report_unblock_qs_rnp+0x90/0x90
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x22/0x30
Code: f0 00 0f 92 c0 84 c0 74 14 48 8b 05 34 74 c5 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 a0 c6 fc b9 e8 d5 b5 06 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 a2 d1 13 02 85 c0 75 38 55 48

But the target task's priority has already been adjusted, so the only
purpose of switched_to_rt() invoking resched_curr() is to wake up the
CPU running some task that needs to be preempted by the boosted task.
But the CPU is offline, which presumably means that the task must be
migrated to some other CPU, and that this other CPU will undertake any
needed preemption at the time of migration. Because the runqueue lock
is held when resched_curr() is invoked, we know that the boosted task
cannot go anywhere, so it is not necessary to invoke resched_curr()
in this particular case.

This commit therefore makes switched_to_rt() refrain from invoking
resched_curr() when the target CPU is offline.

Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched/rt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2144,7 +2144,7 @@ static void switched_to_rt(struct rq *rq
if (p->nr_cpus_allowed > 1 && rq->rt.overloaded)
queue_push_tasks(rq);
#endif /* CONFIG_SMP */
- if (p->prio < rq->curr->prio)
+ if (p->prio < rq->curr->prio && cpu_online(cpu_of(rq)))
resched_curr(rq);
}
}



2018-03-19 20:19:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 086/134] net: xfrm: allow clearing socket xfrm policies.

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

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

From: Lorenzo Colitti <[email protected]>


[ Upstream commit be8f8284cd897af2482d4e54fbc2bdfc15557259 ]

Currently it is possible to add or update socket policies, but
not clear them. Therefore, once a socket policy has been applied,
the socket cannot be used for unencrypted traffic.

This patch allows (privileged) users to clear socket policies by
passing in a NULL pointer and zero length argument to the
{IP,IPV6}_{IPSEC,XFRM}_POLICY setsockopts. This results in both
the incoming and outgoing policies being cleared.

The simple approach taken in this patch cannot clear socket
policies in only one direction. If desired this could be added
in the future, for example by continuing to pass in a length of
zero (which currently is guaranteed to return EMSGSIZE) and
making the policy be a pointer to an integer that contains one
of the XFRM_POLICY_{IN,OUT} enum values.

An alternative would have been to interpret the length as a
signed integer and use XFRM_POLICY_IN (i.e., 0) to clear the
input policy and -XFRM_POLICY_OUT (i.e., -1) to clear the output
policy.

Tested: https://android-review.googlesource.com/539816
Signed-off-by: Lorenzo Colitti <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/xfrm/xfrm_policy.c | 2 +-
net/xfrm/xfrm_state.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)

--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1313,7 +1313,7 @@ EXPORT_SYMBOL(xfrm_policy_delete);

int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
{
- struct net *net = xp_net(pol);
+ struct net *net = sock_net(sk);
struct xfrm_policy *old_pol;

#ifdef CONFIG_XFRM_SUB_POLICY
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1845,6 +1845,13 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;

+ if (!optval && !optlen) {
+ xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
+ xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
+ __sk_dst_reset(sk);
+ return 0;
+ }
+
if (optlen <= 0 || optlen > PAGE_SIZE)
return -EMSGSIZE;




2018-03-19 20:19:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 084/134] sched: Stop resched_cpu() from sending IPIs to offline CPUs

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

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

From: "Paul E. McKenney" <[email protected]>


[ Upstream commit a0982dfa03efca6c239c52cabebcea4afb93ea6b ]

The rcutorture test suite occasionally provokes a splat due to invoking
resched_cpu() on an offline CPU:

WARNING: CPU: 2 PID: 8 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40
Modules linked in:
CPU: 2 PID: 8 Comm: rcu_preempt Not tainted 4.14.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: ffff902ede9daf00 task.stack: ffff96c50010c000
RIP: 0010:native_smp_send_reschedule+0x37/0x40
RSP: 0018:ffff96c50010fdb8 EFLAGS: 00010096
RAX: 000000000000002e RBX: ffff902edaab4680 RCX: 0000000000000003
RDX: 0000000080000003 RSI: 0000000000000000 RDI: 00000000ffffffff
RBP: ffff96c50010fdb8 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 00000000299f36ae R12: 0000000000000001
R13: ffffffff9de64240 R14: 0000000000000001 R15: ffffffff9de64240
FS: 0000000000000000(0000) GS:ffff902edfc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f7d4c642 CR3: 000000001e0e2000 CR4: 00000000000006e0
Call Trace:
resched_curr+0x8f/0x1c0
resched_cpu+0x2c/0x40
rcu_implicit_dynticks_qs+0x152/0x220
force_qs_rnp+0x147/0x1d0
? sync_rcu_exp_select_cpus+0x450/0x450
rcu_gp_kthread+0x5a9/0x950
kthread+0x142/0x180
? force_qs_rnp+0x1d0/0x1d0
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x27/0x40
Code: 14 01 0f 92 c0 84 c0 74 14 48 8b 05 14 4f f4 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 38 89 ca 9d e8 e5 56 08 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 52 9e 37 02 85 c0 75 38 55 48
---[ end trace 26df9e5df4bba4ac ]---

This splat cannot be generated by expedited grace periods because they
always invoke resched_cpu() on the current CPU, which is good because
expedited grace periods require that resched_cpu() unconditionally
succeed. However, other parts of RCU can tolerate resched_cpu() acting
as a no-op, at least as long as it doesn't happen too often.

This commit therefore makes resched_cpu() invoke resched_curr() only if
the CPU is either online or is the current CPU.

Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -601,7 +601,8 @@ void resched_cpu(int cpu)
unsigned long flags;

raw_spin_lock_irqsave(&rq->lock, flags);
- resched_curr(rq);
+ if (cpu_online(cpu) || cpu == smp_processor_id())
+ resched_curr(rq);
raw_spin_unlock_irqrestore(&rq->lock, flags);
}




2018-03-19 20:21:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 041/134] powerpc/mm/hugetlb: Filter out hugepage size not supported by page table layout

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

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

From: "Aneesh Kumar K.V" <[email protected]>


[ Upstream commit a525108cf1cc14651602d678da38fa627a76a724 ]

Without this if firmware reports 1MB page size support we will crash
trying to use 1MB as hugetlb page size.

echo 300 > /sys/kernel/mm/hugepages/hugepages-1024kB/nr_hugepages

kernel BUG at ./arch/powerpc/include/asm/hugetlb.h:19!
.....
....
[c0000000e2c27b30] c00000000029dae8 .hugetlb_fault+0x638/0xda0
[c0000000e2c27c30] c00000000026fb64 .handle_mm_fault+0x844/0x1d70
[c0000000e2c27d70] c00000000004805c .do_page_fault+0x3dc/0x7c0
[c0000000e2c27e30] c00000000000ac98 handle_page_fault+0x10/0x30

With fix, we don't enable 1MB as hugepage size.

bash-4.2# cd /sys/kernel/mm/hugepages/
bash-4.2# ls
hugepages-16384kB hugepages-16777216kB

Signed-off-by: Aneesh Kumar K.V <[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/mm/hugetlbpage.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -828,6 +828,24 @@ static int __init add_huge_page_size(uns
if ((mmu_psize = shift_to_mmu_psize(shift)) < 0)
return -EINVAL;

+#ifdef CONFIG_PPC_BOOK3S_64
+ /*
+ * We need to make sure that for different page sizes reported by
+ * firmware we only add hugetlb support for page sizes that can be
+ * supported by linux page table layout.
+ * For now we have
+ * Radix: 2M
+ * Hash: 16M and 16G
+ */
+ if (radix_enabled()) {
+ if (mmu_psize != MMU_PAGE_2M)
+ return -EINVAL;
+ } else {
+ if (mmu_psize != MMU_PAGE_16M && mmu_psize != MMU_PAGE_16G)
+ return -EINVAL;
+ }
+#endif
+
BUG_ON(mmu_psize_defs[mmu_psize].shift != shift);

/* Return if huge page size has already been setup */



2018-03-19 20:21:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 072/134] perf session: Dont rely on evlist in pipe mode

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

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

From: David Carrillo-Cisneros <[email protected]>


[ Upstream commit 0973ad97c187e06aece61f685b9c3b2d93290a73 ]

Session sets a number parameters that rely on evlist. These parameters
are not used in pipe-mode and should not be set, since evlist is
unavailable. Fix that.

Signed-off-by: David Carrillo-Cisneros <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: He Kuang <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Paul Turner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Simon Que <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Wang Nan <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ Check if file != NULL in perf_session__new(), like when used by builtin-top.c ]
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/util/session.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -135,8 +135,14 @@ struct perf_session *perf_session__new(s
if (perf_session__open(session) < 0)
goto out_close;

- perf_session__set_id_hdr_size(session);
- perf_session__set_comm_exec(session);
+ /*
+ * set session attributes that are present in perf.data
+ * but not in pipe-mode.
+ */
+ if (!file->is_pipe) {
+ perf_session__set_id_hdr_size(session);
+ perf_session__set_comm_exec(session);
+ }
}
} else {
session->machines.host.env = &perf_env;
@@ -151,7 +157,11 @@ struct perf_session *perf_session__new(s
pr_warning("Cannot read kernel map\n");
}

- if (tool && tool->ordering_requires_timestamps &&
+ /*
+ * In pipe-mode, evlist is empty until PERF_RECORD_HEADER_ATTR is
+ * processed, so perf_evlist__sample_id_all is not meaningful here.
+ */
+ if ((!file || !file->is_pipe) && tool && tool->ordering_requires_timestamps &&
tool->ordered_events && !perf_evlist__sample_id_all(session->evlist)) {
dump_printf("WARNING: No sample_id_all support, falling back to unordered processing\n");
tool->ordered_events = false;



2018-03-19 20:21:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 085/134] test_firmware: fix setting old custom fw path back on exit

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

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

From: "Luis R. Rodriguez" <[email protected]>


[ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]

The file /sys/module/firmware_class/parameters/path can be used
to set a custom firmware path. The fw_filesystem.sh script creates
a temporary directory to add a test firmware file to be used during
testing, in order for this to work it uses the custom path syfs file
and it was supposed to reset back the file on execution exit. The
script failed to do this due to a typo, it was using OLD_PATH instead
of OLD_FWPATH, since its inception since v3.17.

Its not as easy to just keep the old setting, it turns out that
resetting an empty setting won't actually do what we want, we need
to check if it was empty and set an empty space.

Without this we end up having the temporary path always set after
we run these tests.

Fixes: 0a8adf58475 ("test: add firmware_class loader test")
Signed-off-by: Luis R. Rodriguez <[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]>
---
tools/testing/selftests/firmware/fw_filesystem.sh | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -28,7 +28,10 @@ test_finish()
if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
fi
- echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path
+ if [ "$OLD_FWPATH" = "" ]; then
+ OLD_FWPATH=" "
+ fi
+ echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
rm -f "$FW"
rmdir "$FWPATH"
}



2018-03-19 20:21:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 082/134] ARM: dts: exynos: Correct Trats2 panel reset line

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

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

From: Simon Shields <[email protected]>


[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]

Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used
on early revisions of the board.

Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node")
Signed-off-by: Simon Shields <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -359,7 +359,7 @@
reg = <0>;
vdd3-supply = <&lcd_vdd3_reg>;
vci-supply = <&ldo25_reg>;
- reset-gpios = <&gpy4 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;



2018-03-19 20:22:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 043/134] drm/vmwgfx: Fixes to vmwgfx_fb

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

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

From: Sinclair Yeh <[email protected]>


[ Upstream commit aa74f0687cfe998e59b20d6454f45e8aa4403c45 ]

1. When unsetting a mode, num_connector should be set to zero
2. The pixel_format field needs to be initialized as newer DRM internal
functions checks this field
3. Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can
change current mode

Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -433,7 +433,7 @@ static int vmw_fb_kms_detach(struct vmw_
set.y = 0;
set.mode = NULL;
set.fb = NULL;
- set.num_connectors = 1;
+ set.num_connectors = 0;
set.connectors = &par->con;
ret = drm_mode_set_config_internal(&set);
if (ret) {
@@ -821,7 +821,9 @@ int vmw_fb_off(struct vmw_private *vmw_p
flush_delayed_work(&par->local_work);

mutex_lock(&par->bo_mutex);
+ drm_modeset_lock_all(vmw_priv->dev);
(void) vmw_fb_kms_detach(par, true, false);
+ drm_modeset_unlock_all(vmw_priv->dev);
mutex_unlock(&par->bo_mutex);

return 0;



2018-03-19 20:24:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 067/134] md/raid6: Fix anomily when recovering a single device in RAID6.

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

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

From: NeilBrown <[email protected]>


[ Upstream commit 7471fb77ce4dc4cb81291189947fcdf621a97987 ]

When recoverying a single missing/failed device in a RAID6,
those stripes where the Q block is on the missing device are
handled a bit differently. In these cases it is easy to
check that the P block is correct, so we do. This results
in the P block be destroy. Consequently the P block needs
to be read a second time in order to compute Q. This causes
lots of seeks and hurts performance.

It shouldn't be necessary to re-read P as it can be computed
from the DATA. But we only compute blocks on missing
devices, since c337869d9501 ("md: do not compute parity
unless it is on a failed drive").

So relax the change made in that commit to allow computing
of the P block in a RAID6 which it is the only missing that
block.

This makes RAID6 recovery run much faster as the disk just
"before" the recovering device is no longer seeking
back-and-forth.

Reported-by-tested-by: Brad Campbell <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Signed-off-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/raid5.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3372,9 +3372,20 @@ static int fetch_block(struct stripe_hea
BUG_ON(test_bit(R5_Wantcompute, &dev->flags));
BUG_ON(test_bit(R5_Wantread, &dev->flags));
BUG_ON(sh->batch_head);
+
+ /*
+ * In the raid6 case if the only non-uptodate disk is P
+ * then we already trusted P to compute the other failed
+ * drives. It is safe to compute rather than re-read P.
+ * In other cases we only compute blocks from failed
+ * devices, otherwise check/repair might fail to detect
+ * a real inconsistency.
+ */
+
if ((s->uptodate == disks - 1) &&
+ ((sh->qd_idx >= 0 && sh->pd_idx == disk_idx) ||
(s->failed && (disk_idx == s->failed_num[0] ||
- disk_idx == s->failed_num[1]))) {
+ disk_idx == s->failed_num[1])))) {
/* have disk failed, and we're requested to fetch it;
* do compute it
*/



2018-03-19 20:24:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 062/134] MIPS: BPF: Quit clobbering callee saved registers in JIT code.

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

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

From: David Daney <[email protected]>


[ Upstream commit 1ef0910cfd681f0bd0b81f8809935b2006e9cfb9 ]

If bpf_needs_clear_a() returns true, only actually clear it if it is
ever used. If it is not used, we don't save and restore it, so the
clearing has the nasty side effect of clobbering caller state.

Also, don't emit stack pointer adjustment instructions if the
adjustment amount is zero.

Signed-off-by: David Daney <[email protected]>
Cc: James Hogan <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Steven J. Hill <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15745/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/net/bpf_jit.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)

--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -527,7 +527,8 @@ static void save_bpf_jit_regs(struct jit
u32 sflags, tmp_flags;

/* Adjust the stack pointer */
- emit_stack_offset(-align_sp(offset), ctx);
+ if (offset)
+ emit_stack_offset(-align_sp(offset), ctx);

tmp_flags = sflags = ctx->flags >> SEEN_SREG_SFT;
/* sflags is essentially a bitmap */
@@ -579,7 +580,8 @@ static void restore_bpf_jit_regs(struct
emit_load_stack_reg(r_ra, r_sp, real_off, ctx);

/* Restore the sp and discard the scrach memory */
- emit_stack_offset(align_sp(offset), ctx);
+ if (offset)
+ emit_stack_offset(align_sp(offset), ctx);
}

static unsigned int get_stack_depth(struct jit_ctx *ctx)
@@ -626,8 +628,14 @@ static void build_prologue(struct jit_ct
if (ctx->flags & SEEN_X)
emit_jit_reg_move(r_X, r_zero, ctx);

- /* Do not leak kernel data to userspace */
- if (bpf_needs_clear_a(&ctx->skf->insns[0]))
+ /*
+ * Do not leak kernel data to userspace, we only need to clear
+ * r_A if it is ever used. In fact if it is never used, we
+ * will not save/restore it, so clearing it in this case would
+ * corrupt the state of the caller.
+ */
+ if (bpf_needs_clear_a(&ctx->skf->insns[0]) &&
+ (ctx->flags & SEEN_A))
emit_jit_reg_move(r_A, r_zero, ctx);
}




2018-03-19 20:24:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 057/134] iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range

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

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

From: Nate Watterson <[email protected]>


[ Upstream commit 5016bdb796b3726eec043ca0ce3be981f712c756 ]

Normally, calling alloc_iova() using an iova_domain with insufficient
pfns remaining between start_pfn and dma_limit will fail and return a
NULL pointer. Unexpectedly, if such a "full" iova_domain contains an
iova with pfn_lo == 0, the alloc_iova() call will instead succeed and
return an iova containing invalid pfns.

This is caused by an underflow bug in __alloc_and_insert_iova_range()
that occurs after walking the "full" iova tree when the search ends
at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just
below that (-1). This (now huge) limit_pfn gives the impression that a
vast amount of space is available between it and start_pfn and thus
a new iova is allocated with the invalid pfn_hi value, 0xFFF.... .

To rememdy this, a check is introduced to ensure that adjustments to
limit_pfn will not underflow.

This issue has been observed in the wild, and is easily reproduced with
the following sample code.

struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
struct iova *rsvd_iova, *good_iova, *bad_iova;
unsigned long limit_pfn = 3;
unsigned long start_pfn = 1;
unsigned long va_size = 2;

init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn);
rsvd_iova = reserve_iova(iovad, 0, 0);
good_iova = alloc_iova(iovad, va_size, limit_pfn, true);
bad_iova = alloc_iova(iovad, va_size, limit_pfn, true);

Prior to the patch, this yielded:
*rsvd_iova == {0, 0} /* Expected */
*good_iova == {2, 3} /* Expected */
*bad_iova == {-2, -1} /* Oh no... */

After the patch, bad_iova is NULL as expected since inadequate
space remains between limit_pfn and start_pfn after allocating
good_iova.

Signed-off-by: Nate Watterson <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iommu/iova.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -126,7 +126,7 @@ static int __alloc_and_insert_iova_range
break; /* found a free slot */
}
adjust_limit_pfn:
- limit_pfn = curr_iova->pfn_lo - 1;
+ limit_pfn = curr_iova->pfn_lo ? (curr_iova->pfn_lo - 1) : 0;
move_left:
prev = curr;
curr = rb_prev(curr);



2018-03-19 20:25:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 063/134] MIPS: BPF: Fix multiple problems in JIT skb access helpers.

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

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

From: David Daney <[email protected]>


[ Upstream commit a81507c79f4ae9a0f9fb1054b59b62a090620dd9 ]

o Socket data is unsigned, so use unsigned accessors instructions.

o Fix path result pointer generation arithmetic.

o Fix half-word byte swapping code for unsigned semantics.

Signed-off-by: David Daney <[email protected]>
Cc: James Hogan <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Steven J. Hill <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15747/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/net/bpf_jit_asm.S | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)

--- a/arch/mips/net/bpf_jit_asm.S
+++ b/arch/mips/net/bpf_jit_asm.S
@@ -90,18 +90,14 @@ FEXPORT(sk_load_half_positive)
is_offset_in_header(2, half)
/* Offset within header boundaries */
PTR_ADDU t1, $r_skb_data, offset
- .set reorder
- lh $r_A, 0(t1)
- .set noreorder
+ lhu $r_A, 0(t1)
#ifdef CONFIG_CPU_LITTLE_ENDIAN
# if defined(__mips_isa_rev) && (__mips_isa_rev >= 2)
- wsbh t0, $r_A
- seh $r_A, t0
+ wsbh $r_A, $r_A
# else
- sll t0, $r_A, 24
- andi t1, $r_A, 0xff00
- sra t0, t0, 16
- srl t1, t1, 8
+ sll t0, $r_A, 8
+ srl t1, $r_A, 8
+ andi t0, t0, 0xff00
or $r_A, t0, t1
# endif
#endif
@@ -115,7 +111,7 @@ FEXPORT(sk_load_byte_positive)
is_offset_in_header(1, byte)
/* Offset within header boundaries */
PTR_ADDU t1, $r_skb_data, offset
- lb $r_A, 0(t1)
+ lbu $r_A, 0(t1)
jr $r_ra
move $r_ret, zero
END(sk_load_byte)
@@ -139,6 +135,11 @@ FEXPORT(sk_load_byte_positive)
* (void *to) is returned in r_s0
*
*/
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#define DS_OFFSET(SIZE) (4 * SZREG)
+#else
+#define DS_OFFSET(SIZE) ((4 * SZREG) + (4 - SIZE))
+#endif
#define bpf_slow_path_common(SIZE) \
/* Quick check. Are we within reasonable boundaries? */ \
LONG_ADDIU $r_s1, $r_skb_len, -SIZE; \
@@ -150,7 +151,7 @@ FEXPORT(sk_load_byte_positive)
PTR_LA t0, skb_copy_bits; \
PTR_S $r_ra, (5 * SZREG)($r_sp); \
/* Assign low slot to a2 */ \
- move a2, $r_sp; \
+ PTR_ADDIU a2, $r_sp, DS_OFFSET(SIZE); \
jalr t0; \
/* Reset our destination slot (DS but it's ok) */ \
INT_S zero, (4 * SZREG)($r_sp); \



2018-03-19 20:25:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 056/134] apparmor: Make path_max parameter readonly

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

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

From: John Johansen <[email protected]>


[ Upstream commit 622f6e3265707ebf02ba776ac6e68003bcc31213 ]

The path_max parameter determines the max size of buffers allocated
but it should not be setable at run time. If can be used to cause an
oops

root@ubuntu:~# echo 16777216 > /sys/module/apparmor/parameters/path_max
root@ubuntu:~# cat /sys/module/apparmor/parameters/path_max
Killed

[ 122.141911] BUG: unable to handle kernel paging request at ffff880080945fff
[ 122.143497] IP: [<ffffffff81228844>] d_absolute_path+0x44/0xa0
[ 122.144742] PGD 220c067 PUD 0
[ 122.145453] Oops: 0002 [#1] SMP
[ 122.146204] Modules linked in: vmw_vsock_vmci_transport vsock ppdev vmw_balloon snd_ens1371 btusb snd_ac97_codec gameport snd_rawmidi btrtl snd_seq_device ac97_bus btbcm btintel snd_pcm input_leds bluetooth snd_timer snd joydev soundcore serio_raw coretemp shpchp nfit parport_pc i2c_piix4 8250_fintek vmw_vmci parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd vmwgfx psmouse mptspi ttm mptscsih drm_kms_helper mptbase syscopyarea scsi_transport_spi sysfillrect
[ 122.163365] ahci sysimgblt e1000 fb_sys_fops libahci drm pata_acpi fjes
[ 122.164747] CPU: 3 PID: 1501 Comm: bash Not tainted 4.4.0-59-generic #80-Ubuntu
[ 122.166250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[ 122.168611] task: ffff88003496aa00 ti: ffff880076474000 task.ti: ffff880076474000
[ 122.170018] RIP: 0010:[<ffffffff81228844>] [<ffffffff81228844>] d_absolute_path+0x44/0xa0
[ 122.171525] RSP: 0018:ffff880076477b90 EFLAGS: 00010206
[ 122.172462] RAX: ffff880080945fff RBX: 0000000000000000 RCX: 0000000001000000
[ 122.173709] RDX: 0000000000ffffff RSI: ffff880080946000 RDI: ffff8800348a1010
[ 122.174978] RBP: ffff880076477bb8 R08: ffff880076477c80 R09: 0000000000000000
[ 122.176227] R10: 00007ffffffff000 R11: ffff88007f946000 R12: ffff88007f946000
[ 122.177496] R13: ffff880076477c80 R14: ffff8800348a1010 R15: ffff8800348a2400
[ 122.178745] FS: 00007fd459eb4700(0000) GS:ffff88007b6c0000(0000) knlGS:0000000000000000
[ 122.180176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 122.181186] CR2: ffff880080945fff CR3: 0000000073422000 CR4: 00000000001406e0
[ 122.182469] Stack:
[ 122.182843] 00ffffff00000001 ffff880080946000 0000000000000000 0000000000000000
[ 122.184409] 00000000570f789c ffff880076477c30 ffffffff81385671 ffff88007a2e7a58
[ 122.185810] 0000000000000000 ffff880076477c88 01000000008a1000 0000000000000000
[ 122.187231] Call Trace:
[ 122.187680] [<ffffffff81385671>] aa_path_name+0x81/0x370
[ 122.188637] [<ffffffff813875dd>] profile_transition+0xbd/0xb80
[ 122.190181] [<ffffffff811af9bc>] ? zone_statistics+0x7c/0xa0
[ 122.191674] [<ffffffff81389b20>] apparmor_bprm_set_creds+0x9b0/0xac0
[ 122.193288] [<ffffffff812e1971>] ? ext4_xattr_get+0x81/0x220
[ 122.194793] [<ffffffff812e800c>] ? ext4_xattr_security_get+0x1c/0x30
[ 122.196392] [<ffffffff813449b9>] ? get_vfs_caps_from_disk+0x69/0x110
[ 122.198004] [<ffffffff81232d4f>] ? mnt_may_suid+0x3f/0x50
[ 122.199737] [<ffffffff81344b03>] ? cap_bprm_set_creds+0xa3/0x600
[ 122.201377] [<ffffffff81346e53>] security_bprm_set_creds+0x33/0x50
[ 122.203024] [<ffffffff81214ce5>] prepare_binprm+0x85/0x190
[ 122.204515] [<ffffffff81216545>] do_execveat_common.isra.33+0x485/0x710
[ 122.206200] [<ffffffff81216a6a>] SyS_execve+0x3a/0x50
[ 122.207615] [<ffffffff81838795>] stub_execve+0x5/0x5
[ 122.208978] [<ffffffff818384f2>] ? entry_SYSCALL_64_fastpath+0x16/0x71
[ 122.210615] Code: f8 31 c0 48 63 c2 83 ea 01 48 c7 45 e8 00 00 00 00 48 01 c6 85 d2 48 c7 45 f0 00 00 00 00 48 89 75 e0 89 55 dc 78 0c 48 8d 46 ff <c6> 46 ff 00 48 89 45 e0 48 8d 55 e0 48 8d 4d dc 48 8d 75 e8 e8
[ 122.217320] RIP [<ffffffff81228844>] d_absolute_path+0x44/0xa0
[ 122.218860] RSP <ffff880076477b90>
[ 122.219919] CR2: ffff880080945fff
[ 122.220936] ---[ end trace 506cdbd85eb6c55e ]---

Reported-by: Tetsuo Handa <[email protected]>
Signed-off-by: John Johansen <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/apparmor/lsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -722,7 +722,7 @@ module_param_named(logsyscall, aa_g_logs

/* Maximum pathname length before accesses will start getting rejected */
unsigned int aa_g_path_max = 2 * PATH_MAX;
-module_param_named(path_max, aa_g_path_max, aauint, S_IRUSR | S_IWUSR);
+module_param_named(path_max, aa_g_path_max, aauint, S_IRUSR);

/* Determines how paranoid loading of policy is and how much verification
* on the loaded policy is done.



2018-03-19 20:25:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 037/134] blk-throttle: make sure expire time isnt too big

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

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

From: Shaohua Li <[email protected]>


[ Upstream commit 06cceedcca67a93ac7f7aa93bbd9980c7496d14e ]

cgroup could be throttled to a limit but when all cgroups cross high
limit, queue enters a higher state and so the group should be throttled
to a higher limit. It's possible the cgroup is sleeping because of
throttle and other cgroups don't dispatch IO any more. In this case,
nobody can trigger current downgrade/upgrade logic. To fix this issue,
we could either set up a timer to wakeup the cgroup if other cgroups are
idle or make sure this cgroup doesn't sleep too long. Setting up a timer
means we must change the timer very frequently. This patch chooses the
latter. Making cgroup sleep time not too big wouldn't change cgroup
bps/iops, but could make it wakeup more frequently, which isn't a big
issue because throtl_slice * 8 is already quite big.

Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
block/blk-throttle.c | 11 +++++++++++
1 file changed, 11 insertions(+)

--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -505,6 +505,17 @@ static void throtl_dequeue_tg(struct thr
static void throtl_schedule_pending_timer(struct throtl_service_queue *sq,
unsigned long expires)
{
+ unsigned long max_expire = jiffies + 8 * throtl_slice;
+
+ /*
+ * Since we are adjusting the throttle limit dynamically, the sleep
+ * time calculated according to previous limit might be invalid. It's
+ * possible the cgroup sleep time is very long and no other cgroups
+ * have IO running so notify the limit changes. Make sure the cgroup
+ * doesn't sleep too long to avoid the missed notification.
+ */
+ if (time_after(expires, max_expire))
+ expires = max_expire;
mod_timer(&sq->pending_timer, expires);
throtl_log(sq, "schedule timer. delay=%lu jiffies=%lu",
expires - jiffies, jiffies);



2018-03-19 20:26:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 054/134] fm10k: correctly check if interface is removed

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

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

From: Phil Turnbull <[email protected]>


[ Upstream commit 540fca35e38d15777b310f450f63f056e63039f5 ]

FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'.

Fixes: 5cb8db4a4cbc ("fm10k: Add support for VF")
Signed-off-by: Phil Turnbull <[email protected]>
Tested-by: Krishneil Singh <[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/fm10k/fm10k_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
@@ -983,7 +983,7 @@ static void fm10k_self_test(struct net_d

memset(data, 0, sizeof(*data) * FM10K_TEST_LEN);

- if (FM10K_REMOVED(hw)) {
+ if (FM10K_REMOVED(hw->hw_addr)) {
netif_err(interface, drv, dev,
"Interface removed - test blocked\n");
eth_test->flags |= ETH_TEST_FL_FAILED;



2018-03-19 20:26:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 046/134] NFC: nfcmrvl: double free on error path

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

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

From: Dan Carpenter <[email protected]>


[ Upstream commit ca42fb9e52d155547e6cf18cf26bce3e1a6af4ea ]

The nci_spi_send() function calls kfree_skb(skb) on both error and
success so this extra kfree_skb() is a double free.

Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nfc/nfcmrvl/spi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/nfc/nfcmrvl/spi.c
+++ b/drivers/nfc/nfcmrvl/spi.c
@@ -96,10 +96,9 @@ static int nfcmrvl_spi_nci_send(struct n
/* Send the SPI packet */
err = nci_spi_send(drv_data->nci_spi, &drv_data->handshake_completion,
skb);
- if (err != 0) {
+ if (err)
nfc_err(priv->dev, "spi_send failed %d", err);
- kfree_skb(skb);
- }
+
return err;
}




2018-03-19 20:27:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 036/134] mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative()

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

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

From: "Kirill A. Shutemov" <[email protected]>


[ Upstream commit 591a3d7c09fa08baff48ad86c2347dbd28a52753 ]

0day testing by Fengguang Wu triggered this crash while running Trinity:

kernel BUG at include/linux/pagemap.h:151!
...
CPU: 0 PID: 458 Comm: trinity-c0 Not tainted 4.11.0-rc2-00251-g2947ba0 #1
...
Call Trace:
__get_user_pages_fast()
get_user_pages_fast()
get_futex_key()
futex_requeue()
do_futex()
SyS_futex()
do_syscall_64()
entry_SYSCALL64_slow_path()

It' VM_BUG_ON() due to false-negative in_atomic(). We call
page_cache_get_speculative() with disabled local interrupts.
It should be atomic enough.

So let's check for disabled interrupts in the VM_BUG_ON() condition
too, to resolve this.

( This got triggered by the conversion of the x86 GUP code to the
generic GUP code. )

Reported-by: Fengguang Wu <[email protected]>
Signed-off-by: Kirill A. Shutemov <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Aneesh Kumar K.V <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: LKP <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [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]>
---
include/linux/pagemap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -153,7 +153,7 @@ static inline int page_cache_get_specula

#ifdef CONFIG_TINY_RCU
# ifdef CONFIG_PREEMPT_COUNT
- VM_BUG_ON(!in_atomic());
+ VM_BUG_ON(!in_atomic() && !irqs_disabled());
# endif
/*
* Preempt must be disabled here - we rely on rcu_read_lock doing
@@ -191,7 +191,7 @@ static inline int page_cache_add_specula

#if !defined(CONFIG_SMP) && defined(CONFIG_TREE_RCU)
# ifdef CONFIG_PREEMPT_COUNT
- VM_BUG_ON(!in_atomic());
+ VM_BUG_ON(!in_atomic() && !irqs_disabled());
# endif
VM_BUG_ON_PAGE(page_count(page) == 0, page);
atomic_add(count, &page->_count);



2018-03-19 20:28:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 050/134] net/faraday: Add missing include of of.h

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

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

From: Andrew Lunn <[email protected]>


[ Upstream commit d39004ab136ebb6949a7dda9d24376f3d6209295 ]

Breaking the include loop netdevice.h, dsa.h, devlink.h broke this
driver, it depends on includes brought in by these headers. Adding
linux/of.h fixes it.

Fixes: ed0e39e97d34 ("net: break include loop netdevice.h, dsa.h, devlink.h")
Signed-off-by: Andrew Lunn <[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/faraday/ftgmac100.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -28,6 +28,7 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/netdevice.h>
+#include <linux/of.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <net/ip.h>



2018-03-19 20:28:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 045/134] NFC: nfcmrvl: Include unaligned.h instead of access_ok.h

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

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

From: Tobias Klauser <[email protected]>


[ Upstream commit d916d923724d59cde99ee588f15eec59dd863bbd ]

Including linux/unaligned/access_ok.h causes the allmodconfig build on
ia64 (and maybe others) to fail with the following warnings:

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32'
include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64'
include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16'
include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32'
include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64'
include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64'

Fix these by including asm/unaligned.h instead and leave it up to the
architecture to decide how to implement unaligned accesses.

Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Reported-by: kbuild test robot <[email protected]>
Link: https://lkml.org/lkml/2016/10/22/247
Cc: Vincent Cuissard <[email protected]>
Signed-off-by: Tobias Klauser <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nfc/nfcmrvl/fw_dnld.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,7 +17,7 @@
*/

#include <linux/module.h>
-#include <linux/unaligned/access_ok.h>
+#include <asm/unaligned.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
#include <net/nfc/nci.h>



2018-03-19 20:28:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 009/134] PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

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

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

From: Prarit Bhargava <[email protected]>


[ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]

The pci_bus_type .shutdown method, pci_device_shutdown(), is called from
device_shutdown() in the kernel restart and shutdown paths.

Previously, pci_device_shutdown() called pci_msi_shutdown() and
pci_msix_shutdown(). This disables MSI and MSI-X, which causes the device
to fall back to raising interrupts via INTx. But the driver is still bound
to the device, it doesn't know about this change, and it likely doesn't
have an INTx handler, so these INTx interrupts cause "nobody cared"
warnings like this:

irq 16: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1
Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/
...

The MSI disabling code was added by d52877c7b1af ("pci/irq: let
pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
enabled and kdump failed because the kexeced kernel wasn't prepared to
receive the MSI interrupts.

Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even
if kernel doesn't support MSI") and e80e7edc55ba ("PCI/MSI: Initialize MSI
capability for all architectures") changed the kexeced kernel to disable
all MSIs itself so it no longer depends on the crashed kernel to clean up
after itself.

Stop disabling MSI/MSI-X in pci_device_shutdown(). This resolves the
"nobody cared" unhandled IRQ issue above. It also allows PCI serial
devices, which may rely on the MSI interrupts, to continue outputting
messages during reboot/shutdown.

[bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls
altogether]
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351
Signed-off-by: Prarit Bhargava <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Alex Williamson <[email protected]>
CC: David Arcari <[email protected]>
CC: Myron Stowe <[email protected]>
CC: Lukas Wunner <[email protected]>
CC: Keith Busch <[email protected]>
CC: Mika Westerberg <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/pci-driver.c | 2 --
1 file changed, 2 deletions(-)

--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -463,8 +463,6 @@ static void pci_device_shutdown(struct d

if (drv && drv->shutdown)
drv->shutdown(pci_dev);
- pci_msi_shutdown(pci_dev);
- pci_msix_shutdown(pci_dev);

#ifdef CONFIG_KEXEC_CORE
/*



2018-03-19 20:29:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 049/134] powerpc: Avoid taking a data miss on every userspace instruction miss

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

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

From: Anton Blanchard <[email protected]>


[ Upstream commit a7a9dcd882a67b68568868b988289fce5ffd8419 ]

Early on in do_page_fault() we call store_updates_sp(), regardless of
the type of exception. For an instruction miss this doesn't make
sense, because we only use this information to detect if a data miss
is the result of a stack expansion instruction or not.

Worse still, it results in a data miss within every userspace
instruction miss handler, because we try and load the very instruction
we are about to install a pte for!

A simple exec microbenchmark runs 6% faster on POWER8 with this fix:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
unsigned long left = atol(argv[1]);
char leftstr[16];

if (left-- == 0)
return 0;

sprintf(leftstr, "%ld", left);
execlp(argv[0], argv[0], leftstr, NULL);
perror("exec failed\n");

return 0;
}

Pass the number of iterations on the command line (eg 10000) and time
how long it takes to execute.

Signed-off-by: Anton Blanchard <[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/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -294,7 +294,7 @@ int __kprobes do_page_fault(struct pt_re
* can result in fault, which will cause a deadlock when called with
* mmap_sem held
*/
- if (user_mode(regs))
+ if (!is_exec && user_mode(regs))
store_update_sp = store_updates_sp(regs);

if (user_mode(regs))



2018-03-19 20:30:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 034/134] dmaengine: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

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

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

From: Jiada Wang <[email protected]>


[ Upstream commit 7f3ff14b7eb1ffad132117f08a1973b48e653d43 ]

sdma_disable_channel() cannot ensure dma is stopped to access
module's FIFOs. There is chance SDMA core is running and accessing
BD when disable of corresponding channel, this may cause sometimes
even after call of .sdma_disable_channel(), SDMA core still be
running and accessing module's FIFOs.

According to NXP R&D team a delay of one BD SDMA cost time (maximum
is 1ms) should be added after disable of the channel bit, to ensure
SDMA core has really been stopped after SDMA clients call
.device_terminate_all.

This patch introduces adds a new function sdma_disable_channel_with_delay()
which simply adds 1ms delay after call sdma_disable_channel(),
and set it as .device_terminate_all.

Signed-off-by: Jiada Wang <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)

--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -911,6 +911,21 @@ static int sdma_disable_channel(struct d
return 0;
}

+static int sdma_disable_channel_with_delay(struct dma_chan *chan)
+{
+ sdma_disable_channel(chan);
+
+ /*
+ * According to NXP R&D team a delay of one BD SDMA cost time
+ * (maximum is 1ms) should be added after disable of the channel
+ * bit, to ensure SDMA core has really been stopped after SDMA
+ * clients call .device_terminate_all.
+ */
+ mdelay(1);
+
+ return 0;
+}
+
static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
{
struct sdma_engine *sdma = sdmac->sdma;
@@ -1793,7 +1808,7 @@ static int sdma_probe(struct platform_de
sdma->dma_device.device_prep_slave_sg = sdma_prep_slave_sg;
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
- sdma->dma_device.device_terminate_all = sdma_disable_channel;
+ sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);



2018-03-19 20:30:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 032/134] spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer

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

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

From: Akinobu Mita <[email protected]>


[ Upstream commit 812613591cb652344186c4cd912304ed02138566 ]

When running the spi-loopback-test with slower clock rate like 10 KHz,
the test for 251 bytes transfer was failed. This failure triggered an
spi-omap2-mcspi's error message "DMA RX last word empty".

This message means that PIO for reading the remaining bytes due to the
DMA transfer length reduction is failed. This problem can be fixed by
polling OMAP2_MCSPI_CHSTAT_RXS bit in channel status register to wait
until the receive buffer register is filled.

Cc: Mark Brown <[email protected]>
Signed-off-by: Akinobu Mita <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spi-omap2-mcspi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -457,6 +457,8 @@ omap2_mcspi_rx_dma(struct spi_device *sp
int elements = 0;
int word_len, element_count;
struct omap2_mcspi_cs *cs = spi->controller_state;
+ void __iomem *chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0;
+
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
count = xfer->len;
@@ -517,8 +519,8 @@ omap2_mcspi_rx_dma(struct spi_device *sp
if (l & OMAP2_MCSPI_CHCONF_TURBO) {
elements--;

- if (likely(mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHSTAT0)
- & OMAP2_MCSPI_CHSTAT_RXS)) {
+ if (!mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_RXS)) {
u32 w;

w = mcspi_read_cs_reg(spi, OMAP2_MCSPI_RX0);
@@ -536,8 +538,7 @@ omap2_mcspi_rx_dma(struct spi_device *sp
return count;
}
}
- if (likely(mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHSTAT0)
- & OMAP2_MCSPI_CHSTAT_RXS)) {
+ if (!mcspi_wait_for_reg_bit(chstat_reg, OMAP2_MCSPI_CHSTAT_RXS)) {
u32 w;

w = mcspi_read_cs_reg(spi, OMAP2_MCSPI_RX0);



2018-03-19 20:31:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 007/134] ath10k: fix a warning during channel switch with multiple vaps

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

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

From: Mohammed Shafi Shajakhan <[email protected]>


[ Upstream commit c73f8c00330f59ce9b1ace9ff698aca83390d358 ]

Doing a channel switch via hostapd_cli seems to update
the new channel context for each VAP's appropriately as below
in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
warning that shows up during this operation and dump the warning only
if no vaps are available for channel switch

hostapd_cli -i wlan0 chan_switch 5 5200
OK

ath10k_pci : mac chanctx switch n_vifs 3 mode 1
ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0

Call Trace:

WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
[<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>]
(ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
[<bf7f150c>] (ath10k_reconfig_complete [ath10k_core])
[<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
[<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
[<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
[<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
[<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211])
[<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])

Fixes: d7bf4b4aba05 ("ath10k: fix ar->rx_channel updating logic")
Signed-off-by: Mohammed Shafi Shajakhan <[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/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6427,7 +6427,7 @@ ath10k_mac_update_rx_channel(struct ath1
lockdep_assert_held(&ar->data_lock);

WARN_ON(ctx && vifs);
- WARN_ON(vifs && n_vifs != 1);
+ WARN_ON(vifs && !n_vifs);

/* FIXME: Sort of an optimization and a workaround. Peers and vifs are
* on a linked list now. Doing a lookup peer -> vif -> chanctx for each



2018-03-19 20:32:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 029/134] Input: qt1070 - add OF device ID table

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

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

From: Javier Martinez Canillas <[email protected]>


[ Upstream commit cf5cd9d4480a87da78768718cac194a71079b5cb ]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

The compatible strings don't have a vendor prefix because that's how it's
used currently, and changing this will be a Device Tree ABI break.

Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/keyboard/qt1070.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/input/keyboard/qt1070.c
+++ b/drivers/input/keyboard/qt1070.c
@@ -274,9 +274,18 @@ static const struct i2c_device_id qt1070
};
MODULE_DEVICE_TABLE(i2c, qt1070_id);

+#ifdef CONFIG_OF
+static const struct of_device_id qt1070_of_match[] = {
+ { .compatible = "qt1070", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qt1070_of_match);
+#endif
+
static struct i2c_driver qt1070_driver = {
.driver = {
.name = "qt1070",
+ .of_match_table = of_match_ptr(qt1070_of_match),
.pm = &qt1070_pm_ops,
},
.id_table = qt1070_id,



2018-03-19 20:33:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 031/134] ASoC: rcar: ssi: dont set SSICR.CKDV = 000 with SSIWSR.CONT

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

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

From: Kuninori Morimoto <[email protected]>


[ Upstream commit 6b8530cc056efd4a11b034ca5b1e9f7e9563f553 ]

R-Car Datasheet is indicating "SSICR.CKDV = 000 is invalid when
SSIWSR.WS_MODE = 1 or SSIWSR.CONT = 1".
Current driver will set CONT, thus, we shouldn't use CKDV = 000.
This patch fixup it.

Reported-by: Hiroyuki Yokoyama <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Tested-by: Hiroyuki Yokoyama <[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/sh/rcar/ssi.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -143,6 +143,15 @@ static int rsnd_ssi_master_clk_start(str
for (j = 0; j < ARRAY_SIZE(ssi_clk_mul_table); j++) {

/*
+ * It will set SSIWSR.CONT here, but SSICR.CKDV = 000
+ * with it is not allowed. (SSIWSR.WS_MODE with
+ * SSICR.CKDV = 000 is not allowed either).
+ * Skip it. See SSICR.CKDV
+ */
+ if (j == 0)
+ continue;
+
+ /*
* this driver is assuming that
* system word is 64fs (= 2 x 32bit)
* see rsnd_ssi_init()



2018-03-19 20:33:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 002/134] Input: tsc2007 - check for presence and power down tsc2007 during probe

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

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

From: "H. Nikolaus Schaller" <[email protected]>


[ Upstream commit 934df23171e7c5b71d937104d4957891c39748ff ]

1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed

Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/touchscreen/tsc2007.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -455,6 +455,14 @@ static int tsc2007_probe(struct i2c_clie

tsc2007_stop(ts);

+ /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+ err = tsc2007_xfer(ts, PWRDOWN);
+ if (err < 0) {
+ dev_err(&client->dev,
+ "Failed to setup chip: %d\n", err);
+ return err; /* usually, chip does not respond */
+ }
+
err = input_register_device(input_dev);
if (err) {
dev_err(&client->dev,



2018-03-19 20:33:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 003/134] staging: speakup: Replace BUG_ON() with WARN_ON().

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

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

From: Varsha Rao <[email protected]>


[ Upstream commit d351c2db5420bb17dcd2d9aac7ddb5f64c6d04b3 ]

BUG_ON() is replaced with WARN_ON() and EINVAL is returned, when
WARN_ON() is true. This fixes the following checkpatch issue:

Avoid crashing the kernel - try using WARN_ON & recovery code rather
than BUG() or BUG_ON().

Signed-off-by: Varsha Rao <[email protected]>
Reviewed-by: Samuel Thibault <[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/speakup/kobjects.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -831,7 +831,9 @@ static ssize_t message_show(struct kobje
struct msg_group_t *group = spk_find_msg_group(attr->attr.name);
unsigned long flags;

- BUG_ON(!group);
+ if (WARN_ON(!group))
+ return -EINVAL;
+
spin_lock_irqsave(&speakup_info.spinlock, flags);
retval = message_show_helper(buf, group->start, group->end);
spin_unlock_irqrestore(&speakup_info.spinlock, flags);
@@ -843,7 +845,9 @@ static ssize_t message_store(struct kobj
{
struct msg_group_t *group = spk_find_msg_group(attr->attr.name);

- BUG_ON(!group);
+ if (WARN_ON(!group))
+ return -EINVAL;
+
return message_store_helper(buf, count, group);
}




2018-03-19 20:35:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 014/134] perf tools: Make perf_event__synthesize_mmap_events() scale

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

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

From: Stephane Eranian <[email protected]>


[ Upstream commit 88b897a30c525c2eee6e7f16e1e8d0f18830845e ]

This patch significantly improves the execution time of
perf_event__synthesize_mmap_events() when running perf record on systems
where processes have lots of threads.

It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to
generate each map line in the maps file. If you have 1000 threads, then you
have necessarily 1000 stacks. For each vma, you need to check if it
corresponds to a thread's stack. With a large number of threads, this can take
a very long time. I have seen latencies >> 10mn.

As of today, perf does not use the fact that a mapping is a stack, therefore we
can work around the issue by using /proc/pid/tasks/pid/maps. This entry does
not try to map a vma to stack and is thus much faster with no loss of
functonality.

The proc-map-timeout logic is kept in case users still want some upper limit.

In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual
/proc/pid/task/pid/maps, tasks -> task. Thanks Arnaldo for catching this.

Committer note:

This problem seems to have been elliminated in the kernel since commit :
b18cb64ead40 ("fs/proc: Stop trying to report thread stacks").

Signed-off-by: Stephane Eranian <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
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/util/event.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -234,8 +234,8 @@ int perf_event__synthesize_mmap_events(s
if (machine__is_default_guest(machine))
return 0;

- snprintf(filename, sizeof(filename), "%s/proc/%d/maps",
- machine->root_dir, pid);
+ snprintf(filename, sizeof(filename), "%s/proc/%d/task/%d/maps",
+ machine->root_dir, pid, pid);

fp = fopen(filename, "r");
if (fp == NULL) {



2018-03-19 20:35:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 022/134] batman-adv: handle race condition for claims between gateways

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

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

From: Andreas Pape <[email protected]>


[ Upstream commit a3a5129e122709306cfa6409781716c2933df99b ]

Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Acked-by: Simon Wunderlich <[email protected]>
Signed-off-by: Andreas Pape <[email protected]>
[[email protected]: fix conflicts with current version]
Signed-off-by: Sven Eckelmann <[email protected]>
Signed-off-by: Simon Wunderlich <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/batman-adv/bridge_loop_avoidance.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1603,10 +1603,22 @@ int batadv_bla_tx(struct batadv_priv *ba
/* if yes, the client has roamed and we have
* to unclaim it.
*/
- batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
- goto allow;
+ if (batadv_has_timed_out(claim->lasttime, 100)) {
+ /* only unclaim if the last claim entry is
+ * older than 100 ms to make sure we really
+ * have a roaming client here.
+ */
+ batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming client %pM detected. Unclaim it.\n",
+ ethhdr->h_source);
+ batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+ goto allow;
+ } else {
+ batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race for claim %pM detected. Drop packet.\n",
+ ethhdr->h_source);
+ goto handled;
+ }
}

/* check if it is a multicast/broadcast frame */



2018-03-19 20:35:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 013/134] i40e: fix ethtool to get EEPROM data from X722 interface

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

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

From: Lihong Yang <[email protected]>


[ Upstream commit c271dd6c391b535226cf1a81aaad9f33cb5899d3 ]

Currently ethtool -e will error out with a X722 interface
as its EEPROM has a scope limit at offset 0x5B9FFF.
This patch fixes the issue by setting the EEPROM length to
the scope limit to avoid NVM read failure beyond that.

Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372
Signed-off-by: Lihong Yang <[email protected]>
Tested-by: Andrew Bowers <[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/i40e/i40e_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1073,6 +1073,11 @@ static int i40e_get_eeprom_len(struct ne
struct i40e_hw *hw = &np->vsi->back->hw;
u32 val;

+#define X722_EEPROM_SCOPE_LIMIT 0x5B9FFF
+ if (hw->mac.type == I40E_MAC_X722) {
+ val = X722_EEPROM_SCOPE_LIMIT + 1;
+ return val;
+ }
val = (rd32(hw, I40E_GLPCI_LBARCTRL)
& I40E_GLPCI_LBARCTRL_FL_SIZE_MASK)
>> I40E_GLPCI_LBARCTRL_FL_SIZE_SHIFT;



2018-03-19 20:36:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 010/134] selinux: check for address length in selinux_socket_bind()

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

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

From: Alexander Potapenko <[email protected]>


[ Upstream commit e2f586bd83177d22072b275edd4b8b872daba924 ]

KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
uninitialized memory in selinux_socket_bind():

==================================================================
BUG: KMSAN: use of unitialized memory
inter: 0
CPU: 3 PID: 1074 Comm: packet2 Tainted: G B 4.8.0-rc6+ #1916
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48
ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550
0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff825759c8>] dump_stack+0x238/0x290 lib/dump_stack.c:51
[<ffffffff818bdee6>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
[<ffffffff818bf0fb>] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
[<ffffffff822dae71>] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288
[<ffffffff8229357c>] security_socket_bind+0x1ec/0x240 security/security.c:1240
[<ffffffff84265d98>] SYSC_bind+0x358/0x5f0 net/socket.c:1366
[<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
[<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
[<ffffffff8518217c>] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:?
chained origin: 00000000ba6009bb
[<ffffffff810bb7a7>] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
[< inline >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
[< inline >] kmsan_save_stack mm/kmsan/kmsan.c:337
[<ffffffff818bd2b8>] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530
[<ffffffff818bf033>] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380
[<ffffffff84265b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356
[<ffffffff84265a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
[<ffffffff81005678>] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
[<ffffffff8518217c>] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:?
origin description: ----address@SYSC_bind (origin=00000000b8c00900)
==================================================================

(the line numbers are relative to 4.8-rc6, but the bug persists upstream)

, when I run the following program as root:

=======================================================
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>

int main(int argc, char *argv[]) {
struct sockaddr addr;
int size = 0;
if (argc > 1) {
size = atoi(argv[1]);
}
memset(&addr, 0, sizeof(addr));
int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
bind(fd, &addr, size);
return 0;
}
=======================================================

(for different values of |size| other error reports are printed).

This happens because bind() unconditionally copies |size| bytes of
|addr| to the kernel, leaving the rest uninitialized. Then
security_socket_bind() reads the IP address bytes, including the
uninitialized ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.

Signed-off-by: Alexander Potapenko <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
[PM: fixed some whitespace damage]
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/selinux/hooks.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4124,10 +4124,18 @@ static int selinux_socket_bind(struct so
u32 sid, node_perm;

if (family == PF_INET) {
+ if (addrlen < sizeof(struct sockaddr_in)) {
+ err = -EINVAL;
+ goto out;
+ }
addr4 = (struct sockaddr_in *)address;
snum = ntohs(addr4->sin_port);
addrp = (char *)&addr4->sin_addr.s_addr;
} else {
+ if (addrlen < SIN6_LEN_RFC2133) {
+ err = -EINVAL;
+ goto out;
+ }
addr6 = (struct sockaddr_in6 *)address;
snum = ntohs(addr6->sin6_port);
addrp = (char *)&addr6->sin6_addr.s6_addr;



2018-03-19 20:36:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 020/134] net/8021q: create device with all possible features in wanted_features

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

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

From: Andrey Vagin <[email protected]>


[ Upstream commit 88997e4208aea117627898e5f6f9801cf3cd42d2 ]

wanted_features is a set of features which have to be enabled if a
hardware allows that.

Currently when a vlan device is created, its wanted_features is set to
current features of its base device.

The problem is that the base device can get new features and they are
not propagated to vlan-s of this device.

If we look at bonding devices, they doesn't have this problem and this
patch suggests to fix this issue by the same way how it works for bonding
devices.

We meet this problem, when we try to create a vlan device over a bonding
device. When a system are booting, real devices require time to be
initialized, so bonding devices created without slaves, then vlan
devices are created and only then ethernet devices are added to the
bonding device. As a result we have vlan devices with disabled
scatter-gather.

* create a bonding device
$ ip link add bond0 type bond
$ ethtool -k bond0 | grep scatter
scatter-gather: off
tx-scatter-gather: off [requested on]
tx-scatter-gather-fraglist: off [requested on]

* create a vlan device
$ ip link add link bond0 name bond0.10 type vlan id 10
$ ethtool -k bond0.10 | grep scatter
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off

* Add a slave device to bond0
$ ip link set dev eth0 master bond0

And now we can see that the bond0 device has got the scatter-gather
feature, but the bond0.10 hasn't got it.
[root@laptop linux-task-diag]# ethtool -k bond0 | grep scatter
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
[root@laptop linux-task-diag]# ethtool -k bond0.10 | grep scatter
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off

With this patch the vlan device will get all new features from the
bonding device.

Here is a call trace how features which are set in this patch reach
dev->wanted_features.

register_netdevice
vlan_dev_init
...
dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE |
NETIF_F_HIGHDMA | NETIF_F_SCTP_CRC |
NETIF_F_ALL_FCOE;

dev->features |= dev->hw_features;
...
dev->wanted_features = dev->features & dev->hw_features;
__netdev_update_features(dev);
vlan_dev_fix_features
...

Cc: Alexey Kuznetsov <[email protected]>
Cc: Patrick McHardy <[email protected]>
Cc: "David S. Miller" <[email protected]>
Signed-off-by: Andrei Vagin <[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]>
---
net/8021q/vlan_dev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -559,8 +559,7 @@ static int vlan_dev_init(struct net_devi
NETIF_F_HIGHDMA | NETIF_F_SCTP_CSUM |
NETIF_F_ALL_FCOE;

- dev->features |= real_dev->vlan_features | NETIF_F_LLTX |
- NETIF_F_GSO_SOFTWARE;
+ dev->features |= dev->hw_features | NETIF_F_LLTX;
dev->gso_max_size = real_dev->gso_max_size;
if (dev->features & NETIF_F_VLAN_FEATURES)
netdev_warn(real_dev, "VLAN features are set incorrectly. Q-in-Q configurations may not work correctly.\n");



2018-03-19 20:36:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 021/134] ARM: dts: Adjust moxart IRQ controller and flags

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

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

From: Linus Walleij <[email protected]>


[ Upstream commit c2a736b698008d296c5010ec39077eeb5796109f ]

The moxart interrupt line flags were not respected in previous
driver: instead of assigning them per-consumer, a fixes mask
was set in the controller.

With the migration to a standard Faraday driver we need to
set up and handle the consumer flags correctly. Also remove
the Moxart-specific flags when switching to using real consumer
flags.

Extend the register window to 0x100 bytes as we may have a few
more registers in there and it doesn't hurt.

Tested-by: Jonas Jensen <[email protected]>
Signed-off-by: Jonas Jensen <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/moxart-uc7112lx.dts | 2 +-
arch/arm/boot/dts/moxart.dtsi | 17 +++++++++--------
2 files changed, 10 insertions(+), 9 deletions(-)

--- a/arch/arm/boot/dts/moxart-uc7112lx.dts
+++ b/arch/arm/boot/dts/moxart-uc7112lx.dts
@@ -6,7 +6,7 @@
*/

/dts-v1/;
-/include/ "moxart.dtsi"
+#include "moxart.dtsi"

/ {
model = "MOXA UC-7112-LX";
--- a/arch/arm/boot/dts/moxart.dtsi
+++ b/arch/arm/boot/dts/moxart.dtsi
@@ -6,6 +6,7 @@
*/

/include/ "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/irq.h>

/ {
compatible = "moxa,moxart";
@@ -36,8 +37,8 @@
ranges;

intc: interrupt-controller@98800000 {
- compatible = "moxa,moxart-ic";
- reg = <0x98800000 0x38>;
+ compatible = "moxa,moxart-ic", "faraday,ftintc010";
+ reg = <0x98800000 0x100>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-mask = <0x00080000>;
@@ -59,7 +60,7 @@
timer: timer@98400000 {
compatible = "moxa,moxart-timer";
reg = <0x98400000 0x42>;
- interrupts = <19 1>;
+ interrupts = <19 IRQ_TYPE_EDGE_FALLING>;
clocks = <&clk_apb>;
};

@@ -80,7 +81,7 @@
dma: dma@90500000 {
compatible = "moxa,moxart-dma";
reg = <0x90500080 0x40>;
- interrupts = <24 0>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
};

@@ -93,7 +94,7 @@
sdhci: sdhci@98e00000 {
compatible = "moxa,moxart-sdhci";
reg = <0x98e00000 0x5C>;
- interrupts = <5 0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_apb>;
dmas = <&dma 5>,
<&dma 5>;
@@ -120,7 +121,7 @@
mac0: mac@90900000 {
compatible = "moxa,moxart-mac";
reg = <0x90900000 0x90>;
- interrupts = <25 0>;
+ interrupts = <25 IRQ_TYPE_LEVEL_HIGH>;
phy-handle = <&ethphy0>;
phy-mode = "mii";
status = "disabled";
@@ -129,7 +130,7 @@
mac1: mac@92000000 {
compatible = "moxa,moxart-mac";
reg = <0x92000000 0x90>;
- interrupts = <27 0>;
+ interrupts = <27 IRQ_TYPE_LEVEL_HIGH>;
phy-handle = <&ethphy1>;
phy-mode = "mii";
status = "disabled";
@@ -138,7 +139,7 @@
uart0: uart@98200000 {
compatible = "ns16550a";
reg = <0x98200000 0x20>;
- interrupts = <31 8>;
+ interrupts = <31 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clock-frequency = <14745600>;



2018-03-19 20:37:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 001/134] blkcg: fix double free of new_blkg in blkcg_init_queue

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

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

From: Hou Tao <[email protected]>

commit 9b54d816e00425c3a517514e0d677bb3cec49258 upstream.

If blkg_create fails, new_blkg passed as an argument will
be freed by blkg_create, so there is no need to free it again.

Signed-off-by: Hou Tao <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
block/blk-cgroup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -1078,10 +1078,8 @@ int blkcg_init_queue(struct request_queu
if (preloaded)
radix_tree_preload_end();

- if (IS_ERR(blkg)) {
- blkg_free(new_blkg);
+ if (IS_ERR(blkg))
return PTR_ERR(blkg);
- }

q->root_blkg = blkg;
q->root_rl.blkg = blkg;



2018-03-19 20:37:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 012/134] i40e: Acquire NVM lock before reads on all devices

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

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

From: Aaron Salter <[email protected]>


[ Upstream commit 96a39aed25e6559b160786117df124084feb9080 ]

Acquire NVM lock before reads on all devices. Previously, locks were
only used for X722 and later. Fixes an issue where simultaneous X710
NVM accesses were interfering with each other.

Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638
Signed-off-by: Aaron Salter <[email protected]>
Tested-by: Andrew Bowers <[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/i40e/i40e_nvm.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -292,14 +292,14 @@ i40e_status i40e_read_nvm_word(struct i4
{
enum i40e_status_code ret_code = 0;

- if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
- ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
- if (!ret_code) {
+ ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
+ if (!ret_code) {
+ if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
ret_code = i40e_read_nvm_word_aq(hw, offset, data);
- i40e_release_nvm(hw);
+ } else {
+ ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
}
- } else {
- ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
+ i40e_release_nvm(hw);
}
return ret_code;
}



2018-03-19 20:38:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 015/134] drivers: net: xgene: Fix hardware checksum setting

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

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

From: Quan Nguyen <[email protected]>


[ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ]

This patch fixes the hardware checksum settings by properly program
the classifier. Otherwise, packet may be received with checksum error
on X-Gene1 SoC.

Signed-off-by: Quan Nguyen <[email protected]>
Signed-off-by: Iyappan Subramanian <[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/apm/xgene/xgene_enet_hw.c | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
2 files changed, 2 insertions(+)

--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -604,6 +604,7 @@ static void xgene_enet_cle_bypass(struct
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG0_0_ADDR, &cb);
cb |= CFG_CLE_BYPASS_EN0;
CFG_CLE_IP_PROTOCOL0_SET(&cb, 3);
+ CFG_CLE_IP_HDR_LEN_SET(&cb, 0);
xgene_enet_wr_csr(pdata, CLE_BYPASS_REG0_0_ADDR, cb);

xgene_enet_rd_csr(pdata, CLE_BYPASS_REG1_0_ADDR, &cb);
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -147,6 +147,7 @@ enum xgene_enet_rm {
#define CFG_RXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 26, 3)

#define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
+#define CFG_CLE_IP_HDR_LEN_SET(dst, val) xgene_set_bits(dst, val, 8, 5)
#define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12)
#define CFG_CLE_FPSEL0_SET(dst, val) xgene_set_bits(dst, val, 16, 4)
#define CFG_MACMODE_SET(dst, val) xgene_set_bits(dst, val, 18, 2)



2018-03-20 00:30:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 048/134] ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks

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

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

From: Geert Uytterhoeven <[email protected]>


[ Upstream commit 16fe68dcab5702a024d85229ff7e98979cb701a5 ]

The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.

Fixes: ee9141522dcf13f8 ("ARM: shmobile: r8a7791: add MSTP10 support on DTSI")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/r8a7791.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1374,8 +1374,11 @@
compatible = "renesas,r8a7791-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7791_CLK_SSI_ALL>, <&mstp10_clks R8A7791_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>,
<&mstp10_clks R8A7791_CLK_SCU_ALL>, <&mstp10_clks R8A7791_CLK_SCU_ALL>,



2018-03-20 00:31:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 053/134] ALSA: firewire-digi00x: handle all MIDI messages on streaming packets

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

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

From: Takashi Sakamoto <[email protected]>


[ Upstream commit 8820a4cf0cb4cd5c6540a9a18b2cedbdfd5a6891 ]

At a commit 9dc5d31cdceb ("ALSA: firewire-digi00x: handle MIDI messages in
isochronous packets"), a functionality to handle MIDI messages on
isochronous packet was supported. But this includes some of my
misunderstanding. This commit is to fix them.

For digi00x series, first data channel of data blocks in rx/tx packet
includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB,
however it's against IEC 61883-6. Unique data format is applied:
- Upper 4 bits of LSB represent port number.
- 0x0: port 1.
- 0x2: port 2.
- 0xe: console port.
- Lower 4 bits of LSB represent the number of included MIDI message bytes;
0x0/0x1/0x2.
- Two bytes of middle of this data channel have MIDI bytes.

Especially, MIDI messages from/to console surface are also transferred by
isochronous packets, as well as physical MIDI ports.

Signed-off-by: Takashi Sakamoto <[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/firewire/digi00x/amdtp-dot.c | 53 +++++++++++++++++++++++++------------
1 file changed, 36 insertions(+), 17 deletions(-)

--- a/sound/firewire/digi00x/amdtp-dot.c
+++ b/sound/firewire/digi00x/amdtp-dot.c
@@ -28,6 +28,9 @@
*/
#define MAX_MIDI_RX_BLOCKS 8

+/* 3 = MAX(DOT_MIDI_IN_PORTS, DOT_MIDI_OUT_PORTS) + 1. */
+#define MAX_MIDI_PORTS 3
+
/*
* The double-oh-three algorithm was discovered by Robin Gareus and Damien
* Zammit in 2012, with reverse-engineering for Digi 003 Rack.
@@ -42,10 +45,8 @@ struct amdtp_dot {
unsigned int pcm_channels;
struct dot_state state;

- unsigned int midi_ports;
- /* 2 = MAX(DOT_MIDI_IN_PORTS, DOT_MIDI_OUT_PORTS) */
- struct snd_rawmidi_substream *midi[2];
- int midi_fifo_used[2];
+ struct snd_rawmidi_substream *midi[MAX_MIDI_PORTS];
+ int midi_fifo_used[MAX_MIDI_PORTS];
int midi_fifo_limit;

void (*transfer_samples)(struct amdtp_stream *s,
@@ -124,8 +125,8 @@ int amdtp_dot_set_parameters(struct amdt
return -EBUSY;

/*
- * A first data channel is for MIDI conformant data channel, the rest is
- * Multi Bit Linear Audio data channel.
+ * A first data channel is for MIDI messages, the rest is Multi Bit
+ * Linear Audio data channel.
*/
err = amdtp_stream_set_parameters(s, rate, pcm_channels + 1);
if (err < 0)
@@ -135,11 +136,6 @@ int amdtp_dot_set_parameters(struct amdt

p->pcm_channels = pcm_channels;

- if (s->direction == AMDTP_IN_STREAM)
- p->midi_ports = DOT_MIDI_IN_PORTS;
- else
- p->midi_ports = DOT_MIDI_OUT_PORTS;
-
/*
* We do not know the actual MIDI FIFO size of most devices. Just
* assume two bytes, i.e., one byte can be received over the bus while
@@ -281,13 +277,25 @@ static void write_midi_messages(struct a
b = (u8 *)&buffer[0];

len = 0;
- if (port < p->midi_ports &&
+ if (port < MAX_MIDI_PORTS &&
midi_ratelimit_per_packet(s, port) &&
p->midi[port] != NULL)
len = snd_rawmidi_transmit(p->midi[port], b + 1, 2);

if (len > 0) {
- b[3] = (0x10 << port) | len;
+ /*
+ * Upper 4 bits of LSB represent port number.
+ * - 0000b: physical MIDI port 1.
+ * - 0010b: physical MIDI port 2.
+ * - 1110b: console MIDI port.
+ */
+ if (port == 2)
+ b[3] = 0xe0;
+ else if (port == 1)
+ b[3] = 0x20;
+ else
+ b[3] = 0x00;
+ b[3] |= len;
midi_use_bytes(s, port, len);
} else {
b[1] = 0;
@@ -309,11 +317,22 @@ static void read_midi_messages(struct am

for (f = 0; f < data_blocks; f++) {
b = (u8 *)&buffer[0];
- port = b[3] >> 4;
+
len = b[3] & 0x0f;
+ if (len > 0) {
+ /*
+ * Upper 4 bits of LSB represent port number.
+ * - 0000b: physical MIDI port 1. Use port 0.
+ * - 1110b: console MIDI port. Use port 2.
+ */
+ if (b[3] >> 4 > 0)
+ port = 2;
+ else
+ port = 0;

- if (port < p->midi_ports && p->midi[port] && len > 0)
- snd_rawmidi_receive(p->midi[port], b + 1, len);
+ if (port < MAX_MIDI_PORTS && p->midi[port])
+ snd_rawmidi_receive(p->midi[port], b + 1, len);
+ }

buffer += s->data_block_quadlets;
}
@@ -364,7 +383,7 @@ void amdtp_dot_midi_trigger(struct amdtp
{
struct amdtp_dot *p = s->protocol;

- if (port < p->midi_ports)
+ if (port < MAX_MIDI_PORTS)
ACCESS_ONCE(p->midi[port]) = midi;
}




2018-03-20 00:33:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 040/134] bonding: refine bond_fold_stats() wrap detection

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

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

From: Eric Dumazet <[email protected]>


[ Upstream commit 142c6594acbcc32391af9c15f8cd65c6c177698f ]

Some device drivers reset their stats at down/up events, possibly
fooling bonding stats, since they operate with relative deltas.

It is nearly not possible to fix drivers, since some of them compute the
tx/rx counters based on per rx/tx queue stats, and the queues can be
reconfigured (ethtool -L) between the down/up sequence.

Lets avoid accumulating 'negative' values that render bonding stats
useless.

It is better to lose small deltas, assuming the bonding stats are
fetched at a reasonable frequency.

Fixes: 5f0c5f73e5ef ("bonding: make global bonding stats more reliable")
Signed-off-by: Eric Dumazet <[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/bonding/bond_main.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3276,12 +3276,17 @@ static void bond_fold_stats(struct rtnl_
for (i = 0; i < sizeof(*_res) / sizeof(u64); i++) {
u64 nv = new[i];
u64 ov = old[i];
+ s64 delta = nv - ov;

/* detects if this particular field is 32bit only */
if (((nv | ov) >> 32) == 0)
- res[i] += (u32)nv - (u32)ov;
- else
- res[i] += nv - ov;
+ delta = (s64)(s32)((u32)nv - (u32)ov);
+
+ /* filter anomalies, some drivers reset their stats
+ * at down/up events.
+ */
+ if (delta > 0)
+ res[i] += delta;
}
}




2018-03-20 00:34:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 092/134] cpufreq: Fix governor module removal race

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

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

From: "Rafael J. Wysocki" <[email protected]>


[ Upstream commit a8b149d32b663c1a4105273295184b78f53d33cf ]

It is possible to remove a cpufreq governor module after
cpufreq_parse_governor() has returned success in
store_scaling_governor() and before cpufreq_set_policy()
acquires a reference to it, because the governor list is
not protected during that period and nothing prevents the
governor from being unregistered then.

Prevent that from happening by acquiring an extra reference
to the governor module temporarily in cpufreq_parse_governor(),
under cpufreq_governor_mutex, and dropping it in
store_scaling_governor(), when cpufreq_set_policy() returns.

Note that the second cpufreq_parse_governor() call site is fine,
because it only cares about the policy member of new_policy.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/cpufreq.c | 6 ++++++
1 file changed, 6 insertions(+)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -551,6 +551,8 @@ static int cpufreq_parse_governor(char *
*governor = t;
err = 0;
}
+ if (t && !try_module_get(t->owner))
+ t = NULL;

mutex_unlock(&cpufreq_governor_mutex);
}
@@ -669,6 +671,10 @@ static ssize_t store_scaling_governor(st
return -EINVAL;

ret = cpufreq_set_policy(policy, &new_policy);
+
+ if (new_policy.governor)
+ module_put(new_policy.governor->owner);
+
return ret ? ret : count;
}




2018-03-20 00:42:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 118/134] ALSA: seq: Fix possible UAF in snd_seq_check_queue()

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

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

From: Takashi Iwai <[email protected]>

commit d0f833065221cbfcbadf19fd4102bcfa9330006a upstream.

Although we've covered the races between concurrent write() and
ioctl() in the previous patch series, there is still a possible UAF in
the following scenario:

A: user client closed B: timer irq
-> snd_seq_release() -> snd_seq_timer_interrupt()
-> snd_seq_free_client() -> snd_seq_check_queue()
-> cell = snd_seq_prioq_cell_peek()
-> snd_seq_prioq_leave()
.... removing all cells
-> snd_seq_pool_done()
.... vfree()
-> snd_seq_compare_tick_time(cell)
... Oops

So the problem is that a cell is peeked and accessed without any
protection until it's retrieved from the queue again via
snd_seq_prioq_cell_out().

This patch tries to address it, also cleans up the code by a slight
refactoring. snd_seq_prioq_cell_out() now receives an extra pointer
argument. When it's non-NULL, the function checks the event timestamp
with the given pointer. The caller needs to pass the right reference
either to snd_seq_tick or snd_seq_realtime depending on the event
timestamp type.

A good news is that the above change allows us to remove the
snd_seq_prioq_cell_peek(), too, thus the patch actually reduces the
code size.

Reviewed-by: Nicolai Stange <[email protected]>
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/seq/seq_prioq.c | 28 ++++++++++++++--------------
sound/core/seq/seq_prioq.h | 6 ++----
sound/core/seq/seq_queue.c | 28 +++++++++-------------------
3 files changed, 25 insertions(+), 37 deletions(-)

--- a/sound/core/seq/seq_prioq.c
+++ b/sound/core/seq/seq_prioq.c
@@ -87,7 +87,7 @@ void snd_seq_prioq_delete(struct snd_seq
if (f->cells > 0) {
/* drain prioQ */
while (f->cells > 0)
- snd_seq_cell_free(snd_seq_prioq_cell_out(f));
+ snd_seq_cell_free(snd_seq_prioq_cell_out(f, NULL));
}

kfree(f);
@@ -214,8 +214,18 @@ int snd_seq_prioq_cell_in(struct snd_seq
return 0;
}

+/* return 1 if the current time >= event timestamp */
+static int event_is_ready(struct snd_seq_event *ev, void *current_time)
+{
+ if ((ev->flags & SNDRV_SEQ_TIME_STAMP_MASK) == SNDRV_SEQ_TIME_STAMP_TICK)
+ return snd_seq_compare_tick_time(current_time, &ev->time.tick);
+ else
+ return snd_seq_compare_real_time(current_time, &ev->time.time);
+}
+
/* dequeue cell from prioq */
-struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f)
+struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f,
+ void *current_time)
{
struct snd_seq_event_cell *cell;
unsigned long flags;
@@ -227,6 +237,8 @@ struct snd_seq_event_cell *snd_seq_prioq
spin_lock_irqsave(&f->lock, flags);

cell = f->head;
+ if (cell && current_time && !event_is_ready(&cell->event, current_time))
+ cell = NULL;
if (cell) {
f->head = cell->next;

@@ -252,18 +264,6 @@ int snd_seq_prioq_avail(struct snd_seq_p
return f->cells;
}

-
-/* peek at cell at the head of the prioq */
-struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq * f)
-{
- if (f == NULL) {
- pr_debug("ALSA: seq: snd_seq_prioq_cell_in() called with NULL prioq\n");
- return NULL;
- }
- return f->head;
-}
-
-
static inline int prioq_match(struct snd_seq_event_cell *cell,
int client, int timestamp)
{
--- a/sound/core/seq/seq_prioq.h
+++ b/sound/core/seq/seq_prioq.h
@@ -44,14 +44,12 @@ void snd_seq_prioq_delete(struct snd_seq
int snd_seq_prioq_cell_in(struct snd_seq_prioq *f, struct snd_seq_event_cell *cell);

/* dequeue cell from prioq */
-struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f);
+struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f,
+ void *current_time);

/* return number of events available in prioq */
int snd_seq_prioq_avail(struct snd_seq_prioq *f);

-/* peek at cell at the head of the prioq */
-struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq *f);
-
/* client left queue */
void snd_seq_prioq_leave(struct snd_seq_prioq *f, int client, int timestamp);

--- a/sound/core/seq/seq_queue.c
+++ b/sound/core/seq/seq_queue.c
@@ -277,30 +277,20 @@ void snd_seq_check_queue(struct snd_seq_

__again:
/* Process tick queue... */
- while ((cell = snd_seq_prioq_cell_peek(q->tickq)) != NULL) {
- if (snd_seq_compare_tick_time(&q->timer->tick.cur_tick,
- &cell->event.time.tick)) {
- cell = snd_seq_prioq_cell_out(q->tickq);
- if (cell)
- snd_seq_dispatch_event(cell, atomic, hop);
- } else {
- /* event remains in the queue */
+ for (;;) {
+ cell = snd_seq_prioq_cell_out(q->tickq,
+ &q->timer->tick.cur_tick);
+ if (!cell)
break;
- }
+ snd_seq_dispatch_event(cell, atomic, hop);
}

-
/* Process time queue... */
- while ((cell = snd_seq_prioq_cell_peek(q->timeq)) != NULL) {
- if (snd_seq_compare_real_time(&q->timer->cur_time,
- &cell->event.time.time)) {
- cell = snd_seq_prioq_cell_out(q->timeq);
- if (cell)
- snd_seq_dispatch_event(cell, atomic, hop);
- } else {
- /* event remains in the queue */
+ for (;;) {
+ cell = snd_seq_prioq_cell_out(q->timeq, &q->timer->cur_time);
+ if (!cell)
break;
- }
+ snd_seq_dispatch_event(cell, atomic, hop);
}

/* free lock */



2018-03-20 00:44:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 116/134] ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()

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

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

From: Takashi Iwai <[email protected]>

commit 01c0b4265cc16bc1f43f475c5944c55c10d5768f upstream.

snd_pcm_oss_get_formats() has an obvious use-after-free around
snd_mask_test() calls, as spotted by syzbot. The passed format_mask
argument is a pointer to the hw_params object that is freed before the
loop. What a surprise that it has been present since the original
code of decades ago...

Reported-by: [email protected]
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/oss/pcm_oss.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1814,10 +1814,9 @@ static int snd_pcm_oss_get_formats(struc
return -ENOMEM;
_snd_pcm_hw_params_any(params);
err = snd_pcm_hw_refine(substream, params);
- format_mask = *hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
- kfree(params);
if (err < 0)
- return err;
+ goto error;
+ format_mask = *hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
for (fmt = 0; fmt < 32; ++fmt) {
if (snd_mask_test(&format_mask, fmt)) {
int f = snd_pcm_oss_format_to(fmt);
@@ -1825,7 +1824,10 @@ static int snd_pcm_oss_get_formats(struc
formats |= f;
}
}
- return formats;
+
+ error:
+ kfree(params);
+ return err < 0 ? err : formats;
}

static int snd_pcm_oss_set_format(struct snd_pcm_oss_file *pcm_oss_file, int format)



2018-03-20 01:42:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 055/134] scsi: ses: dont get power status of SES device slot on probe

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

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

From: Mauricio Faria de Oliveira <[email protected]>


[ Upstream commit 75106523f39751390b5789b36ee1d213b3af1945 ]

The commit 08024885a2a3 ("ses: Add power_status to SES device slot")
introduced the 'power_status' attribute to enclosure components and
the associated callbacks.

There are 2 callbacks available to get the power status of a device:
1) ses_get_power_status() for 'struct enclosure_component_callbacks'
2) get_component_power_status() for the sysfs device attribute
(these are available for kernel-space and user-space, respectively.)

However, despite both methods being available to get power status
on demand, that commit also introduced a call to get power status
in ses_enclosure_data_process().

This dramatically increased the total probe time for SCSI devices
on larger configurations, because ses_enclosure_data_process() is
called several times during the SCSI devices probe and loops over
the component devices (but that is another problem, another patch).

That results in a tremendous continuous hammering of SCSI Receive
Diagnostics commands to the enclosure-services device, which does
delay the total probe time for the SCSI devices __significantly__:

Originally, ~34 minutes on a system attached to ~170 disks:

[ 9214.490703] mpt3sas version 13.100.00.00 loaded
...
[11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0),
ordered(0), scsi_level(6), cmd_que(1)

With this patch, it decreased to ~2.5 minutes -- a 13.6x faster

[ 1002.992533] mpt3sas version 13.100.00.00 loaded
...
[ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0),
ordered(0), scsi_level(6), cmd_que(1)

Back to the commit discussion.. on the ses_get_power_status() call
introduced in ses_enclosure_data_process(): impact of removing it.

That may possibly be in place to initialize the power status value
on device probe. However, those 2 functions available to retrieve
that value _do_ automatically refresh/update it. So the potential
benefit would be a direct access of the 'power_status' field which
does not use the callbacks...

But the only reader of 'struct enclosure_component::power_status'
is the get_component_power_status() callback for sysfs attribute,
and it _does_ check for and call the .get_power_status callback,
(which indeed is defined and implemented by that commit), so the
power status value is, again, automatically updated.

So, the remaining potential for a direct/non-callback access to
the power_status attribute would be out-of-tree modules -- well,
for those, if they are for whatever reason interested in values
that are set during device probe and not up-to-date by the time
they need it.. well, that would be curious.

Well, to handle that more properly, set the initial power state
value to '-1' (i.e., uninitialized) instead of '1' (power 'on'),
and check for it in that callback which may do an direct access
to the field value _if_ a callback function is not defined.

Signed-off-by: Mauricio Faria de Oliveira <[email protected]>
Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot")
Reviewed-by: Dan Williams <[email protected]>
Reviewed-by: Song Liu <[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/misc/enclosure.c | 7 ++++++-
drivers/scsi/ses.c | 1 -
2 files changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -148,7 +148,7 @@ enclosure_register(struct device *dev, c
for (i = 0; i < components; i++) {
edev->component[i].number = -1;
edev->component[i].slot = -1;
- edev->component[i].power_status = 1;
+ edev->component[i].power_status = -1;
}

mutex_lock(&container_list_lock);
@@ -600,6 +600,11 @@ static ssize_t get_component_power_statu

if (edev->cb->get_power_status)
edev->cb->get_power_status(edev, ecomp);
+
+ /* If still uninitialized, the callback failed or does not exist. */
+ if (ecomp->power_status == -1)
+ return (edev->cb->get_power_status) ? -EIO : -ENOTTY;
+
return snprintf(buf, 40, "%s\n", ecomp->power_status ? "on" : "off");
}

--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -546,7 +546,6 @@ static void ses_enclosure_data_process(s
ecomp = &edev->component[components++];

if (!IS_ERR(ecomp)) {
- ses_get_power_status(edev, ecomp);
if (addl_desc_ptr)
ses_process_descriptor(
ecomp,



2018-03-20 01:42:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

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

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

From: Roger Quadros <[email protected]>


[ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]

It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
is in use then there are random chances that the usb_otg_ss module
will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.

Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
fixes this issue.

We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
issue or not so don't add this flag for those instances.

Cc: Tero Kristo <[email protected]>
Signed-off-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/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class = &dra7xx_usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk = "dpll_core_h13x2_ck",
+ .flags = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
@@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class = &dra7xx_usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk = "dpll_core_h13x2_ck",
+ .flags = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,



2018-03-20 01:42:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 099/134] scsi: dh: add new rdac devices

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

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

From: Xose Vazquez Perez <[email protected]>


[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]

Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.

Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220,
D240 and D280.

Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.

These changes were done in multipath-tools time ago.

Cc: NetApp RDAC team <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Cc: Christophe Varoqui <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Cc: James E.J. Bottomley <[email protected]>
Cc: SCSI ML <[email protected]>
Cc: device-mapper development <[email protected]>
Signed-off-by: Xose Vazquez Perez <[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/scsi_dh.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d
{"IBM", "1815", "rdac", },
{"IBM", "1818", "rdac", },
{"IBM", "3526", "rdac", },
+ {"IBM", "3542", "rdac", },
+ {"IBM", "3552", "rdac", },
{"SGI", "TP9", "rdac", },
{"SGI", "IS", "rdac", },
- {"STK", "OPENstorage D280", "rdac", },
+ {"STK", "OPENstorage", "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
+ {"STK", "BladeCtlr", "rdac", },
{"SUN", "CSM", "rdac", },
{"SUN", "LCSM100", "rdac", },
{"SUN", "STK6580_6780", "rdac", },



2018-03-20 01:42:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 127/134] scsi: sg: fix static checker warning in sg_is_valid_dxfer

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

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

From: Johannes Thumshirn <[email protected]>

commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream.

dxfer_len is an unsigned int and we always assign a value > 0 to it, so
it doesn't make any sense to check if it is < 0. We can't really check
dxferp as well as we have both NULL and not NULL cases in the possible
call paths.

So just return true for SG_DXFER_FROM_DEV transfer in
sg_is_valid_dxfer().

Signed-off-by: Johannes Thumshirn <[email protected]>
Reported-by: Colin Ian King <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Cc: Douglas Gilbert <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/sg.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -770,8 +770,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
return false;
return true;
case SG_DXFER_FROM_DEV:
- if (hp->dxfer_len < 0)
- return false;
+ /*
+ * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
+ * can either be NULL or != NULL so there's no point in checking
+ * it either. So just return true.
+ */
return true;
case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:



2018-03-20 01:43:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 128/134] scsi: sg: only check for dxfer_len greater than 256M

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

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

From: Johannes Thumshirn <[email protected]>

commit f930c7043663188429cd9b254e9d761edfc101ce upstream.

Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
only way we can check for bad requests is by checking if the length
exceeds 256M.

Signed-off-by: Johannes Thumshirn <[email protected]>
Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request)
Reported-by: Jason L Tibbitts III <[email protected]>
Tested-by: Jason L Tibbitts III <[email protected]>
Suggested-by: Doug Gilbert <[email protected]>
Cc: Doug Gilbert <[email protected]>
Cc: <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/sg.c | 31 +------------------------------
1 file changed, 1 insertion(+), 30 deletions(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -762,35 +762,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi
return count;
}

-static bool sg_is_valid_dxfer(sg_io_hdr_t *hp)
-{
- switch (hp->dxfer_direction) {
- case SG_DXFER_NONE:
- if (hp->dxferp || hp->dxfer_len > 0)
- return false;
- return true;
- case SG_DXFER_FROM_DEV:
- /*
- * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp
- * can either be NULL or != NULL so there's no point in checking
- * it either. So just return true.
- */
- return true;
- case SG_DXFER_TO_DEV:
- case SG_DXFER_TO_FROM_DEV:
- if (!hp->dxferp || hp->dxfer_len == 0)
- return false;
- return true;
- case SG_DXFER_UNKNOWN:
- if ((!hp->dxferp && hp->dxfer_len) ||
- (hp->dxferp && hp->dxfer_len == 0))
- return false;
- return true;
- default:
- return false;
- }
-}
-
static int
sg_common_write(Sg_fd * sfp, Sg_request * srp,
unsigned char *cmnd, int timeout, int blocking)
@@ -811,7 +782,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n",
(int) cmnd[0], (int) hp->cmd_len));

- if (!sg_is_valid_dxfer(hp))
+ if (hp->dxfer_len >= SZ_256M)
return -EINVAL;

k = sg_start_req(srp, cmnd);



2018-03-20 01:43:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 047/134] ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks

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

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

From: Geert Uytterhoeven <[email protected]>


[ Upstream commit d13d4e063d4a08eb1686e890e9183dde709871bf ]

The SSI-ALL gate clock is located in between the P clock and the
individual SSI[0-9] clocks, hence the former should be listed as their
parent.

Fixes: bcde372254386872 ("ARM: shmobile: r8a7790: add MSTP10 support on DTSI")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/r8a7790.dtsi | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1360,8 +1360,11 @@
compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
clocks = <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
- <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
+ <&mstp10_clks R8A7790_CLK_SSI_ALL>, <&mstp10_clks R8A7790_CLK_SSI_ALL>,
<&p_clk>,
<&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>,
<&mstp10_clks R8A7790_CLK_SCU_ALL>, <&mstp10_clks R8A7790_CLK_SCU_ALL>,



2018-03-20 01:43:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 112/134] selftests/x86: Add tests for the STR and SLDT instructions

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

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

From: Ricardo Neri <[email protected]>

commit a9e017d5619eb371460c8e516f4684def62bef3a upstream.

The STR and SLDT instructions are not valid when running on virtual-8086
mode and generate an invalid operand exception. These two instructions are
protected by the Intel User-Mode Instruction Prevention (UMIP) security
feature. In protected mode, if UMIP is enabled, these instructions generate
a general protection fault if called from CPL > 0. Linux traps the general
protection fault and emulates the instructions sgdt, sidt and smsw; but not
str and sldt.

These tests are added to verify that the emulation code does not emulate
these two instructions but the expected invalid operand exception is
seen.

Tests fallback to exit with INT3 in case emulation does happen.

Signed-off-by: Ricardo Neri <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Chen Yucong <[email protected]>
Cc: Chris Metcalf <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: Fenghua Yu <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Huang Rui <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Masami Hiramatsu <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Paul Gortmaker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ravi V. Shankar <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/1509935277-22138-13-git-send-email-ricardo.neri-calderon@linux.intel.com
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/testing/selftests/x86/entry_from_vm86.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)

--- a/tools/testing/selftests/x86/entry_from_vm86.c
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -111,6 +111,11 @@ asm (
"smsw %ax\n\t"
"mov %ax, (2080)\n\t"
"int3\n\t"
+ "vmcode_umip_str:\n\t"
+ "str %eax\n\t"
+ "vmcode_umip_sldt:\n\t"
+ "sldt %eax\n\t"
+ "int3\n\t"
".size vmcode, . - vmcode\n\t"
"end_vmcode:\n\t"
".code32\n\t"
@@ -119,7 +124,8 @@ asm (

extern unsigned char vmcode[], end_vmcode[];
extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[],
- vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[];
+ vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[],
+ vmcode_umip_str[], vmcode_umip_sldt[];

/* Returns false if the test was skipped. */
static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -226,6 +232,16 @@ void do_umip_tests(struct vm86plus_struc
printf("[FAIL]\tAll the results of SIDT should be the same.\n");
else
printf("[PASS]\tAll the results from SIDT are identical.\n");
+
+ sethandler(SIGILL, sighandler, 0);
+ do_test(vm86, vmcode_umip_str - vmcode, VM86_SIGNAL, 0,
+ "STR instruction");
+ clearhandler(SIGILL);
+
+ sethandler(SIGILL, sighandler, 0);
+ do_test(vm86, vmcode_umip_sldt - vmcode, VM86_SIGNAL, 0,
+ "SLDT instruction");
+ clearhandler(SIGILL);
}

int main(void)



2018-03-20 01:43:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 052/134] reiserfs: Make cancel_old_flush() reliable

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

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

From: Jan Kara <[email protected]>


[ Upstream commit 71b0576bdb862e964a82c73327cdd1a249c53e67 ]

Currently canceling of delayed work that flushes old data using
cancel_old_flush() does not prevent work from being requeued. Thus
in theory new work can be queued after cancel_old_flush() from
reiserfs_freeze() has run. This will become larger problem once
flush_old_commits() can requeue the work itself.

Fix the problem by recording in sbi->work_queue that flushing work is
canceled and should not be requeued.

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/reiserfs/journal.c | 2 +-
fs/reiserfs/reiserfs.h | 1 +
fs/reiserfs/super.c | 21 +++++++++++++++------
3 files changed, 17 insertions(+), 7 deletions(-)

--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -1961,7 +1961,7 @@ static int do_journal_release(struct rei
* will be requeued because superblock is being shutdown and doesn't
* have MS_ACTIVE set.
*/
- cancel_delayed_work_sync(&REISERFS_SB(sb)->old_work);
+ reiserfs_cancel_old_flush(sb);
/* wait for all commits to finish */
cancel_delayed_work_sync(&SB_JOURNAL(sb)->j_work);

--- a/fs/reiserfs/reiserfs.h
+++ b/fs/reiserfs/reiserfs.h
@@ -2948,6 +2948,7 @@ int reiserfs_allocate_list_bitmaps(struc
struct reiserfs_list_bitmap *, unsigned int);

void reiserfs_schedule_old_flush(struct super_block *s);
+void reiserfs_cancel_old_flush(struct super_block *s);
void add_save_link(struct reiserfs_transaction_handle *th,
struct inode *inode, int truncate);
int remove_save_link(struct inode *inode, int truncate);
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -90,7 +90,9 @@ static void flush_old_commits(struct wor
s = sbi->s_journal->j_work_sb;

spin_lock(&sbi->old_work_lock);
- sbi->work_queued = 0;
+ /* Avoid clobbering the cancel state... */
+ if (sbi->work_queued == 1)
+ sbi->work_queued = 0;
spin_unlock(&sbi->old_work_lock);

reiserfs_sync_fs(s, 1);
@@ -117,21 +119,22 @@ void reiserfs_schedule_old_flush(struct
spin_unlock(&sbi->old_work_lock);
}

-static void cancel_old_flush(struct super_block *s)
+void reiserfs_cancel_old_flush(struct super_block *s)
{
struct reiserfs_sb_info *sbi = REISERFS_SB(s);

- cancel_delayed_work_sync(&REISERFS_SB(s)->old_work);
spin_lock(&sbi->old_work_lock);
- sbi->work_queued = 0;
+ /* Make sure no new flushes will be queued */
+ sbi->work_queued = 2;
spin_unlock(&sbi->old_work_lock);
+ cancel_delayed_work_sync(&REISERFS_SB(s)->old_work);
}

static int reiserfs_freeze(struct super_block *s)
{
struct reiserfs_transaction_handle th;

- cancel_old_flush(s);
+ reiserfs_cancel_old_flush(s);

reiserfs_write_lock(s);
if (!(s->s_flags & MS_RDONLY)) {
@@ -152,7 +155,13 @@ static int reiserfs_freeze(struct super_

static int reiserfs_unfreeze(struct super_block *s)
{
+ struct reiserfs_sb_info *sbi = REISERFS_SB(s);
+
reiserfs_allow_writes(s);
+ spin_lock(&sbi->old_work_lock);
+ /* Allow old_work to run again */
+ sbi->work_queued = 0;
+ spin_unlock(&sbi->old_work_lock);
return 0;
}

@@ -2187,7 +2196,7 @@ error_unlocked:
if (sbi->commit_wq)
destroy_workqueue(sbi->commit_wq);

- cancel_delayed_work_sync(&REISERFS_SB(s)->old_work);
+ reiserfs_cancel_old_flush(s);

reiserfs_free_bitmap_cache(s);
if (SB_BUFFER_WITH_SB(s))



2018-03-20 01:43:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 061/134] coresight: Fixes coresight DT parse to get correct output port ID.

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

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

From: Mike Leach <[email protected]>


[ Upstream commit eeedc5421dd3b51de73e6106405c5c77f920f281 ]

Corrected to get the port numbering to allow programmable replicator driver
to operate correctly.

By convention, CoreSight devices number ports, not endpoints in
the .dts files:-

port {
reg<N>
endpoint {
}
}

Existing code read endpoint number - always 0x0, rather than the correct
port number.

Signed-off-by: Mike Leach <[email protected]>
Signed-off-by: Mathieu Poirier <[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/hwtracing/coresight/of_coresight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -150,7 +150,7 @@ struct coresight_platform_data *of_get_c
continue;

/* The local out port number */
- pdata->outports[i] = endpoint.id;
+ pdata->outports[i] = endpoint.port;

/*
* Get a handle on the remote port and parent



2018-03-20 01:43:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 100/134] media: cpia2: Fix a couple off by one bugs

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

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

From: Dan Carpenter <[email protected]>


[ Upstream commit d5ac225c7d64c9c3ef821239edc035634e594ec9 ]

The cam->buffers[] array has cam->num_frames elements so the > needs to
be changed to >= to avoid going beyond the end of the array. The
->buffers[] array is allocated in cpia2_allocate_buffers() if you want
to confirm.

Fixes: ab33d5071de7 ("V4L/DVB (3376): Add cpia2 camera support")

Signed-off-by: Dan Carpenter <[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/usb/cpia2/cpia2_v4l.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -812,7 +812,7 @@ static int cpia2_querybuf(struct file *f
struct camera_data *cam = video_drvdata(file);

if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
- buf->index > cam->num_frames)
+ buf->index >= cam->num_frames)
return -EINVAL;

buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
@@ -863,7 +863,7 @@ static int cpia2_qbuf(struct file *file,

if(buf->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
buf->memory != V4L2_MEMORY_MMAP ||
- buf->index > cam->num_frames)
+ buf->index >= cam->num_frames)
return -EINVAL;

DBG("QBUF #%d\n", buf->index);



2018-03-20 01:43:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 110/134] selftests/x86/entry_from_vm86: Exit with 1 if we fail

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

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

From: Andy Lutomirski <[email protected]>

commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream.

Fix a logic error that caused the test to exit with 0 even if test
cases failed.

Signed-off-by: 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: Stas Sergeev <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.1521003603.git.luto@kernel.org
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
tools/testing/selftests/x86/entry_from_vm86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/testing/selftests/x86/entry_from_vm86.c
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -231,7 +231,7 @@ int main(void)
clearhandler(SIGSEGV);

/* Make sure nothing explodes if we fork. */
- if (fork() > 0)
+ if (fork() == 0)
return 0;

return (nerrs == 0 ? 0 : 1);



2018-03-20 01:43:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 074/134] scsi: sg: close race condition in sg_remove_sfp_usercontext()

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

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

From: Hannes Reinecke <[email protected]>


[ Upstream commit 97d27b0dd015e980ade63fda111fd1353276e28b ]

sg_remove_sfp_usercontext() is clearing any sg requests, but needs to
take 'rq_list_lock' when modifying the list.

Reported-by: Christoph Hellwig <[email protected]>
Signed-off-by: Hannes Reinecke <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Tested-by: Johannes Thumshirn <[email protected]>
Reviewed-by: Christoph Hellwig <[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/sg.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -535,6 +535,7 @@ sg_read(struct file *filp, char __user *
} else
count = (old_hdr->result == 0) ? 0 : -EIO;
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
retval = count;
free_old_hdr:
kfree(old_hdr);
@@ -575,6 +576,7 @@ sg_new_read(Sg_fd * sfp, char __user *bu
}
err_out:
err2 = sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return err ? : err2 ? : count;
}

@@ -811,6 +813,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
SCSI_LOG_TIMEOUT(1, sg_printk(KERN_INFO, sfp->parentdp,
"sg_common_write: start_req err=%d\n", k));
sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return k; /* probably out of space --> ENOMEM */
}
if (atomic_read(&sdp->detaching)) {
@@ -823,6 +826,7 @@ sg_common_write(Sg_fd * sfp, Sg_request
}

sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
return -ENODEV;
}

@@ -1312,6 +1316,7 @@ sg_rq_end_io_usercontext(struct work_str
struct sg_fd *sfp = srp->parentfp;

sg_finish_rem_req(srp);
+ sg_remove_request(sfp, srp);
kref_put(&sfp->f_ref, sg_remove_sfp);
}

@@ -1856,8 +1861,6 @@ sg_finish_rem_req(Sg_request *srp)
else
sg_remove_scat(sfp, req_schp);

- sg_remove_request(sfp, srp);
-
return ret;
}

@@ -2204,12 +2207,17 @@ sg_remove_sfp_usercontext(struct work_st
struct sg_fd *sfp = container_of(work, struct sg_fd, ew.work);
struct sg_device *sdp = sfp->parentdp;
Sg_request *srp;
+ unsigned long iflags;

/* Cleanup any responses which were never read(). */
+ write_lock_irqsave(&sfp->rq_list_lock, iflags);
while (!list_empty(&sfp->rq_list)) {
srp = list_first_entry(&sfp->rq_list, Sg_request, entry);
sg_finish_rem_req(srp);
+ list_del(&srp->entry);
+ srp->parentfp = NULL;
}
+ write_unlock_irqrestore(&sfp->rq_list_lock, iflags);

if (sfp->reserve.bufflen > 0) {
SCSI_LOG_TIMEOUT(6, sg_printk(KERN_INFO, sdp,



2018-03-20 01:43:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 119/134] ALSA: seq: Clear client entry before deleting else at closing

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

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

From: Takashi Iwai <[email protected]>

commit a2ff19f7b70118ced291a28d5313469914de451b upstream.

When releasing a client, we need to clear the clienttab[] entry at
first, then call snd_seq_queue_client_leave(). Otherwise, the
in-flight cell in the queue might be picked up by the timer interrupt
via snd_seq_check_queue() before calling snd_seq_queue_client_leave(),
and it's delivered to another queue while the client is clearing
queues. This may eventually result in an uncleared cell remaining in
a queue, and the later snd_seq_pool_delete() may need to wait for a
long time until the event gets really processed.

By moving the clienttab[] clearance at the beginning of release, any
event delivery of a cell belonging to this client will fail at a later
point, since snd_seq_client_ptr() returns NULL. Thus the cell that
was picked up by the timer interrupt will be returned immediately
without further delivery, and the long stall of snd_seq_delete_pool()
can be avoided, too.

Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/seq/seq_clientmgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -270,12 +270,12 @@ static int seq_free_client1(struct snd_s

if (!client)
return 0;
- snd_seq_delete_all_ports(client);
- snd_seq_queue_client_leave(client->number);
spin_lock_irqsave(&clients_lock, flags);
clienttablock[client->number] = 1;
clienttab[client->number] = NULL;
spin_unlock_irqrestore(&clients_lock, flags);
+ snd_seq_delete_all_ports(client);
+ snd_seq_queue_client_leave(client->number);
snd_use_lock_sync(&client->use_lock);
snd_seq_queue_client_termination(client->number);
if (client->pool)



2018-03-20 01:49:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 115/134] x86/mm: Fix vmalloc_fault to use pXd_large

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

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

From: Toshi Kani <[email protected]>

commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream.

Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS
is not set since the function inadvertently uses pXn_huge(), which always
return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS.

Fix vmalloc_fault() to call pXd_large() instead.

Fixes: f4eafd8bcd52 ("x86/mm: Fix vmalloc_fault() to handle large pages properly")
Reported-by: Gratian Crisan <[email protected]>
Signed-off-by: Toshi Kani <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Borislav Petkov <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/mm/fault.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -287,7 +287,7 @@ static noinline int vmalloc_fault(unsign
if (!pmd_k)
return -1;

- if (pmd_huge(*pmd_k))
+ if (pmd_large(*pmd_k))
return 0;

pte_k = pte_offset_kernel(pmd_k, address);
@@ -407,7 +407,7 @@ static noinline int vmalloc_fault(unsign
if (pud_none(*pud) || pud_pfn(*pud) != pud_pfn(*pud_ref))
BUG();

- if (pud_huge(*pud))
+ if (pud_large(*pud))
return 0;

pmd = pmd_offset(pud, address);
@@ -418,7 +418,7 @@ static noinline int vmalloc_fault(unsign
if (pmd_none(*pmd) || pmd_pfn(*pmd) != pmd_pfn(*pmd_ref))
BUG();

- if (pmd_huge(*pmd))
+ if (pmd_large(*pmd))
return 0;

pte_ref = pte_offset_kernel(pmd_ref, address);



2018-03-20 01:49:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 125/134] irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis

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

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

From: Ard Biesheuvel <[email protected]>

commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.

When struct its_device instances are created, the nr_ites member
will be set to a power of 2 that equals or exceeds the requested
number of MSIs passed to the msi_prepare() callback. At the same
time, the LPI map is allocated to be some multiple of 32 in size,
where the allocated size may be less than the requested size
depending on whether a contiguous range of sufficient size is
available in the global LPI bitmap.

This may result in the situation where the nr_ites < nr_lpis, and
since nr_ites is what we program into the hardware when we map the
device, the additional LPIs will be non-functional.

For bog standard hardware, this does not really matter. However,
in cases where ITS device IDs are shared between different PCIe
devices, we may end up allocating these additional LPIs without
taking into account that they don't actually work.

So let's make nr_ites at least 32. This ensures that all allocated
LPIs are 'live', and that its_alloc_device_irq() will fail when
attempts are made to allocate MSIs beyond what was allocated in
the first place.

Signed-off-by: Ard Biesheuvel <[email protected]>
[maz: updated comment]
Signed-off-by: Marc Zyngier <[email protected]>
[ardb: trivial tweak of unrelated context]
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/irqchip/irq-gic-v3-its.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)

--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -663,7 +663,7 @@ static struct irq_chip its_irq_chip = {
* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
*/
#define IRQS_PER_CHUNK_SHIFT 5
-#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT)
+#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)

static unsigned long *lpi_bitmap;
static u32 lpi_chunks;
@@ -1168,11 +1168,10 @@ static struct its_device *its_create_dev

dev = kzalloc(sizeof(*dev), GFP_KERNEL);
/*
- * At least one bit of EventID is being used, hence a minimum
- * of two entries. No, the architecture doesn't let you
- * express an ITT with a single entry.
+ * We allocate at least one chunk worth of LPIs bet device,
+ * and thus that many ITEs. The device may require less though.
*/
- nr_ites = max(2UL, roundup_pow_of_two(nvecs));
+ nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
sz = nr_ites * its->ite_size;
sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
itt = kzalloc(sz, GFP_KERNEL);



2018-03-20 01:49:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 076/134] kprobes/x86: Set kprobes pages read-only

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

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

From: Masami Hiramatsu <[email protected]>


[ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]

Set the pages which is used for kprobes' singlestep buffer
and optprobe's trampoline instruction buffer to readonly.
This can prevent unexpected (or unintended) instruction
modification.

This also passes rodata_test as below.

Without this patch, rodata_test shows a warning:

WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20
x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000

With this fix, no W+X pages are found:

x86/mm: Checked W+X mappings: passed, no W+X pages found.
rodata_test: all tests were successful

Reported-by: Andrey Ryabinin <[email protected]>
Signed-off-by: Masami Hiramatsu <[email protected]>
Cc: Ananth N Mavinakayanahalli <[email protected]>
Cc: Anil S Keshavamurthy <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: David S . Miller <[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]>
Cc: Ye Xiaolong <[email protected]>
Link: http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devbox
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/kprobes/core.c | 4 ++++
arch/x86/kernel/kprobes/opt.c | 3 +++
2 files changed, 7 insertions(+)

--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -406,6 +406,8 @@ static int arch_copy_kprobe(struct kprob
{
int ret;

+ set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+
/* Copy an instruction with recovering if other optprobe modifies it.*/
ret = __copy_instruction(p->ainsn.insn, p->addr);
if (!ret)
@@ -420,6 +422,8 @@ static int arch_copy_kprobe(struct kprob
else
p->ainsn.boostable = -1;

+ set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
+
/* Check whether the instruction modifies Interrupt Flag or not */
p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);

--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -370,6 +370,7 @@ int arch_prepare_optimized_kprobe(struct
}

buf = (u8 *)op->optinsn.insn;
+ set_memory_rw((unsigned long)buf & PAGE_MASK, 1);

/* Copy instructions into the out-of-line buffer */
ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
@@ -392,6 +393,8 @@ int arch_prepare_optimized_kprobe(struct
synthesize_reljump(buf + TMPL_END_IDX + op->optinsn.size,
(u8 *)op->kp.addr + op->optinsn.size);

+ set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
+
flush_icache_range((unsigned long) buf,
(unsigned long) buf + TMPL_END_IDX +
op->optinsn.size + RELATIVEJUMP_SIZE);



2018-03-20 01:49:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 104/134] mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED

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

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

From: Adiel Aloni <[email protected]>


[ Upstream commit e16ea4bb516bc21ea2202f2107718b29218bea59 ]

Enforce using PS_MANUAL_POLL in ps hwsim debugfs to trigger a poll,
only if PS_ENABLED was set before.
This is required due to commit c9491367b759 ("mac80211: always update the
PM state of a peer on MGMT / DATA frames") that enforces the ap to
check only mgmt/data frames ps bit, and then update station's power save
accordingly.
When sending only ps-poll (control frame) the ap will not be aware that
the station entered power save.
Setting ps enable before triggering ps_poll, will send NDP with PM bit
enabled first.

Signed-off-by: Adiel Aloni <[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]>
---
drivers/net/wireless/mac80211_hwsim.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -699,16 +699,21 @@ static int hwsim_fops_ps_write(void *dat
val != PS_MANUAL_POLL)
return -EINVAL;

- old_ps = data->ps;
- data->ps = val;
-
- local_bh_disable();
if (val == PS_MANUAL_POLL) {
+ if (data->ps != PS_ENABLED)
+ return -EINVAL;
+ local_bh_disable();
ieee80211_iterate_active_interfaces_atomic(
data->hw, IEEE80211_IFACE_ITER_NORMAL,
hwsim_send_ps_poll, data);
- data->ps_poll_pending = true;
- } else if (old_ps == PS_DISABLED && val != PS_DISABLED) {
+ local_bh_enable();
+ return 0;
+ }
+ old_ps = data->ps;
+ data->ps = val;
+
+ local_bh_disable();
+ if (old_ps == PS_DISABLED && val != PS_DISABLED) {
ieee80211_iterate_active_interfaces_atomic(
data->hw, IEEE80211_IFACE_ITER_NORMAL,
hwsim_send_nullfunc_ps, data);



2018-03-20 01:49:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 117/134] ALSA: hda - Revert power_save option default value

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

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

From: Takashi Iwai <[email protected]>

commit 40088dc4e1ead7df31728c73f5b51d71da18831d upstream.

With the commit 1ba8f9d30817 ("ALSA: hda: Add a power_save
blacklist"), we changed the default value of power_save option to -1
for processing the power-save blacklist.
Unfortunately, this seems breaking user-space applications that
actually read the power_save parameter value via sysfs and judge /
adjust the power-saving status. They see the value -1 as if the
power-save is turned off, although the actual value is taken from
CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive.

So, overall, passing -1 there was no good idea. Let's partially
revert it -- at least for power_save option default value is restored
again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT. Meanwhile, in this patch,
we keep the blacklist behavior and make is adjustable via the new
option, pm_blacklist.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
Fixes: 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
Acked-by: Hans de Goede <[email protected]>
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/hda_intel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -179,11 +179,15 @@ static const struct kernel_param_ops par
};
#define param_check_xint param_check_int

-static int power_save = -1;
+static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
module_param(power_save, xint, 0644);
MODULE_PARM_DESC(power_save, "Automatic power-saving timeout "
"(in second, 0 = disable).");

+static bool pm_blacklist = true;
+module_param(pm_blacklist, bool, 0644);
+MODULE_PARM_DESC(pm_blacklist, "Enable power-management blacklist");
+
/* reset the HD-audio controller in power save mode.
* this may give more power-saving, but will take longer time to
* wake up.
@@ -2164,10 +2168,9 @@ static int azx_probe_continue(struct azx

val = power_save;
#ifdef CONFIG_PM
- if (val == -1) {
+ if (pm_blacklist) {
const struct snd_pci_quirk *q;

- val = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
if (q && val) {
dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n",



2018-03-20 01:50:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 096/134] spi: sun6i: disable/unprepare clocks on remove

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

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

From: Tobias Jordan <[email protected]>


[ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ]

sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable
clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure
that sun6i_spi_runtime_suspend() is called if needed.

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

Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Tobias Jordan <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spi-sun6i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -457,7 +457,7 @@ err_free_master:

static int sun6i_spi_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_force_suspend(&pdev->dev);

return 0;
}



2018-03-20 01:50:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 132/134] USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()

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

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

From: Wei Yongjun <[email protected]>

commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream.

Add the missing platform_device_put() before return from bdc_pci_probe()
in the platform_device_add_resources() error handling case.

Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC")
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev
if (ret) {
dev_err(&pci->dev,
"couldn't add resources to bdc device\n");
+ platform_device_put(bdc);
return ret;
}




2018-03-20 01:50:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 087/134] mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()

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

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

From: Miquel Raynal <[email protected]>


[ Upstream commit df467899da0b71465760b4e35127bce837244eee ]

Some drivers (like nand_hynix.c) call ->cmdfunc() with NAND_CMD_NONE
and a column address and expect the controller to only send address
cycles. Right now, the default ->cmdfunc() implementations provided by
the core do not filter out the command cycle in this case and forwards
the request to the controller driver through the ->cmd_ctrl() method.
The thing is, NAND controller drivers can get this wrong and send a
command cycle with a NAND_CMD_NONE opcode and since NAND_CMD_NONE is
-1, and the command field is usually casted to an u8, we end up sending
the 0xFF command which is actually a RESET operation.

Add conditions in nand_command[_lp]() functions to sending the initial
command cycle when command == NAND_CMD_NONE.

Signed-off-by: Miquel Raynal <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/nand/nand_base.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -626,7 +626,8 @@ static void nand_command(struct mtd_info
chip->cmd_ctrl(mtd, readcmd, ctrl);
ctrl &= ~NAND_CTRL_CHANGE;
}
- chip->cmd_ctrl(mtd, command, ctrl);
+ if (command != NAND_CMD_NONE)
+ chip->cmd_ctrl(mtd, command, ctrl);

/* Address cycle, when necessary */
ctrl = NAND_CTRL_ALE | NAND_CTRL_CHANGE;
@@ -655,6 +656,7 @@ static void nand_command(struct mtd_info
*/
switch (command) {

+ case NAND_CMD_NONE:
case NAND_CMD_PAGEPROG:
case NAND_CMD_ERASE1:
case NAND_CMD_ERASE2:
@@ -717,7 +719,9 @@ static void nand_command_lp(struct mtd_i
}

/* Command latch cycle */
- chip->cmd_ctrl(mtd, command, NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
+ if (command != NAND_CMD_NONE)
+ chip->cmd_ctrl(mtd, command,
+ NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);

if (column != -1 || page_addr != -1) {
int ctrl = NAND_CTRL_CHANGE | NAND_NCE | NAND_ALE;
@@ -750,6 +754,7 @@ static void nand_command_lp(struct mtd_i
*/
switch (command) {

+ case NAND_CMD_NONE:
case NAND_CMD_CACHEDPROG:
case NAND_CMD_PAGEPROG:
case NAND_CMD_ERASE1:



2018-03-20 01:50:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 129/134] ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

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

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

From: Adam Ford <[email protected]>

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.

The pinmuxing was missing for I2C1 which was causing intermittent issues
with the PMIC which is connected to I2C1. The bootloader did not quite
configure the I2C1 either, so when running at 2.6MHz, it was generating
errors at time.

This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz

Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo
DM3730 devkit")

Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -90,6 +90,8 @@
};

&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
clock-frequency = <2600000>;

twl: twl@48 {
@@ -137,6 +139,12 @@
OMAP3_CORE1_IOPAD(0x218e, PIN_OUTPUT | MUX_MODE4) /* mcbsp1_fsr.gpio_157 */
>;
};
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
+ OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
+ >;
+ };
};

&omap3_pmx_core2 {



2018-03-20 01:50:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 126/134] scsi: sg: fix SG_DXFER_FROM_DEV transfers

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

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

From: Johannes Thumshirn <[email protected]>

commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream.

SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set
it to NULL for the old sg_io read/write interface, but must have a
length bigger than 0. This fixes a regression introduced by commit
28676d869bbb ("scsi: sg: check for valid direction before starting the
request")

Signed-off-by: Johannes Thumshirn <[email protected]>
Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request")
Reported-by: Chris Clayton <[email protected]>
Tested-by: Chris Clayton <[email protected]>
Cc: Douglas Gilbert <[email protected]>
Reviewed-by: Hannes Reinecke <[email protected]>
Tested-by: Chris Clayton <[email protected]>
Acked-by: Douglas Gilbert <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Cc: Cristian Crinteanu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/sg.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_
if (hp->dxferp || hp->dxfer_len > 0)
return false;
return true;
- case SG_DXFER_TO_DEV:
case SG_DXFER_FROM_DEV:
+ if (hp->dxfer_len < 0)
+ return false;
+ return true;
+ case SG_DXFER_TO_DEV:
case SG_DXFER_TO_FROM_DEV:
if (!hp->dxferp || hp->dxfer_len == 0)
return false;



2018-03-20 01:50:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 042/134] braille-console: Fix value returned by _braille_console_setup

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

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

From: Samuel Thibault <[email protected]>


[ Upstream commit 2ed2b8621be2708c0f6d61fe9841e9ad8b9753f0 ]

commit bbeddf52adc1 ("printk: move braille console support into
separate braille.[ch] files") introduced _braille_console_setup()
to outline the braille initialization code. There was however some
confusion over the value it was supposed to return. commit 2cfe6c4ac7ee
("printk: Fix return of braille_register_console()") tried to fix it
but failed to.

This fixes and documents the returned value according to the use
in printk.c: non-zero return means a parsing error, and thus this
console configuration should be ignored.

Signed-off-by: Samuel Thibault <[email protected]>
Cc: Aleksey Makarov <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Ming Lei <[email protected]>
Cc: Steven Rostedt <[email protected]>
Acked-by: Petr Mladek <[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]>
---
kernel/printk/braille.c | 15 ++++++++-------
kernel/printk/braille.h | 13 ++++++++++---
2 files changed, 18 insertions(+), 10 deletions(-)

--- a/kernel/printk/braille.c
+++ b/kernel/printk/braille.c
@@ -2,12 +2,13 @@

#include <linux/kernel.h>
#include <linux/console.h>
+#include <linux/errno.h>
#include <linux/string.h>

#include "console_cmdline.h"
#include "braille.h"

-char *_braille_console_setup(char **str, char **brl_options)
+int _braille_console_setup(char **str, char **brl_options)
{
if (!strncmp(*str, "brl,", 4)) {
*brl_options = "";
@@ -15,14 +16,14 @@ char *_braille_console_setup(char **str,
} else if (!strncmp(*str, "brl=", 4)) {
*brl_options = *str + 4;
*str = strchr(*brl_options, ',');
- if (!*str)
+ if (!*str) {
pr_err("need port name after brl=\n");
- else
- *((*str)++) = 0;
- } else
- return NULL;
+ return -EINVAL;
+ }
+ *((*str)++) = 0;
+ }

- return *str;
+ return 0;
}

int
--- a/kernel/printk/braille.h
+++ b/kernel/printk/braille.h
@@ -9,7 +9,14 @@ braille_set_options(struct console_cmdli
c->brl_options = brl_options;
}

-char *
+/*
+ * Setup console according to braille options.
+ * Return -EINVAL on syntax error, 0 on success (or no braille option was
+ * actually given).
+ * Modifies str to point to the serial options
+ * Sets brl_options to the parsed braille options.
+ */
+int
_braille_console_setup(char **str, char **brl_options);

int
@@ -25,10 +32,10 @@ braille_set_options(struct console_cmdli
{
}

-static inline char *
+static inline int
_braille_console_setup(char **str, char **brl_options)
{
- return NULL;
+ return 0;
}

static inline int



2018-03-20 01:50:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 122/134] lock_parent() needs to recheck if dentry got __dentry_killed under it

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

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

From: Al Viro <[email protected]>

commit 3b821409632ab778d46e807516b457dfa72736ed upstream.

In case when dentry passed to lock_parent() is protected from freeing only
by the fact that it's on a shrink list and trylock of parent fails, we
could get hit by __dentry_kill() (and subsequent dentry_kill(parent))
between unlocking dentry and locking presumed parent. We need to recheck
that dentry is alive once we lock both it and parent *and* postpone
rcu_read_unlock() until after that point. Otherwise we could return
a pointer to struct dentry that already is rcu-scheduled for freeing, with
->d_lock held on it; caller's subsequent attempt to unlock it can end
up with memory corruption.

Cc: [email protected] # 3.12+, counting backports
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/dcache.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -634,11 +634,16 @@ again:
spin_unlock(&parent->d_lock);
goto again;
}
- rcu_read_unlock();
- if (parent != dentry)
+ if (parent != dentry) {
spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED);
- else
+ if (unlikely(dentry->d_lockref.count < 0)) {
+ spin_unlock(&parent->d_lock);
+ parent = NULL;
+ }
+ } else {
parent = NULL;
+ }
+ rcu_read_unlock();
return parent;
}




2018-03-20 01:50:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 068/134] usb: dwc2: Make sure we disconnect the gadget state

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

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

From: John Stultz <[email protected]>


[ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]

I had seen some odd behavior with HiKey's usb-gadget interface
that I finally seemed to have chased down. Basically every other
time I plugged in the OTG port, the gadget interface would
properly initialize. The other times, I'd get a big WARN_ON
in dwc2_hsotg_init_fifo() about the fifo_map not being clear.

Ends up if we don't disconnect the gadget state, the fifo-map
doesn't get cleared properly, which causes WARN_ON messages and
also results in the device not properly being setup as a gadget
every other time the OTG port is connected.

So this patch adds a call to dwc2_hsotg_disconnect() in the
reset path so the state is properly cleared.

With it, the gadget interface initializes properly on every
plug in.

Cc: Wei Xu <[email protected]>
Cc: Guodong Xu <[email protected]>
Cc: Amit Pundir <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: John Youn <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Chen Yu <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Acked-by: John Youn <[email protected]>
Signed-off-by: John Stultz <[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/dwc2/hcd.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(s
dwc2_core_init(hsotg, false, -1);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(&hsotg->lock, flags);
+ dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(&hsotg->lock, flags);
dwc2_hsotg_core_connect(hsotg);



2018-03-20 01:50:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 107/134] ipvlan: add L2 check for packets arriving via virtual devices

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

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

From: Mahesh Bandewar <[email protected]>


[ Upstream commit 92ff42645028fa6f9b8aa767718457b9264316b4 ]

Packets that don't have dest mac as the mac of the master device should
not be entertained by the IPvlan rx-handler. This is mostly true as the
packet path mostly takes care of that, except when the master device is
a virtual device. As demonstrated in the following case -

ip netns add ns1
ip link add ve1 type veth peer name ve2
ip link add link ve2 name iv1 type ipvlan mode l2
ip link set dev iv1 netns ns1
ip link set ve1 up
ip link set ve2 up
ip -n ns1 link set iv1 up
ip addr add 192.168.10.1/24 dev ve1
ip -n ns1 addr 192.168.10.2/24 dev iv1
ping -c2 192.168.10.2
<Works!>
ip neigh show dev ve1
ip neigh show 192.168.10.2 lladdr <random> dev ve1
ping -c2 192.168.10.2
<Still works! Wrong!!>

This patch adds that missing check in the IPvlan rx-handler.

Reported-by: Amit Sikka <[email protected]>
Signed-off-by: Mahesh Bandewar <[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/ipvlan/ipvlan_core.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -282,6 +282,10 @@ static int ipvlan_rcv_frame(struct ipvl_
if (dev_forward_skb(ipvlan->dev, skb) == NET_RX_SUCCESS)
success = true;
} else {
+ if (!ether_addr_equal_64bits(eth_hdr(skb)->h_dest,
+ ipvlan->phy_dev->dev_addr))
+ skb->pkt_type = PACKET_OTHERHOST;
+
ret = RX_HANDLER_ANOTHER;
success = true;
}



2018-03-20 01:50:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 008/134] net: mvpp2: set dma mask and coherent dma mask on PPv2.2

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

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

From: Thomas Petazzoni <[email protected]>


[ Upstream commit 2067e0a13cfe0b1bdca7b91bc5e4f2740b07d478 ]

On PPv2.2, the streaming mappings can be anywhere in the first 40 bits
of the physical address space. However, for the coherent mappings, we
still need them to be in the first 32 bits of the address space,
because all BM pools share a single register to store the high 32 bits
of the BM pool address, which means all BM pools must be allocated in
the same 4GB memory area.

Signed-off-by: Thomas Petazzoni <[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/marvell/mvpp2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -6448,6 +6448,20 @@ static int mvpp2_probe(struct platform_d
/* Get system's tclk rate */
priv->tclk = clk_get_rate(priv->pp_clk);

+ if (priv->hw_version == MVPP22) {
+ err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(40));
+ if (err)
+ goto err_mg_clk;
+ /* Sadly, the BM pools all share the same register to
+ * store the high 32 bits of their address. So they
+ * must all have the same high 32 bits, which forces
+ * us to restrict coherent memory to DMA_BIT_MASK(32).
+ */
+ err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ if (err)
+ goto err_mg_clk;
+ }
+
/* Initialize network controller */
err = mvpp2_init(pdev, priv);
if (err < 0) {



2018-03-20 01:50:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 102/134] drm/amdkfd: Fix memory leaks in kfd topology

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

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

From: Yong Zhao <[email protected]>


[ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ]

Kobject created using kobject_create_and_add() can be freed using
kobject_put() when there is no referenece any more. However,
kobject memory allocated with kzalloc() has to set up a release
callback in order to free it when the counter decreases to 0.
Otherwise it causes memory leak.

Signed-off-by: Yong Zhao <[email protected]>
Signed-off-by: Felix Kuehling <[email protected]>
Reviewed-by: Oded Gabbay <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -519,11 +519,17 @@ static ssize_t sysprops_show(struct kobj
return ret;
}

+static void kfd_topology_kobj_release(struct kobject *kobj)
+{
+ kfree(kobj);
+}
+
static const struct sysfs_ops sysprops_ops = {
.show = sysprops_show,
};

static struct kobj_type sysprops_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &sysprops_ops,
};

@@ -559,6 +565,7 @@ static const struct sysfs_ops iolink_ops
};

static struct kobj_type iolink_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &iolink_ops,
};

@@ -586,6 +593,7 @@ static const struct sysfs_ops mem_ops =
};

static struct kobj_type mem_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &mem_ops,
};

@@ -625,6 +633,7 @@ static const struct sysfs_ops cache_ops
};

static struct kobj_type cache_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &cache_ops,
};

@@ -747,6 +756,7 @@ static const struct sysfs_ops node_ops =
};

static struct kobj_type node_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &node_ops,
};




2018-03-20 01:51:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 018/134] perf probe: Return errno when not hitting any event

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

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

From: Kefeng Wang <[email protected]>


[ Upstream commit 70946723eeb859466f026274b29c6196e39149c4 ]

On old perf, when using 'perf probe -d' to delete an inexistent event,
it returns errno, eg,

-bash-4.3# perf probe -d xxx || echo $?
Info: Event "*:xxx" does not exist.
Error: Failed to delete events.
255

But now perf_del_probe_events() will always set ret = 0, different from
previous del_perf_probe_events(). After this, it returns errno again,
eg,

-bash-4.3# ./perf probe -d xxx || echo $?
"xxx" does not hit any event.
Error: Failed to delete events.
254

And it is more appropriate to return -ENOENT instead of -EPERM.

Signed-off-by: Kefeng Wang <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Wang Nan <[email protected]>
Fixes: dddc7ee32fa1 ("perf probe: Fix an error when deleting probes successfully")
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/builtin-probe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -405,9 +405,9 @@ static int perf_del_probe_events(struct
}

if (ret == -ENOENT && ret2 == -ENOENT)
- pr_debug("\"%s\" does not hit any event.\n", str);
- /* Note that this is silently ignored */
- ret = 0;
+ pr_warning("\"%s\" does not hit any event.\n", str);
+ else
+ ret = 0;

error:
if (kfd >= 0)



2018-03-20 01:51:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 044/134] vxlan: vxlan dev should inherit lowerdevs gso_max_size

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

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

From: Felix Manlunas <[email protected]>


[ Upstream commit d6acfeb17d030bb3907e77c048b0e7783ad8e5a9 ]

vxlan dev currently ignores lowerdev's gso_max_size, which adversely
affects TSO performance of liquidio if it's the lowerdev. Egress TCP
packets' skb->len often exceed liquidio's advertised gso_max_size. This
may happen on other NIC drivers.

Fix it by assigning lowerdev's gso_max_size to that of vxlan dev. Might as
well do likewise for gso_max_segs.

Single flow TSO throughput of liquidio as lowerdev (using iperf3):

Before the patch: 139 Mbps
After the patch : 8.68 Gbps
Percent increase: 6,144 %

Signed-off-by: Felix Manlunas <[email protected]>
Signed-off-by: Satanand Burla <[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/vxlan.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2834,6 +2834,11 @@ static int vxlan_dev_configure(struct ne
needed_headroom = lowerdev->hard_header_len;
}

+ if (lowerdev) {
+ dev->gso_max_size = lowerdev->gso_max_size;
+ dev->gso_max_segs = lowerdev->gso_max_segs;
+ }
+
if (conf->mtu) {
err = __vxlan_change_mtu(dev, lowerdev, dst, conf->mtu, false);
if (err)



2018-03-20 01:51:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 070/134] drivers/perf: arm_pmu: handle no platform_device

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

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

From: Mark Rutland <[email protected]>


[ Upstream commit 7654137071fa706e5c91f4f27bc2a5cd7e435a9b ]

In armpmu_dispatch_irq() we look at arm_pmu::plat_device to acquire
platdata, so that we can defer to platform-specific IRQ handling,
required on some 32-bit parts. With the advent of ACPI we won't always
have a platform_device, and so we must avoid trying to dereference
fields from it.

This patch fixes up armpmu_dispatch_irq() to avoid doing so, introducing
a new armpmu_get_platdata() helper.

Signed-off-by: Mark Rutland <[email protected]>
Tested-by: Jeremy Linton <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/perf/arm_pmu.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -321,10 +321,16 @@ validate_group(struct perf_event *event)
return 0;
}

+static struct arm_pmu_platdata *armpmu_get_platdata(struct arm_pmu *armpmu)
+{
+ struct platform_device *pdev = armpmu->plat_device;
+
+ return pdev ? dev_get_platdata(&pdev->dev) : NULL;
+}
+
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
struct arm_pmu *armpmu;
- struct platform_device *plat_device;
struct arm_pmu_platdata *plat;
int ret;
u64 start_clock, finish_clock;
@@ -336,8 +342,8 @@ static irqreturn_t armpmu_dispatch_irq(i
* dereference.
*/
armpmu = *(void **)dev;
- plat_device = armpmu->plat_device;
- plat = dev_get_platdata(&plat_device->dev);
+
+ plat = armpmu_get_platdata(armpmu);

start_clock = sched_clock();
if (plat && plat->handle_irq)



2018-03-20 01:51:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 064/134] MIPS: r2-on-r6-emu: Fix BLEZL and BGTZL identification

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

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

From: Leonid Yegoshin <[email protected]>


[ Upstream commit 5bba7aa4958e271c3ffceb70d47d3206524cf489 ]

Fix the problem of inaccurate identification of instructions BLEZL and
BGTZL in R2 emulation code by making sure all necessary encoding
specifications are met.

Previously, certain R6 instructions could be identified as BLEZL or
BGTZL. R2 emulation routine didn't take into account that both BLEZL
and BGTZL instructions require their rt field (bits 20 to 16 of
instruction encoding) to be 0, and that, at same time, if the value in
that field is not 0, the encoding may represent a legitimate MIPS R6
instruction.

This means that a problem could occur after emulation optimization,
when emulation routine tried to pipeline emulation, picked up a next
candidate, and subsequently misrecognized an R6 instruction as BLEZL
or BGTZL.

It should be said that for single pass strategy, the problem does not
happen because CPU doesn't trap on branch-compacts which share opcode
space with BLEZL/BGTZL (but have rt field != 0, of course).

Signed-off-by: Leonid Yegoshin <[email protected]>
Signed-off-by: Miodrag Dinic <[email protected]>
Signed-off-by: Aleksandar Markovic <[email protected]>
Reported-by: Douglas Leung <[email protected]>
Reviewed-by: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/15456/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/kernel/mips-r2-to-r6-emul.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

--- a/arch/mips/kernel/mips-r2-to-r6-emul.c
+++ b/arch/mips/kernel/mips-r2-to-r6-emul.c
@@ -1097,10 +1097,20 @@ repeat:
}
break;

- case beql_op:
- case bnel_op:
case blezl_op:
case bgtzl_op:
+ /*
+ * For BLEZL and BGTZL, rt field must be set to 0. If this
+ * is not the case, this may be an encoding of a MIPS R6
+ * instruction, so return to CPU execution if this occurs
+ */
+ if (MIPSInst_RT(inst)) {
+ err = SIGILL;
+ break;
+ }
+ /* fall through */
+ case beql_op:
+ case bnel_op:
if (delay_slot(regs)) {
err = SIGILL;
break;



2018-03-20 01:52:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.4 033/134] tcp: sysctl: Fix a race to avoid unexpected 0 window from space

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

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

From: Gao Feng <[email protected]>


[ Upstream commit c48367427a39ea0b85c7cf018fe4256627abfd9e ]

Because sysctl_tcp_adv_win_scale could be changed any time, so there
is one race in tcp_win_from_space.
For example,
1.sysctl_tcp_adv_win_scale<=0 (sysctl_tcp_adv_win_scale is negative now)
2.space>>(-sysctl_tcp_adv_win_scale) (sysctl_tcp_adv_win_scale is postive now)

As a result, tcp_win_from_space returns 0. It is unexpected.

Certainly if the compiler put the sysctl_tcp_adv_win_scale into one
register firstly, then use the register directly, it would be ok.
But we could not depend on the compiler behavior.

Signed-off-by: Gao 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]>
---
include/net/tcp.h | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1199,9 +1199,11 @@ void tcp_select_initial_window(int __spa

static inline int tcp_win_from_space(int space)
{
- return sysctl_tcp_adv_win_scale<=0 ?
- (space>>(-sysctl_tcp_adv_win_scale)) :
- space - (space>>sysctl_tcp_adv_win_scale);
+ int tcp_adv_win_scale = sysctl_tcp_adv_win_scale;
+
+ return tcp_adv_win_scale <= 0 ?
+ (space>>(-tcp_adv_win_scale)) :
+ space - (space>>tcp_adv_win_scale);
}

/* Note: caller must be prepared to deal with negative returns */



2018-03-20 01:54:15

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.123 release.
> There are 134 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 Mar 21 17:18:04 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.123-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, and flashed onto my OnePlus 5.

No initial issues noticed in general usage or dmesg.

Thanks!
Nathan

2018-03-20 02:03:53

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Roger Quadros <[email protected]>
>
>
> [ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
>
> It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
> is in use then there are random chances that the usb_otg_ss module
> will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
>
> Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
> fixes this issue.
>
> We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
> issue or not so don't add this flag for those instances.
>
> Cc: Tero Kristo <[email protected]>
> Signed-off-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]>

This fails to build for me on arm32 with default config.

#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm multi_v7_defconfig
#
#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
#
../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
.flags = HWMOD_CLKDM_NOAUTO,
^
../scripts/Makefile.build:269: recipe for target 'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
make[2]: Target '__build' not remade because of errors.
/home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969: recipe for target 'arch/arm/mach-omap2' failed
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: Target '_all' not remade because of errors.
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Target '_all' not remade because of errors.

Dan

> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
> .class = &dra7xx_usb_otg_ss_hwmod_class,
> .clkdm_name = "l3init_clkdm",
> .main_clk = "dpll_core_h13x2_ck",
> + .flags = HWMOD_CLKDM_NOAUTO,
> .prcm = {
> .omap4 = {
> .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
> @@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
> .class = &dra7xx_usb_otg_ss_hwmod_class,
> .clkdm_name = "l3init_clkdm",
> .main_clk = "dpll_core_h13x2_ck",
> + .flags = HWMOD_CLKDM_NOAUTO,
> .prcm = {
> .omap4 = {
> .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,
>
>

2018-03-20 02:04:49

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.123 release.
> There are 134 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 Mar 21 17:18:04 UTC 2018.
> Anything received after that time might be too late.

4.4 fails to build on arm32 with default config due to
b4df31e348a4 ("ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss")

#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm multi_v7_defconfig
#
#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
#
../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
.flags = HWMOD_CLKDM_NOAUTO,
^
../scripts/Makefile.build:269: recipe for target 'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
make[2]: Target '__build' not remade because of errors.
/home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969: recipe for target 'arch/arm/mach-omap2' failed
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: Target '_all' not remade because of errors.
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Target '_all' not remade because of errors.

Dan

2018-03-20 05:10:22

by Tero Kristo

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

On 20/03/18 01:52, Dan Rue wrote:
> On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Roger Quadros <[email protected]>
>>
>>
>> [ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
>>
>> It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
>> is in use then there are random chances that the usb_otg_ss module
>> will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
>>
>> Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
>> fixes this issue.
>>
>> We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
>> issue or not so don't add this flag for those instances.
>>
>> Cc: Tero Kristo <[email protected]>
>> Signed-off-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]>
>
> This fails to build for me on arm32 with default config.
>
> #
> # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm multi_v7_defconfig
> #
> #
> # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
> #
> ../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
> .flags = HWMOD_CLKDM_NOAUTO,
> ^
> ../scripts/Makefile.build:269: recipe for target 'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
> make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
> make[2]: Target '__build' not remade because of errors.
> /home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969: recipe for target 'arch/arm/mach-omap2' failed
> make[1]: *** [arch/arm/mach-omap2] Error 2
> make[1]: Target '_all' not remade because of errors.
> Makefile:152: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
> make: Target '_all' not remade because of errors.

This again has some dependencies, at least:

8ff42da41147 ("ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO")

-Tero

>
> Dan
>
>> ---
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
>> .class = &dra7xx_usb_otg_ss_hwmod_class,
>> .clkdm_name = "l3init_clkdm",
>> .main_clk = "dpll_core_h13x2_ck",
>> + .flags = HWMOD_CLKDM_NOAUTO,
>> .prcm = {
>> .omap4 = {
>> .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
>> @@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
>> .class = &dra7xx_usb_otg_ss_hwmod_class,
>> .clkdm_name = "l3init_clkdm",
>> .main_clk = "dpll_core_h13x2_ck",
>> + .flags = HWMOD_CLKDM_NOAUTO,
>> .prcm = {
>> .omap4 = {
>> .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,
>>
>>

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2018-03-20 06:07:43

by Dan Rue

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

On Tue, Mar 20, 2018 at 07:08:36AM +0200, Tero Kristo wrote:
> On 20/03/18 01:52, Dan Rue wrote:
> > On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Roger Quadros <[email protected]>
> > >
> > >
> > > [ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
> > >
> > > It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
> > > is in use then there are random chances that the usb_otg_ss module
> > > will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
> > >
> > > Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
> > > fixes this issue.
> > >
> > > We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
> > > issue or not so don't add this flag for those instances.
> > >
> > > Cc: Tero Kristo <[email protected]>
> > > Signed-off-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]>
> >
> > This fails to build for me on arm32 with default config.
> >
> > #
> > # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm multi_v7_defconfig
> > #
> > #
> > # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
> > #
> > ../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
> > .flags = HWMOD_CLKDM_NOAUTO,
> > ^
> > ../scripts/Makefile.build:269: recipe for target 'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
> > make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
> > make[2]: Target '__build' not remade because of errors.
> > /home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969: recipe for target 'arch/arm/mach-omap2' failed
> > make[1]: *** [arch/arm/mach-omap2] Error 2
> > make[1]: Target '_all' not remade because of errors.
> > Makefile:152: recipe for target 'sub-make' failed
> > make: *** [sub-make] Error 2
> > make: Target '_all' not remade because of errors.
>
> This again has some dependencies, at least:
>
> 8ff42da41147 ("ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO")

Thank you - I can confirm that adding 8ff42da41147 fixes the arm32 build
for me.

>
> -Tero
>
> >
> > Dan
> >
> > > ---
> > > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > > @@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
> > > .class = &dra7xx_usb_otg_ss_hwmod_class,
> > > .clkdm_name = "l3init_clkdm",
> > > .main_clk = "dpll_core_h13x2_ck",
> > > + .flags = HWMOD_CLKDM_NOAUTO,
> > > .prcm = {
> > > .omap4 = {
> > > .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
> > > @@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
> > > .class = &dra7xx_usb_otg_ss_hwmod_class,
> > > .clkdm_name = "l3init_clkdm",
> > > .main_clk = "dpll_core_h13x2_ck",
> > > + .flags = HWMOD_CLKDM_NOAUTO,
> > > .prcm = {
> > > .omap4 = {
> > > .clkctrl_offs = DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,
> > >
> > >
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2018-03-20 07:44:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

On Tue, Mar 20, 2018 at 07:52:51AM +0800, Dan Rue wrote:
> On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Roger Quadros <[email protected]>
> >
> >
> > [ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
> >
> > It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
> > is in use then there are random chances that the usb_otg_ss module
> > will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
> >
> > Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
> > fixes this issue.
> >
> > We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
> > issue or not so don't add this flag for those instances.
> >
> > Cc: Tero Kristo <[email protected]>
> > Signed-off-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]>
>
> This fails to build for me on arm32 with default config.
>
> #
> # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm multi_v7_defconfig
> #
> #
> # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
> #
> ../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
> .flags = HWMOD_CLKDM_NOAUTO,
> ^
> ../scripts/Makefile.build:269: recipe for target 'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
> make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
> make[2]: Target '__build' not remade because of errors.
> /home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969: recipe for target 'arch/arm/mach-omap2' failed
> make[1]: *** [arch/arm/mach-omap2] Error 2
> make[1]: Target '_all' not remade because of errors.
> Makefile:152: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
> make: Target '_all' not remade because of errors.

I've dropped the patch that caused this problem now, will push out a
-rc2 in a few minutes, thanks.

greg k-h

2018-03-20 07:46:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Mon, Mar 19, 2018 at 01:57:05PM -0700, Nathan Chancellor wrote:
> On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.123 release.
> > There are 134 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 Mar 21 17:18:04 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.123-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, and flashed onto my OnePlus 5.
>
> No initial issues noticed in general usage or dmesg.

Great, thanks for testing and letting me know.

greg k-h

2018-03-20 07:53:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.123 release.
> There are 134 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 Mar 21 17:18:04 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.123-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.

-rc2 is out to fix a build error that was in -rc1:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz


2018-03-20 08:09:24

by Sam Protsenko

[permalink] [raw]
Subject: Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

On 20 March 2018 at 15:42, Greg Kroah-Hartman
<[email protected]> wrote:
> On Tue, Mar 20, 2018 at 07:52:51AM +0800, Dan Rue wrote:
>> On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
>> > 4.4-stable review patch. If anyone has any objections, please let me know.
>> >
>> > ------------------
>> >
>> > From: Roger Quadros <[email protected]>
>> >
>> >
>> > [ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
>> >
>> > It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
>> > is in use then there are random chances that the usb_otg_ss module
>> > will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
>> >
>> > Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
>> > fixes this issue.
>> >
>> > We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
>> > issue or not so don't add this flag for those instances.
>> >
>> > Cc: Tero Kristo <[email protected]>
>> > Signed-off-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]>
>>
>> This fails to build for me on arm32 with default config.
>>
>> #
>> # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm multi_v7_defconfig
>> #
>> #
>> # make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
>> #
>> ../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
>> .flags = HWMOD_CLKDM_NOAUTO,
>> ^
>> ../scripts/Makefile.build:269: recipe for target 'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
>> make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
>> make[2]: Target '__build' not remade because of errors.
>> /home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969: recipe for target 'arch/arm/mach-omap2' failed
>> make[1]: *** [arch/arm/mach-omap2] Error 2
>> make[1]: Target '_all' not remade because of errors.
>> Makefile:152: recipe for target 'sub-make' failed
>> make: *** [sub-make] Error 2
>> make: Target '_all' not remade because of errors.
>
> I've dropped the patch that caused this problem now, will push out a
> -rc2 in a few minutes, thanks.
>

Didn't see that conversation and sent series to fix this problem.
Probably to drop that patch is a better solution. In that case please
just ignore my series.

Thanks!

> greg k-h

2018-03-20 13:34:45

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On 03/19/2018 11:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.123 release.
> There are 134 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 Mar 21 17:18:04 UTC 2018.
> Anything received after that time might be too late.
>

For v4.4.122-134-gb4e03b4:

Build results:
total: 145 pass: 140 fail: 5
Failed builds:
arm:allmodconfig
powerpc:defconfig
powerpc:allmodconfig
powerpc:cell_defconfig
powerpc:maple_defconfig

arm:allmodconfig:

drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_probe':
drivers/net/ethernet/marvell/mvpp2.c:6451:10: error: 'struct mvpp2' has no member named 'hw_version'
if (priv->hw_version == MVPP22) {
^
drivers/net/ethernet/marvell/mvpp2.c:6451:26: error: 'MVPP22' undeclared (first use in this function)
if (priv->hw_version == MVPP22) {
^
powerpc:

arch/powerpc/mm/hugetlbpage.c: In function 'add_huge_page_size':
arch/powerpc/mm/hugetlbpage.c:840:2: error: implicit declaration of function 'radix_enabled'

Guenter

2018-03-20 17:24:31

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On 20 March 2018 at 13:20, Greg Kroah-Hartman
<[email protected]> wrote:
> On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 4.4.123 release.
>> There are 134 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 Mar 21 17:18:04 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.123-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.
>
> -rc2 is out to fix a build error that was in -rc1:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary
------------------------------------------------------------------------

kernel: 4.4.123-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: b4e03b46235c27f79031a504b8bf20d085338f18
git describe: v4.4.122-134-gb4e03b46235c
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.122-134-gb4e03b46235c


No regressions (compared to build v4.4.122-135-gce9da67811cd)

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 29, pass: 34
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 152, pass: 998
* ltp-timers-tests - skip: 1, pass: 12

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 33, pass: 47
* kselftest-vsyscall-mode-native - skip: 33, pass: 47
* kselftest-vsyscall-mode-none - skip: 33, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 149, pass: 1001
* ltp-timers-tests - skip: 1, pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 29, pass: 33
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 98, pass: 1052
* ltp-timers-tests - skip: 1, pass: 12

x86_64
* boot - pass: 22
* kselftest - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-native - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-none - skip: 31, fail: 2, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 120, pass: 1030
* ltp-timers-tests - skip: 1, pass: 12

Hikey test results,

Summary
------------------------------------------------------------------------

kernel: 4.4.123-rc2
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.123-rc2-hikey-20180320-153
git commit: 0ad868c09a57249a737a21599412c085870c72ce
git describe: 4.4.123-rc2-hikey-20180320-153
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.123-rc2-hikey-20180320-153


No regressions (compared to build 4.4.123-rc1-hikey-20180319-152)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 32, pass: 31
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 154, pass: 996
* ltp-timers-tests - skip: 1, pass: 12

--
Linaro QA (beta)
https://qa-reports.linaro.org

>
> _______________________________________________
> Lkft-triage mailing list
> [email protected]
> https://lists.linaro.org/mailman/listinfo/lkft-triage

2018-03-20 17:35:15

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On 03/19/2018 12:04 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.123 release.
> There are 134 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 Mar 21 17:18:04 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.123-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-03-21 05:30:34

by Nathan Chancellor

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Tue, Mar 20, 2018 at 06:32:00AM -0700, Guenter Roeck wrote:
> On 03/19/2018 11:04 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.123 release.
> > There are 134 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 Mar 21 17:18:04 UTC 2018.
> > Anything received after that time might be too late.
> >
>
> For v4.4.122-134-gb4e03b4:
>
> Build results:
> total: 145 pass: 140 fail: 5
> Failed builds:
> arm:allmodconfig
> powerpc:defconfig
> powerpc:allmodconfig
> powerpc:cell_defconfig
> powerpc:maple_defconfig
>
> arm:allmodconfig:
>
> drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_probe':
> drivers/net/ethernet/marvell/mvpp2.c:6451:10: error: 'struct mvpp2' has no member named 'hw_version'
> if (priv->hw_version == MVPP22) {
> ^
> drivers/net/ethernet/marvell/mvpp2.c:6451:26: error: 'MVPP22' undeclared (first use in this function)
> if (priv->hw_version == MVPP22) {
>

Caused by commit 6349601ed3e1 ("net: mvpp2: set dma mask and coherent
dma mask on PPv2.2"), which seems irrelevant for 4.4 since PPv2.2
support was added in 4.12 per upstream commit fc5e1550e5c3 ("net: mvpp2:
finally add the PPv2.2 compatible string").

> powerpc:
>
> arch/powerpc/mm/hugetlbpage.c: In function 'add_huge_page_size':
> arch/powerpc/mm/hugetlbpage.c:840:2: error: implicit declaration of function 'radix_enabled'
>

Caused by commit 17cd5e81ded7 ("powerpc/mm/hugetlb: Filter out hugepage
size not supported by page table layout"). It is introduced in 4.7 in
upstream commit 566ca99af026 ("powerpc/mm/radix: Add dummy
radix_enabled()") and not properly turned on until upstream commit
a8ed87c92adf ("powerpc/mm/radix: Add MMU_FTR_RADIX"). I am going to
assume from the fact there is a lot of MMU work after this and the
wording of the Kconfig entry that this is probably not suitable fo
a stable backport.

> Guenter

Cheers,
Nathan

2018-03-21 13:13:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Tue, Mar 20, 2018 at 10:29:11PM -0700, Nathan Chancellor wrote:
> On Tue, Mar 20, 2018 at 06:32:00AM -0700, Guenter Roeck wrote:
> > On 03/19/2018 11:04 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.123 release.
> > > There are 134 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 Mar 21 17:18:04 UTC 2018.
> > > Anything received after that time might be too late.
> > >
> >
> > For v4.4.122-134-gb4e03b4:
> >
> > Build results:
> > total: 145 pass: 140 fail: 5
> > Failed builds:
> > arm:allmodconfig
> > powerpc:defconfig
> > powerpc:allmodconfig
> > powerpc:cell_defconfig
> > powerpc:maple_defconfig
> >
> > arm:allmodconfig:
> >
> > drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_probe':
> > drivers/net/ethernet/marvell/mvpp2.c:6451:10: error: 'struct mvpp2' has no member named 'hw_version'
> > if (priv->hw_version == MVPP22) {
> > ^
> > drivers/net/ethernet/marvell/mvpp2.c:6451:26: error: 'MVPP22' undeclared (first use in this function)
> > if (priv->hw_version == MVPP22) {
> >
>
> Caused by commit 6349601ed3e1 ("net: mvpp2: set dma mask and coherent
> dma mask on PPv2.2"), which seems irrelevant for 4.4 since PPv2.2
> support was added in 4.12 per upstream commit fc5e1550e5c3 ("net: mvpp2:
> finally add the PPv2.2 compatible string").

Dropped from both the 4.4.y and 4.9.y trees (I saw it was failing the
build in 4.9.y as well.)

thanks,

greg k-h

2018-03-21 13:16:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Tue, Mar 20, 2018 at 10:29:11PM -0700, Nathan Chancellor wrote:
> > powerpc:
> >
> > arch/powerpc/mm/hugetlbpage.c: In function 'add_huge_page_size':
> > arch/powerpc/mm/hugetlbpage.c:840:2: error: implicit declaration of function 'radix_enabled'
> >
>
> Caused by commit 17cd5e81ded7 ("powerpc/mm/hugetlb: Filter out hugepage
> size not supported by page table layout"). It is introduced in 4.7 in
> upstream commit 566ca99af026 ("powerpc/mm/radix: Add dummy
> radix_enabled()") and not properly turned on until upstream commit
> a8ed87c92adf ("powerpc/mm/radix: Add MMU_FTR_RADIX"). I am going to
> assume from the fact there is a lot of MMU work after this and the
> wording of the Kconfig entry that this is probably not suitable fo
> a stable backport.

Now dropped from the 4.4.y queue as well, thanks to both of you for this
work.

Let me go do some more -rc releases now...

thanks,

greg k-h

2018-03-21 13:21:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.123 release.
> > There are 134 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 Mar 21 17:18:04 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.123-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.
>
> -rc2 is out to fix a build error that was in -rc1:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz

And now -rc3 is out to hopefully resolve the last of the reported
problems:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz


2018-03-21 13:23:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Tue, Mar 20, 2018 at 10:52:45PM +0530, Naresh Kamboju wrote:
> On 20 March 2018 at 13:20, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 4.4.123 release.
> >> There are 134 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 Mar 21 17:18:04 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.123-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.
> >
> > -rc2 is out to fix a build error that was in -rc1:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for testing and letting me know.

greg k-h

2018-03-21 17:43:11

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Wed, Mar 21, 2018 at 02:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.123 release.
> > > There are 134 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 Mar 21 17:18:04 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.123-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.
> >
> > -rc2 is out to fix a build error that was in -rc1:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
>
> And now -rc3 is out to hopefully resolve the last of the reported
> problems:
>
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz
>

Almost. For 4.4.122-132-g78a7af7:

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 127 pass: 125 fail: 2
Failed tests:
powerpc:mpc8544ds:mpc85xx_defconfig
powerpc:mpc8544ds:mpc85xx_smp_defconfig

Error log:
drivers/mtd/nand/fsl_ifc_nand.c: In function 'fsl_ifc_chip_init':
drivers/mtd/nand/fsl_ifc_nand.c:995:23: error: 'FSL_IFC_VERSION_2_0_0' undeclared

Most likely commit 2a39eeb6949c ("mtd: nand: ifc: update bufnum mask for ver >=
2.0.0") doesn't really apply to v4.4 and older kernels.

Guenter

2018-03-21 19:42:12

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On 21 March 2018 at 18:48, Greg Kroah-Hartman
<[email protected]> wrote:
> On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
>> On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
>> > This is the start of the stable review cycle for the 4.4.123 release.
>> > There are 134 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 Mar 21 17:18:04 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.123-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.
>>
>> -rc2 is out to fix a build error that was in -rc1:
>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
>
> And now -rc3 is out to hopefully resolve the last of the reported
> problems:
>
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary
------------------------------------------------------------------------

kernel: 4.4.123-rc3
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 78a7af793a37563cedcf5322a9832d3fdb70dade
git describe: v4.4.122-132-g78a7af793a37
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.122-132-g78a7af793a37


No regressions (compared to build v4.4.122-134-gb4e03b46235c)

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 29, pass: 34
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 152, pass: 998
* ltp-timers-tests - skip: 1, pass: 12

qemu_x86_64
* boot - pass: 22
* kselftest - skip: 33, pass: 47
* kselftest-vsyscall-mode-native - skip: 33, pass: 47
* kselftest-vsyscall-mode-none - skip: 33, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 150, pass: 1000
* ltp-timers-tests - skip: 1, pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 29, pass: 33
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 98, pass: 1052
* ltp-timers-tests - skip: 1, pass: 12

x86_64
* boot - fail: 1, pass: 22
* kselftest - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-native - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-none - skip: 31, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 120, pass: 1030
* ltp-timers-tests - skip: 1, pass: 12

--
Linaro QA (beta)
https://qa-reports.linaro.org

>
> _______________________________________________
> Lkft-triage mailing list
> [email protected]
> https://lists.linaro.org/mailman/listinfo/lkft-triage

2018-03-22 08:22:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Wed, Mar 21, 2018 at 10:40:43AM -0700, Guenter Roeck wrote:
> On Wed, Mar 21, 2018 at 02:18:43PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.4.123 release.
> > > > There are 134 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 Mar 21 17:18:04 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.123-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.
> > >
> > > -rc2 is out to fix a build error that was in -rc1:
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
> >
> > And now -rc3 is out to hopefully resolve the last of the reported
> > problems:
> >
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz
> >
>
> Almost. For 4.4.122-132-g78a7af7:
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 127 pass: 125 fail: 2
> Failed tests:
> powerpc:mpc8544ds:mpc85xx_defconfig
> powerpc:mpc8544ds:mpc85xx_smp_defconfig
>
> Error log:
> drivers/mtd/nand/fsl_ifc_nand.c: In function 'fsl_ifc_chip_init':
> drivers/mtd/nand/fsl_ifc_nand.c:995:23: error: 'FSL_IFC_VERSION_2_0_0' undeclared
>
> Most likely commit 2a39eeb6949c ("mtd: nand: ifc: update bufnum mask for ver >=
> 2.0.0") doesn't really apply to v4.4 and older kernels.

Yeah, good catch, now dropping this one.

Odd that the Qemu test fails, but the build doesn't?

thanks again for the testing and help here.

greg k-h

2018-03-22 13:17:21

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On 03/22/2018 01:20 AM, Greg Kroah-Hartman wrote:
> On Wed, Mar 21, 2018 at 10:40:43AM -0700, Guenter Roeck wrote:
>> On Wed, Mar 21, 2018 at 02:18:43PM +0100, Greg Kroah-Hartman wrote:
>>> On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
>>>> On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 4.4.123 release.
>>>>> There are 134 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 Mar 21 17:18:04 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.123-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.
>>>>
>>>> -rc2 is out to fix a build error that was in -rc1:
>>>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
>>>
>>> And now -rc3 is out to hopefully resolve the last of the reported
>>> problems:
>>>
>>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz
>>>
>>
>> Almost. For 4.4.122-132-g78a7af7:
>>
>> Build results:
>> total: 145 pass: 145 fail: 0
>> Qemu test results:
>> total: 127 pass: 125 fail: 2
>> Failed tests:
>> powerpc:mpc8544ds:mpc85xx_defconfig
>> powerpc:mpc8544ds:mpc85xx_smp_defconfig
>>
>> Error log:
>> drivers/mtd/nand/fsl_ifc_nand.c: In function 'fsl_ifc_chip_init':
>> drivers/mtd/nand/fsl_ifc_nand.c:995:23: error: 'FSL_IFC_VERSION_2_0_0' undeclared
>>
>> Most likely commit 2a39eeb6949c ("mtd: nand: ifc: update bufnum mask for ver >=
>> 2.0.0") doesn't really apply to v4.4 and older kernels.
>
> Yeah, good catch, now dropping this one.
>
> Odd that the Qemu test fails, but the build doesn't?
>

To conserve energy and time, I don't run a compile-only test if the same image is built
as part of the qemu tests.

Guenter

2018-03-22 16:41:42

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Wed, Mar 21, 2018 at 02:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.123 release.
> > > There are 134 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 Mar 21 17:18:04 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.123-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.
> >
> > -rc2 is out to fix a build error that was in -rc1:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
>
> And now -rc3 is out to hopefully resolve the last of the reported
> problems:
>
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz
>

Indeed it does:

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 127 pass: 127 fail: 0

Guenter

2018-03-22 17:09:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 000/134] 4.4.123-stable review

On Thu, Mar 22, 2018 at 09:39:17AM -0700, Guenter Roeck wrote:
> On Wed, Mar 21, 2018 at 02:18:43PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Mar 20, 2018 at 08:50:12AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Mar 19, 2018 at 07:04:43PM +0100, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.4.123 release.
> > > > There are 134 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 Mar 21 17:18:04 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.123-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.
> > >
> > > -rc2 is out to fix a build error that was in -rc1:
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc2.gz
> >
> > And now -rc3 is out to hopefully resolve the last of the reported
> > problems:
> >
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.123-rc3.gz
> >
>
> Indeed it does:
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 127 pass: 127 fail: 0

Wonderful, thanks for letting me know.

greg k-h

2018-03-29 15:31:50

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 009/134] PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

On Mon, 2018-03-19 at 19:04 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Prarit Bhargava <[email protected]>
>
>
> [ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]
[...]
> The MSI disabling code was added by d52877c7b1af ("pci/irq: let
> pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
> enabled and kdump failed because the kexeced kernel wasn't prepared to
> receive the MSI interrupts.
>
> Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even
> if kernel doesn't support MSI")

This went into 4.2 and hasn't been backported.

> and  e80e7edc55ba ("PCI/MSI: Initialize MSI capability for all
> architectures")

This went into 4.5 and hasn't been backported.

> changed the kexeced kernel to disable all MSIs itself so it no longer
> depends on the crashed kernel to clean up after itself.
[...]

So I think 3.18-stable and 4.4-stable will need backports of the later
changes in order for this to work properly.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-03-29 16:15:21

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 014/134] perf tools: Make perf_event__synthesize_mmap_events() scale

On Mon, 2018-03-19 at 19:04 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Stephane Eranian <[email protected]>
>
>
> [ Upstream commit 88b897a30c525c2eee6e7f16e1e8d0f18830845e ]
>
> This patch significantly improves the execution time of
> perf_event__synthesize_mmap_events() when running perf record on systems
> where processes have lots of threads.
>
> It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to
> generate each map line in the maps file.  If you have 1000 threads, then you
> have necessarily 1000 stacks.  For each vma, you need to check if it
> corresponds to a thread's stack.  With a large number of threads, this can take
> a very long time. I have seen latencies >> 10mn.
>
> As of today, perf does not use the fact that a mapping is a stack, therefore we
> can work around the issue by using /proc/pid/tasks/pid/maps.  This entry does
> not try to map a vma to stack and is thus much faster with no loss of
> functonality.
>
> The proc-map-timeout logic is kept in case users still want some upper limit.
>
> In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual
> /proc/pid/task/pid/maps, tasks -> task.  Thanks Arnaldo for catching this.
>
> Committer note:
>
> This problem seems to have been elliminated in the kernel since commit :
> b18cb64ead40 ("fs/proc: Stop trying to report thread stacks").
[...]

I don't think so. It looks like this was fixed by commit 65376df58217
("proc: revert /proc/<pid>/maps [stack:TID] annotation") which we
already have in 4.4-stable. But older branches (3.16, 3.18, 4.1) don't
have that and probably should do.

It looks like commit b18cb64ead40 ("fs/proc: Stop trying to report
thread stacks") is also a candidate for stable.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-03-29 21:25:22

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 033/134] tcp: sysctl: Fix a race to avoid unexpected 0 window from space

On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Gao Feng <[email protected]>
>
>
> [ Upstream commit c48367427a39ea0b85c7cf018fe4256627abfd9e ]
>
> Because sysctl_tcp_adv_win_scale could be changed any time, so there
> is one race in tcp_win_from_space.
> For example,
> 1.sysctl_tcp_adv_win_scale<=0 (sysctl_tcp_adv_win_scale is negative now)
> 2.space>>(-sysctl_tcp_adv_win_scale) (sysctl_tcp_adv_win_scale is postive now)
>
> As a result, tcp_win_from_space returns 0. It is unexpected.
>
> Certainly if the compiler put the sysctl_tcp_adv_win_scale into one
> register firstly, then use the register directly, it would be ok.
> But we could not depend on the compiler behavior.

This is true, but the compiler can also decide that this local variable
is just an alias for the global variable and still read it twice. It
is necessary to use READ_ONCE() to prevent that.

Ben.

> Signed-off-by: Gao 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]>
> ---
>  include/net/tcp.h |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1199,9 +1199,11 @@ void tcp_select_initial_window(int __spa
>  
>  static inline int tcp_win_from_space(int space)
>  {
> - return sysctl_tcp_adv_win_scale<=0 ?
> - (space>>(-sysctl_tcp_adv_win_scale)) :
> - space - (space>>sysctl_tcp_adv_win_scale);
> + int tcp_adv_win_scale = sysctl_tcp_adv_win_scale;
> +
> + return tcp_adv_win_scale <= 0 ?
> + (space>>(-tcp_adv_win_scale)) :
> + space - (space>>tcp_adv_win_scale);
>  }
>  
>  /* Note: caller must be prepared to deal with negative returns */

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-01 15:51:15

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 068/134] usb: dwc2: Make sure we disconnect the gadget state

On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: John Stultz <[email protected]>
>
>
> [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]

Maybe we should also have:

commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09
Author: John Stultz <[email protected]>
Date:   Mon Oct 23 14:32:48 2017 -0700

    usb: dwc2: Improve gadget state disconnection handling

Ben.

> I had seen some odd behavior with HiKey's usb-gadget interface
> that I finally seemed to have chased down. Basically every other
> time I plugged in the OTG port, the gadget interface would
> properly initialize. The other times, I'd get a big WARN_ON
> in dwc2_hsotg_init_fifo() about the fifo_map not being clear.
>
> Ends up if we don't disconnect the gadget state, the fifo-map
> doesn't get cleared properly, which causes WARN_ON messages and
> also results in the device not properly being setup as a gadget
> every other time the OTG port is connected.
>
> So this patch adds a call to dwc2_hsotg_disconnect() in the
> reset path so the state is properly cleared.
>
> With it, the gadget interface initializes properly on every
> plug in.
>
> Cc: Wei Xu <[email protected]>
> Cc: Guodong Xu <[email protected]>
> Cc: Amit Pundir <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: John Youn <[email protected]>
> Cc: Douglas Anderson <[email protected]>
> Cc: Chen Yu <[email protected]>
> Cc: Felipe Balbi <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: [email protected]
> Acked-by: John Youn <[email protected]>
> Signed-off-by: John Stultz <[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/dwc2/hcd.c |    1 +
>  1 file changed, 1 insertion(+)
>
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(s
>   dwc2_core_init(hsotg, false, -1);
>   dwc2_enable_global_interrupts(hsotg);
>   spin_lock_irqsave(&hsotg->lock, flags);
> + dwc2_hsotg_disconnect(hsotg);
>   dwc2_hsotg_core_init_disconnected(hsotg, false);
>   spin_unlock_irqrestore(&hsotg->lock, flags);
>  dwc2_hsotg_core_connect(hsotg);

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-01 16:22:06

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 076/134] kprobes/x86: Set kprobes pages read-only

On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Masami Hiramatsu <[email protected]>
>
>
> [ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]

This caused a regression in mainline, fixed by:

commit c93f5cf571e7795f97d49ef51b766cf25e328545
Author: Masami Hiramatsu <[email protected]>
Date:   Thu May 25 19:38:17 2017 +0900

    kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

Ben.

> Set the pages which is used for kprobes' singlestep buffer
> and optprobe's trampoline instruction buffer to readonly.
> This can prevent unexpected (or unintended) instruction
> modification.
>
> This also passes rodata_test as below.
>
> Without this patch, rodata_test shows a warning:
>
>   WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20
>   x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000
>
> With this fix, no W+X pages are found:
>
>   x86/mm: Checked W+X mappings: passed, no W+X pages found.
>   rodata_test: all tests were successful
>
> Reported-by: Andrey Ryabinin <[email protected]>
> Signed-off-by: Masami Hiramatsu <[email protected]>
> Cc: Ananth N Mavinakayanahalli <[email protected]>
> Cc: Anil S Keshavamurthy <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Brian Gerst <[email protected]>
> Cc: David S . Miller <[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]>
> Cc: Ye Xiaolong <[email protected]>
> Link: http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devbox
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
>  arch/x86/kernel/kprobes/core.c |    4 ++++
>  arch/x86/kernel/kprobes/opt.c  |    3 +++
>  2 files changed, 7 insertions(+)
>
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -406,6 +406,8 @@ static int arch_copy_kprobe(struct kprob
>  {
>   int ret;
>  
> + set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
> +
>   /* Copy an instruction with recovering if other optprobe modifies it.*/
>   ret = __copy_instruction(p->ainsn.insn, p->addr);
>   if (!ret)
> @@ -420,6 +422,8 @@ static int arch_copy_kprobe(struct kprob
>   else
>   p->ainsn.boostable = -1;
>  
> + set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
> +
>   /* Check whether the instruction modifies Interrupt Flag or not */
>   p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
>  
> --- a/arch/x86/kernel/kprobes/opt.c
> +++ b/arch/x86/kernel/kprobes/opt.c
> @@ -370,6 +370,7 @@ int arch_prepare_optimized_kprobe(struct
>   }
>  
>   buf = (u8 *)op->optinsn.insn;
> + set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
>  
>   /* Copy instructions into the out-of-line buffer */
>   ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
> @@ -392,6 +393,8 @@ int arch_prepare_optimized_kprobe(struct
>   synthesize_reljump(buf + TMPL_END_IDX + op->optinsn.size,
>      (u8 *)op->kp.addr + op->optinsn.size);
>  
> + set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
> +
>   flush_icache_range((unsigned long) buf,
>      (unsigned long) buf + TMPL_END_IDX +
>      op->optinsn.size + RELATIVEJUMP_SIZE);

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-01 18:58:21

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 085/134] test_firmware: fix setting old custom fw path back on exit

On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: "Luis R. Rodriguez" <[email protected]>
>
>
> [ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]
>
> The file /sys/module/firmware_class/parameters/path can be used
> to set a custom firmware path. The fw_filesystem.sh script creates
> a temporary directory to add a test firmware file to be used during
> testing, in order for this to work it uses the custom path syfs file
> and it was supposed to reset back the file on execution exit. The
> script failed to do this due to a typo, it was using OLD_PATH instead
> of OLD_FWPATH, since its inception since v3.17.
>
> Its not as easy to just keep the old setting, it turns out that
> resetting an empty setting won't actually do what we want, we need
> to check if it was empty and set an empty space.

That doesn't seem to work either. I don't see any stripping of spaces
in the generic parameter code or firmware_class, and the parameter
reads back as a space:

# echo -n ' ' > path
# od -tx1 path
0000000 20 0a
0000002

However, this seems to work:

# printf '\0' > path
# od -tx1 path
0000000 0a
0000001

Ben.

> Without this we end up having the temporary path always set after
> we run these tests.
>
> Fixes: 0a8adf58475 ("test: add firmware_class loader test")
> Signed-off-by: Luis R. Rodriguez <[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]>
> ---
>  tools/testing/selftests/firmware/fw_filesystem.sh |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> --- a/tools/testing/selftests/firmware/fw_filesystem.sh
> +++ b/tools/testing/selftests/firmware/fw_filesystem.sh
> @@ -28,7 +28,10 @@ test_finish()
>   if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
>   echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
>   fi
> - echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path
> + if [ "$OLD_FWPATH" = "" ]; then
> + OLD_FWPATH=" "
> + fi
> + echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
>   rm -f "$FW"
>   rmdir "$FWPATH"
>  }
>
>
>
--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-01 20:50:27

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 088/134] ARM: dts: am335x-pepper: Fix the audio CODECs reset pin

On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: "Andrew F. Davis" <[email protected]>
>
>
> [ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]
>
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", fix this here.

This doesn't work without commit a825f31f9328 ("ASoC: tlv320aic31xx:
Use standard reset GPIO OF name") which went into 4.16. Please revert
this for all stable branches.

Ben.

> Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
>
> Signed-off-by: Andrew F. Davis <[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/am335x-pepper.dts |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/arm/boot/dts/am335x-pepper.dts
> +++ b/arch/arm/boot/dts/am335x-pepper.dts
> @@ -139,7 +139,7 @@
>  &audio_codec {
>   status = "okay";
>  
> - gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
>   AVDD-supply = <&ldo3_reg>;
>   IOVDD-supply = <&ldo3_reg>;
>   DRVDD-supply = <&ldo3_reg>;

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-01 20:51:38

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 089/134] ARM: dts: omap3-n900: Fix the audio CODECs reset pin

On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: "Andrew F. Davis" <[email protected]>
>
>
> [ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]
>
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", fix this here.

This also depends on a driver change. Please revert it for all stable
branches.

Ben.

> Fixes: 14e3e295b2b9 ("ARM: dts: omap3-n900: Add TLV320AIC3X support")
>
> Signed-off-by: Andrew F. Davis <[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/omap3-n900.dts |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -488,7 +488,7 @@
>   tlv320aic3x: tlv320aic3x@18 {
>   compatible = "ti,tlv320aic3x";
>   reg = <0x18>;
> - gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
> + reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
>   ai3x-gpio-func = <
>   0 /* AIC3X_GPIO1_FUNC_DISABLED */
>   5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
> @@ -505,7 +505,7 @@
>   tlv320aic3x_aux: tlv320aic3x@19 {
>   compatible = "ti,tlv320aic3x";
>   reg = <0x19>;
> - gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */
> + reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */
>  
>   AVDD-supply = <&vmmc2>;
>   DRVDD-supply = <&vmmc2>;

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-01 20:58:06

by Ben Hutchings

[permalink] [raw]
Subject: Re: [PATCH 4.4 092/134] cpufreq: Fix governor module removal race

On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: "Rafael J. Wysocki" <[email protected]>
>
>
> [ Upstream commit a8b149d32b663c1a4105273295184b78f53d33cf ]
[...]
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -551,6 +551,8 @@ static int cpufreq_parse_governor(char *
>   *governor = t;
>   err = 0;
>   }
> + if (t && !try_module_get(t->owner))
> + t = NULL;

This won't work because t is dead after this point.  The fix appears to
depend on:

commit 045149e6a22119e5bf0d16a0b24a4173a2abb71d
Author: Rafael J. Wysocki <[email protected]>
Date: Thu Nov 23 01:23:16 2017 +0100

cpufreq: Clean up cpufreq_parse_governor()

which moves the assignment to *governor further down.

Ben.
 
>   mutex_unlock(&cpufreq_governor_mutex);
>   }
> @@ -669,6 +671,10 @@ static ssize_t store_scaling_governor(st
>   return -EINVAL;
>  
>   ret = cpufreq_set_policy(policy, &new_policy);
> +
> + if (new_policy.governor)
> + module_put(new_policy.governor->owner);
> +
>   return ret ? ret : count;
>  }
>  

--
Ben Hutchings
Software Developer, Codethink Ltd.


2018-04-02 06:47:37

by Masami Hiramatsu

[permalink] [raw]
Subject: Re: [PATCH 4.4 076/134] kprobes/x86: Set kprobes pages read-only

On Sun, 01 Apr 2018 17:20:30 +0100
Ben Hutchings <[email protected]> wrote:

> On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Masami Hiramatsu <[email protected]>
> >
> >
> > [ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
>
> This caused a regression in mainline, fixed by:
>
> commit c93f5cf571e7795f97d49ef51b766cf25e328545
> Author: Masami Hiramatsu <[email protected]>
> Date:   Thu May 25 19:38:17 2017 +0900
>
>     kprobes/x86: Fix to set RWX bits correctly before releasing trampoline

Thanks Ben,
Greg, could you please pick above patch too?

Thank you,

>
> Ben.
>
> > Set the pages which is used for kprobes' singlestep buffer
> > and optprobe's trampoline instruction buffer to readonly.
> > This can prevent unexpected (or unintended) instruction
> > modification.
> >
> > This also passes rodata_test as below.
> >
> > Without this patch, rodata_test shows a warning:
> >
> >   WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:235 note_page+0x7a9/0xa20
> >   x86/mm: Found insecure W+X mapping at address ffffffffa0000000/0xffffffffa0000000
> >
> > With this fix, no W+X pages are found:
> >
> >   x86/mm: Checked W+X mappings: passed, no W+X pages found.
> >   rodata_test: all tests were successful
> >
> > Reported-by: Andrey Ryabinin <[email protected]>
> > Signed-off-by: Masami Hiramatsu <[email protected]>
> > Cc: Ananth N Mavinakayanahalli <[email protected]>
> > Cc: Anil S Keshavamurthy <[email protected]>
> > Cc: Borislav Petkov <[email protected]>
> > Cc: Brian Gerst <[email protected]>
> > Cc: David S . Miller <[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]>
> > Cc: Ye Xiaolong <[email protected]>
> > Link: http://lkml.kernel.org/r/149076375592.22469.14174394514338612247.stgit@devbox
> > Signed-off-by: Ingo Molnar <[email protected]>
> > Signed-off-by: Sasha Levin <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> >  arch/x86/kernel/kprobes/core.c |    4 ++++
> >  arch/x86/kernel/kprobes/opt.c  |    3 +++
> >  2 files changed, 7 insertions(+)
> >
> > --- a/arch/x86/kernel/kprobes/core.c
> > +++ b/arch/x86/kernel/kprobes/core.c
> > @@ -406,6 +406,8 @@ static int arch_copy_kprobe(struct kprob
> >  {
> >   int ret;
> >  
> > + set_memory_rw((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
> > +
> >   /* Copy an instruction with recovering if other optprobe modifies it.*/
> >   ret = __copy_instruction(p->ainsn.insn, p->addr);
> >   if (!ret)
> > @@ -420,6 +422,8 @@ static int arch_copy_kprobe(struct kprob
> >   else
> >   p->ainsn.boostable = -1;
> >  
> > + set_memory_ro((unsigned long)p->ainsn.insn & PAGE_MASK, 1);
> > +
> >   /* Check whether the instruction modifies Interrupt Flag or not */
> >   p->ainsn.if_modifier = is_IF_modifier(p->ainsn.insn);
> >  
> > --- a/arch/x86/kernel/kprobes/opt.c
> > +++ b/arch/x86/kernel/kprobes/opt.c
> > @@ -370,6 +370,7 @@ int arch_prepare_optimized_kprobe(struct
> >   }
> >  
> >   buf = (u8 *)op->optinsn.insn;
> > + set_memory_rw((unsigned long)buf & PAGE_MASK, 1);
> >  
> >   /* Copy instructions into the out-of-line buffer */
> >   ret = copy_optimized_instructions(buf + TMPL_END_IDX, op->kp.addr);
> > @@ -392,6 +393,8 @@ int arch_prepare_optimized_kprobe(struct
> >   synthesize_reljump(buf + TMPL_END_IDX + op->optinsn.size,
> >      (u8 *)op->kp.addr + op->optinsn.size);
> >  
> > + set_memory_ro((unsigned long)buf & PAGE_MASK, 1);
> > +
> >   flush_icache_range((unsigned long) buf,
> >      (unsigned long) buf + TMPL_END_IDX +
> >      op->optinsn.size + RELATIVEJUMP_SIZE);
>
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.
>


--
Masami Hiramatsu <[email protected]>

2018-04-03 10:31:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 076/134] kprobes/x86: Set kprobes pages read-only

On Mon, Apr 02, 2018 at 03:45:57PM +0900, Masami Hiramatsu wrote:
> On Sun, 01 Apr 2018 17:20:30 +0100
> Ben Hutchings <[email protected]> wrote:
>
> > On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch.??If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Masami Hiramatsu <[email protected]>
> > >
> > >
> > > [ Upstream commit d0381c81c2f782fa2131178d11e0cfb23d50d631 ]
> >
> > This caused a regression in mainline, fixed by:
> >
> > commit c93f5cf571e7795f97d49ef51b766cf25e328545
> > Author: Masami Hiramatsu <[email protected]>
> > Date:???Thu May 25 19:38:17 2017 +0900
> >
> > ????kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
>
> Thanks Ben,
> Greg, could you please pick above patch too?

Now picked up, thanks.

greg k-h

2018-04-03 17:43:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 068/134] usb: dwc2: Make sure we disconnect the gadget state

On Sun, Apr 01, 2018 at 04:49:45PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:05 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: John Stultz <[email protected]>
> >
> >
> > [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]
>
> Maybe we should also have:
>
> commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09
> Author: John Stultz <[email protected]>
> Date:???Mon Oct 23 14:32:48 2017 -0700
>
> ????usb: dwc2: Improve gadget state disconnection handling

Good idea, now queued up.

greg k-h

2018-04-03 19:08:43

by Luis Chamberlain

[permalink] [raw]
Subject: Re: [PATCH 4.4 085/134] test_firmware: fix setting old custom fw path back on exit

On Sun, Apr 01, 2018 at 07:56:55PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: "Luis R. Rodriguez" <[email protected]>
> >
> >
> > [ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]
> >
> > The file /sys/module/firmware_class/parameters/path can be used
> > to set a custom firmware path. The fw_filesystem.sh script creates
> > a temporary directory to add a test firmware file to be used during
> > testing, in order for this to work it uses the custom path syfs file
> > and it was supposed to reset back the file on execution exit. The
> > script failed to do this due to a typo, it was using OLD_PATH instead
> > of OLD_FWPATH, since its inception since v3.17.
> >
> > Its not as easy to just keep the old setting, it turns out that
> > resetting an empty setting won't actually do what we want, we need
> > to check if it was empty and set an empty space.
>
> That doesn't seem to work either. I don't see any stripping of spaces
> in the generic parameter code or firmware_class, and the parameter
> reads back as a space:
>
> # echo -n ' ' > path
> # od -tx1 path
> 0000000 20 0a
> 0000002
>
> However, this seems to work:
>
> # printf '\0' > path
> # od -tx1 path
> 0000000 0a
> 0000001

Not sure what you mean, care to send a patch?

Luis
>
> Ben.
>
> > Without this we end up having the temporary path always set after
> > we run these tests.
> >
> > Fixes: 0a8adf58475 ("test: add firmware_class loader test")
> > Signed-off-by: Luis R. Rodriguez <[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]>
> > ---
> > ?tools/testing/selftests/firmware/fw_filesystem.sh |????5 ++++-
> > ?1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > --- a/tools/testing/selftests/firmware/fw_filesystem.sh
> > +++ b/tools/testing/selftests/firmware/fw_filesystem.sh
> > @@ -28,7 +28,10 @@ test_finish()
> > ? if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
> > ? echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
> > ? fi
> > - echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path
> > + if [ "$OLD_FWPATH" = "" ]; then
> > + OLD_FWPATH=" "
> > + fi
> > + echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
> > ? rm -f "$FW"
> > ? rmdir "$FWPATH"
> > ?}
> >
> >
> >
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.
>
>

--
Do not panic

2018-04-04 15:25:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 009/134] PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

On Thu, Mar 29, 2018 at 04:28:54PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:04 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Prarit Bhargava <[email protected]>
> >
> >
> > [ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]
> [...]
> > The MSI disabling code was added by d52877c7b1af ("pci/irq: let
> > pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
> > enabled and kdump failed because the kexeced kernel wasn't prepared to
> > receive the MSI interrupts.
> >
> > Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even
> > if kernel doesn't support MSI")
>
> This went into 4.2 and hasn't been backported.

To backport that to 3.18.y takes 2 other patches to get it "correct".

> > and??e80e7edc55ba ("PCI/MSI: Initialize MSI capability for all
> > architectures")
>
> This went into 4.5 and hasn't been backported.

Yeah, but that really isn't needed unless 4d9aac397a5d ("powerpc/PCI:
Disable MSI/MSI-X interrupts at PCI probe time in OF case") is also
there, along with 1851617cd2da.

> So I think 3.18-stable and 4.4-stable will need backports of the later
> changes in order for this to work properly.

I think I'm just going to revert this as no one is complaining about
this issue on 4.4.y and 3.18.y kernels. Thanks for the review.

greg k-h

2018-04-06 06:51:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 088/134] ARM: dts: am335x-pepper: Fix the audio CODECs reset pin

On Sun, Apr 01, 2018 at 09:48:15PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: "Andrew F. Davis" <[email protected]>
> >
> >
> > [ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]
> >
> > The correct DT property for specifying a GPIO used for reset
> > is "reset-gpios", fix this here.
>
> This doesn't work without commit a825f31f9328 ("ASoC: tlv320aic31xx:
> Use standard reset GPIO OF name") which went into 4.16. Please revert
> this for all stable branches.

Now reverted, thanks.

greg k-h

2018-04-06 06:59:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 089/134] ARM: dts: omap3-n900: Fix the audio CODECs reset pin

On Sun, Apr 01, 2018 at 09:49:40PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: "Andrew F. Davis" <[email protected]>
> >
> >
> > [ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]
> >
> > The correct DT property for specifying a GPIO used for reset
> > is "reset-gpios", fix this here.
>
> This also depends on a driver change. Please revert it for all stable
> branches.

Now reverted everywhere, thanks.

greg k-h

2018-04-06 07:07:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 014/134] perf tools: Make perf_event__synthesize_mmap_events() scale

On Thu, Mar 29, 2018 at 05:13:56PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:04 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Stephane Eranian <[email protected]>
> >
> >
> > [ Upstream commit 88b897a30c525c2eee6e7f16e1e8d0f18830845e ]
> >
> > This patch significantly improves the execution time of
> > perf_event__synthesize_mmap_events() when running perf record on systems
> > where processes have lots of threads.
> >
> > It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to
> > generate each map line in the maps file.??If you have 1000 threads, then you
> > have necessarily 1000 stacks.??For each vma, you need to check if it
> > corresponds to a thread's stack.??With a large number of threads, this can take
> > a very long time. I have seen latencies >> 10mn.
> >
> > As of today, perf does not use the fact that a mapping is a stack, therefore we
> > can work around the issue by using /proc/pid/tasks/pid/maps.??This entry does
> > not try to map a vma to stack and is thus much faster with no loss of
> > functonality.
> >
> > The proc-map-timeout logic is kept in case users still want some upper limit.
> >
> > In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual
> > /proc/pid/task/pid/maps, tasks -> task.??Thanks Arnaldo for catching this.
> >
> > Committer note:
> >
> > This problem seems to have been elliminated in the kernel since commit :
> > b18cb64ead40 ("fs/proc: Stop trying to report thread stacks").
> [...]
>
> I don't think so. It looks like this was fixed by commit 65376df58217
> ("proc: revert /proc/<pid>/maps [stack:TID] annotation") which we
> already have in 4.4-stable. But older branches (3.16, 3.18, 4.1) don't
> have that and probably should do.

Now added to 3.18.y

> It looks like commit b18cb64ead40 ("fs/proc: Stop trying to report
> thread stacks") is also a candidate for stable.

Now added to 3.18.y and 4.4.y, thanks!

greg k-h

2018-04-06 07:09:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.4 092/134] cpufreq: Fix governor module removal race

On Sun, Apr 01, 2018 at 09:56:41PM +0100, Ben Hutchings wrote:
> On Mon, 2018-03-19 at 19:06 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.??If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: "Rafael J. Wysocki" <[email protected]>
> >
> >
> > [ Upstream commit a8b149d32b663c1a4105273295184b78f53d33cf ]
> [...]
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -551,6 +551,8 @@ static int cpufreq_parse_governor(char *
> > ? *governor = t;
> > ? err = 0;
> > ? }
> > + if (t && !try_module_get(t->owner))
> > + t = NULL;
>
> This won't work because t is dead after this point. ?The fix appears to
> depend on:
>
> commit 045149e6a22119e5bf0d16a0b24a4173a2abb71d
> Author: Rafael J. Wysocki <[email protected]>
> Date: Thu Nov 23 01:23:16 2017 +0100
>
> cpufreq: Clean up cpufreq_parse_governor()
>
> which moves the assignment to *governor further down.

Ick, this also didn't make it into 4.9.y so I'm just reverting it from
everywhere.

thanks for the review!

greg k-h