2015-11-12 23:18:40

by Kamal Mostafa

[permalink] [raw]
Subject: [3.19.y-ckt stable] Linux 3.19.8-ckt10 stable review

This is the start of the review cycle for the Linux 3.19.8-ckt10 stable kernel.

This version contains 155 new patches, summarized below. The new patches are
posted as replies to this message and also available in this git branch:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y-review

git://kernel.ubuntu.com/ubuntu/linux.git linux-3.19.y-review

The review period for version 3.19.8-ckt10 will be open for the next three days.
To report a problem, please reply to the relevant follow-up patch message.

For more information about the Linux 3.19.y-ckt extended stable kernel version,
see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable .

-Kamal

--
arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 +-
arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 ++
arch/arm/boot/dts/imx6qdl-rex.dtsi | 2 -
arch/arm/plat-orion/common.c | 2 +-
arch/arm64/Makefile | 2 +-
arch/arm64/kernel/armv8_deprecated.c | 16 +++---
arch/arm64/kernel/entry-ftrace.S | 22 +++++++-
arch/arm64/kernel/stacktrace.c | 6 +--
arch/arm64/mm/fault.c | 1 +
arch/m68k/include/asm/linkage.h | 30 +++++++++++
arch/mips/kernel/cps-vec.S | 12 +++--
arch/mips/mm/dma-default.c | 2 +-
arch/powerpc/kernel/rtas.c | 3 ++
arch/s390/boot/compressed/Makefile | 2 +-
arch/sparc/crypto/aes_glue.c | 2 +
arch/sparc/crypto/camellia_glue.c | 1 +
arch/sparc/crypto/des_glue.c | 2 +
arch/x86/boot/compressed/eboot.c | 8 ++-
arch/x86/include/asm/processor.h | 3 +-
arch/x86/include/asm/thread_info.h | 27 ++++++++++
arch/x86/kernel/crash.c | 7 ++-
arch/x86/kernel/entry_32.S | 2 +-
arch/x86/kernel/process_64.c | 52 ++++++++++++++----
arch/x86/kernel/setup.c | 8 +++
arch/x86/kvm/svm.c | 8 ++-
arch/x86/mm/init_64.c | 2 +-
arch/x86/platform/efi/efi.c | 67 ++++++++++++++++++++++-
arch/x86/xen/enlighten.c | 23 ++++++++
arch/x86/xen/setup.c | 2 +-
crypto/ablkcipher.c | 2 +-
crypto/ahash.c | 3 +-
crypto/algapi.c | 2 +-
crypto/api.c | 6 +--
crypto/crypto_user.c | 2 +-
drivers/base/regmap/regmap-debugfs.c | 5 +-
drivers/block/rbd.c | 72 ++++++++++++++-----------
drivers/block/xen-blkfront.c | 3 +-
drivers/clk/ti/clk-3xxx.c | 2 +-
drivers/dma/dw/core.c | 4 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 51 ++++++++++++------
drivers/gpu/drm/drm_sysfs.c | 12 ++---
drivers/gpu/drm/i915/i915_gem_userptr.c | 5 +-
drivers/gpu/drm/i915/intel_display.c | 7 +++
drivers/gpu/drm/i915/intel_lrc.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 24 +++++++++
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 21 ++++++--
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_display.c | 14 +----
drivers/gpu/drm/radeon/radeon_encoders.c | 1 -
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 70 +++++++++++++++---------
drivers/gpu/drm/radeon/si_dpm.c | 2 +
drivers/i2c/busses/i2c-designware-platdrv.c | 31 +++++++++--
drivers/i2c/busses/i2c-mv64xxx.c | 2 -
drivers/i2c/busses/i2c-rcar.c | 7 +--
drivers/i2c/busses/i2c-s3c2410.c | 8 +--
drivers/infiniband/core/cm.c | 10 +++-
drivers/iommu/amd_iommu.c | 4 +-
drivers/iommu/amd_iommu_types.h | 1 +
drivers/iommu/intel-iommu.c | 12 +++--
drivers/isdn/i4l/isdn_ppp.c | 12 +++--
drivers/md/dm-cache-policy-cleaner.c | 2 +-
drivers/md/dm-raid.c | 3 +-
drivers/md/dm-thin.c | 2 +-
drivers/md/dm.c | 4 +-
drivers/md/md.c | 3 +-
drivers/md/persistent-data/dm-btree-remove.c | 17 +++---
drivers/md/persistent-data/dm-btree.c | 2 +-
drivers/md/raid0.c | 69 +++++++++++++-----------
drivers/md/raid1.c | 2 +-
drivers/md/raid10.c | 2 +-
drivers/md/raid5.c | 6 ++-
drivers/media/dvb-frontends/si2168.c | 4 ++
drivers/media/platform/vivid/vivid-osd.c | 1 +
drivers/misc/cxl/native.c | 2 +-
drivers/mtd/nand/sunxi_nand.c | 27 ++++------
drivers/mtd/ubi/io.c | 5 ++
drivers/mtd/ubi/vtbl.c | 1 +
drivers/mtd/ubi/wl.c | 1 +
drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 2 +-
drivers/net/ppp/ppp_generic.c | 6 +--
drivers/net/ppp/pppoe.c | 3 +-
drivers/net/slip/slhc.c | 12 +++--
drivers/net/slip/slip.c | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 1 +
drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-7000.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/d3.c | 12 ++---
drivers/net/wireless/iwlwifi/mvm/fw.c | 4 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/mvm/mvm.h | 5 ++
drivers/net/wireless/iwlwifi/pcie/drv.c | 5 ++
drivers/pci/pci-sysfs.c | 2 +-
drivers/pinctrl/freescale/pinctrl-imx25.c | 4 +-
drivers/scsi/3w-9xxx.c | 28 +++++++---
drivers/scsi/mvsas/mv_sas.c | 2 +
drivers/staging/dgnc/dgnc_mgmt.c | 1 +
drivers/staging/iio/accel/sca3000_ring.c | 2 +-
drivers/staging/iio/adc/mxs-lradc.c | 9 ++--
drivers/staging/speakup/fakekey.c | 1 +
drivers/tty/n_tty.c | 15 ++----
drivers/tty/serial/8250/8250_core.c | 8 +++
drivers/tty/tty_io.c | 31 +++++++++--
drivers/usb/core/quirks.c | 13 +++++
drivers/usb/host/xhci-pci.c | 1 +
drivers/usb/host/xhci-ring.c | 30 +++++++++--
fs/btrfs/backref.c | 8 ++-
fs/btrfs/ioctl.c | 5 ++
fs/btrfs/volumes.h | 8 +++
fs/cifs/inode.c | 34 ------------
fs/overlayfs/copy_up.c | 6 +--
include/drm/drm_dp_mst_helper.h | 3 +-
include/linux/skbuff.h | 3 ++
include/net/af_unix.h | 6 ++-
include/net/sock.h | 8 +++
include/sound/soc.h | 6 ++-
include/sound/wm8904.h | 2 +-
include/xen/interface/sched.h | 8 +++
ipc/msg.c | 14 ++---
ipc/shm.c | 13 ++---
ipc/util.c | 8 +--
kernel/irq/proc.c | 19 ++++++-
kernel/module.c | 8 ++-
kernel/sched/core.c | 10 ++--
kernel/sched/sched.h | 5 +-
kernel/time/clocksource.c | 2 +-
kernel/workqueue.c | 8 +--
lib/fault-inject.c | 2 +-
mm/filemap.c | 9 ++--
mm/hugetlb.c | 8 +++
mm/memcontrol.c | 1 +
mm/slab.c | 13 +++--
net/core/ethtool.c | 2 +-
net/core/filter.c | 6 ++-
net/core/skbuff.c | 9 ++--
net/ipv4/gre_offload.c | 3 +-
net/ipv6/xfrm6_output.c | 17 +++---
net/l2tp/l2tp_core.c | 11 +++-
net/netlink/af_netlink.c | 34 +++++++-----
net/openvswitch/flow_table.c | 3 +-
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 6 ++-
net/unix/af_unix.c | 16 +++++-
sound/pci/hda/patch_cirrus.c | 1 +
sound/pci/hda/patch_conexant.c | 1 +
sound/pci/hda/patch_realtek.c | 1 +
sound/soc/au1x/db1200.c | 4 ++
sound/soc/codecs/sgtl5000.c | 4 +-
sound/soc/codecs/tas2552.c | 4 +-
sound/soc/dwc/designware_i2s.c | 4 +-
sound/soc/soc-ops.c | 28 ++++++++++
sound/synth/emux/emux_oss.c | 3 +-
tools/lib/traceevent/event-parse.c | 23 ++++++--
tools/perf/util/symbol-elf.c | 35 +++++-------
158 files changed, 1061 insertions(+), 464 deletions(-)

Aaron Conole (2):
af_unix: Convert the unix_sk macro to an inline function for type safety
af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

Adam Richter (1):
drm: fix mutex leak in drm_dp_get_mst_branch_device

Adrian Hunter (1):
perf tools: Fix copying of /proc/kcore

Alex Deucher (5):
drm/radeon: move bl encoder assignment into bl init
drm/radeon: fix dpms when driver backlight control is disabled
drm/radeon: add pm sysfs files late
drm/radeon: add quirk for ASUS R7 370
drm/radeon: don't try to recreate sysfs entries on resume

Alexander Couzens (1):
l2tp: protect tunnel->del_work by ref_count

Alexandre Belloni (1):
iio: mxs-lradc: Fix temperature offset

Alim Akhtar (1):
ARM: dts: Fix audio card detection on Peach boards

Andreas Dannenberg (1):
ASoC: tas2552: fix dBscale-min declaration

Andreas Schwab (1):
m68k: Define asmlinkage_protect

Andrey Vagin (1):
net/unix: fix logic about sk_peek_offset

Andy Lutomirski (1):
x86/asm/entry: Create and use a 'TOP_OF_KERNEL_STACK_PADDING' macro

Andy Shevchenko (1):
dmaengine: dw: properly read DWC_PARAMS register

Arad, Ronen (1):
netlink: Trim skb to alloc size to avoid MSG_TRUNC

Arik Nemtsov (1):
iwlwifi: mvm: init card correctly on ctkill exit check

Avraham Stern (1):
iwlwifi: mvm: clear csa countdown when AP is stopped

Bandan Das (1):
KVM: nSVM: Check for NRIPS support before updating control field

Ben Dooks (1):
clk: ti: fix dual-registration of uart4_ick

Ben Hutchings (3):
isdn_ppp: Add checks for allocation failure in isdn_ppp_open()
ppp, slip: Validate VJ compression slot parameters completely
genirq: Fix race in register_irq_proc()

Ben Skeggs (1):
drm/nouveau/fbcon: take runpm reference when userspace has an open fd

Boris BREZILLON (2):
mtd: nand: sunxi: fix OOB handling in ->write_xxx() functions
mtd: nand: sunxi: fix sunxi_nand_chips_cleanup()

Carol L Soto (1):
net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

Cathy Avery (1):
xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

Charles Keepax (2):
ASoC: Add info callback for SX_TLV controls
ASoC: wm8904: Correct number of EQ registers

Chris Mason (1):
btrfs: fix use after free iterating extrefs

Chris Wilson (2):
drm/i915: Flush pipecontrol post-sync writes
drm/i915: Deny wrapping an userptr into a framebuffer

Christian Borntraeger (1):
s390/boot/decompression: disable floating point in decompressor

Christian Zander (1):
iommu/vt-d: fix range computation when making room for large pages

Christoph Hellwig (1):
3w-9xxx: don't unmap bounce buffered commands

Christophe Lombard (1):
cxl: Fix number of allocated pages in SPA

Dan Carpenter (1):
iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()

Daniel Borkmann (1):
bpf: fix panic in SO_GET_FILTER with native ebpf programs

Daniel Vetter (1):
drm: Fix locking for sysfs dpms file

Dave Airlie (3):
drm/dp/mst: fixup handling hotplug on port removal.
drm/dp/mst: drop cancel work sync in the mstb destroy path (v2)
drm/dp/mst: make mst i2c transfer code more robust.

Dave Kleikamp (1):
crypto: sparc - initialize blkcipher.ivsize

David Henningsson (1):
ALSA: hda - Fix inverted internal mic on Lenovo G50-80

David Howells (2):
ovl: use O_LARGEFILE in ovl_copy_up()
ovl: fix dentry reference leak

David Sterba (1):
btrfs: check unsupported filters in balance arguments

Dirk Müller (1):
Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

Doron Tsur (1):
IB/cm: Fix rb-tree duplicate free and use-after-free

Dāvis Mosāns (1):
mvsas: Fix NULL pointer dereference in mvs_slot_task_free

Eric Dumazet (2):
net: add pfmemalloc check in sk_add_backlog()
ipv6: gre: support SIT encapsulation

Fabiano Fidêncio (1):
drm/qxl: recreate the primary surface when the bo is not primary

Felipe F. Tonello (1):
ARM: dts: fix usb pin control for imx-rex dts

Felix Fietkau (1):
ath9k: declare required extra tx headroom

Florian Fainelli (1):
ARM: orion: Fix DSA platform device after mvmdio conversion

Florian Westphal (1):
fault-inject: fix inverted interval/probability values in printk

Gianluca Renzi (1):
ASoC: sgtl5000: fix wrong register MIC_BIAS_VOLTAGE setup on probe

Guillaume Nault (2):
ppp: don't override sk->sk_state in pppoe_flush_dev()
ppp: fix pppoe_dev deletion condition in pppoe_release()

Herbert Xu (2):
crypto: api - Only abort operations on fatal signal
ipv6: Fix IPsec pre-encap fragmentation check

Hezi Shahmoon (1):
i2c: mv64xxx: really allow I2C offloading

Ilia Mirkin (1):
drm/nouveau/gem: return only valid domain when there's only one

Ilya Dryomov (3):
rbd: fix double free on rbd_dev->header_name
rbd: don't leak parent_spec in rbd_dev_probe_parent()
rbd: prevent kernel stack blow up on rbd map

James Hogan (1):
MIPS: dma-default: Fix 32-bit fall back to GFP_DMA

Jan Kara (1):
mm: make sendfile(2) killable

Jann Horn (1):
drivers/tty: require read access for controlling terminal

Jes Sorensen (2):
md/raid1: submit_bio_wait() returns 0 on success
md/raid10: submit_bio_wait() returns 0 on success

Joe Perches (1):
ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings

Joe Thornber (2):
dm cache: fix NULL pointer when switching from cleaner policy
dm btree remove: fix a bug when rebalancing nodes after removal

Joerg Roedel (1):
iommu/amd: Don't clear DTE flags when modifying it

Johannes Berg (3):
iwlwifi: dvm: fix D3 firmware PN programming
iwlwifi: mvm: fix D3 firmware PN programming
iwlwifi: fix firmware filename for 3160

John Flatness (1):
ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1

John Stultz (1):
clocksource: Fix abs() usage w/ 64bit values

Joonsoo Kim (1):
mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1)

Junichi Nomura (1):
dm: fix AB-BA deadlock in __dm_destroy()

Kapileshwar Singh (1):
tools lib traceevent: Fix string handling in heterogeneous arch environments

Konstantin Khlebnikov (1):
ovs: do not allocate memory from offline numa node

Kosuke Tatsukawa (1):
tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

Kővágó, Zoltán (1):
x86/efi: Fix multiple GOP device support

Lars-Peter Clausen (1):
ASoC: db1200: Fix DAI link format for db1300 and db1550

Laura Abbott (3):
ALSA: hda: Add dock support for ThinkPad T550
xhci: Add spurious wakeup quirk for LynxPoint-LP controllers
[media] si2168: Bounds check firmware

Lee, Chun-Yi (1):
x86/kexec: Fix kexec crash in syscall kexec_file_load()

Li Bin (1):
arm64: ftrace: fix function_graph tracer panic

Linus Torvalds (1):
Initialize msg/shm IPC objects before doing ipc_addid()

Luca Coelho (1):
iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series

Malcolm Crossley (1):
x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

Mans Rullgard (1):
serial: 8250: add uart_config entry for PORT_RT2880

Mark Brown (2):
regmap: debugfs: Ensure we don't underflow when printing access masks
regmap: debugfs: Don't bother actually printing when calculating max length

Mark Salyzyn (1):
arm64: readahead: fault retry breaks mmap file read random detection

Mathias Nyman (2):
xhci: don't finish a TD if we get a short transfer event mid TD
xhci: handle no ping response error properly

Matt Fleming (1):
x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

Maxim Sheviakov (1):
drm/radeon: add quirk for MSI R7 370

Mel Gorman (1):
mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault

Michel Dänzer (1):
drm/radeon: Restore LCD backlight level on resume (>= R5xx)

Mika Westerberg (1):
i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

Mike Snitzer (2):
dm thin: fix missing pool reference count decrement in pool_ctr error path
dm btree: fix leak of bufio-backed block in btree_split_beneath error path

Mikulas Patocka (1):
dm raid: fix round up of default region size

NeilBrown (3):
md/raid0: update queue parameter in a safer location.
md/raid0: apply base queue limits *before* disk_stack_limits
Revert "md: allow a partially recovered device to be hot-added to an array."

Paolo Bonzini (1):
x86/setup: Extend low identity map to cover whole kernel range

Paul Burton (3):
MIPS: CPS: Stop dangling delay slot from has_mt.
MIPS: CPS: Don't include MT code in non-MT kernels.
MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT

Peter Ujfalusi (1):
ASoC: tas2552: Correct the Speaker Driver Playback Volume (PGA_GAIN)

Peter Zijlstra (2):
sched/core: Fix TASK_DEAD race in finish_task_switch()
module: Fix locking in symbol_put_addr()

Pravin B Shelar (2):
skbuff: Fix skb checksum flag on skb pull
skbuff: Fix skb checksum partial check.

Richard Weinberger (1):
UBI: Validate data_size

Roman Gushchin (1):
md/raid5: fix locking in handle_stripe_clean_event()

Ronny Hegewald (1):
rbd: require stable pages if message data CRCs are enabled

Russell King (1):
crypto: ahash - ensure statesize is non-zero

Salva Peiró (2):
[media] media/vivid-osd: fix info leak in ioctl
staging/dgnc: fix info leak in ioctl

Sasha Levin (1):
PCI: Prevent out of bounds access in numa_node override

Shaohua Li (2):
workqueue: make sure delayed work run in local cpu
memcg: convert threshold to bytes

Stephen Smalley (1):
x86/mm: Set NX on gap between __ex_table and rodata

Steve French (1):
[SMB3] Do not fall back to SMBWriteX in set_file_size error cases

Steve Wise (1):
svcrdma: handle rdma read with a non-zero initial page offset

Takashi Iwai (1):
ALSA: synth: Fix conflicting OSS device registration on AWE32

Thomas Gleixner (1):
x86/process: Add proper bound checks in 64bit get_wchan()

Tomi Valkeinen (1):
ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on

Uwe Kleine-König (1):
pinctrl: imx25: ensure that a pin with id i is at position i in the info array

Vasant Hegde (1):
powerpc/rtas: Validate rtas.entry before calling enter_rtas()

Ville Syrjälä (1):
drm/i915: Restore lost DPLL register write on gen2-4

Vincent Palatin (1):
usb: Add device quirk for Logitech PTZ cameras

Vitaly Kuznetsov (1):
x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

Will Deacon (3):
arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419
arm64: compat: fix stxr failure case in SWP emulation
Revert "ARM64: unwind: Fix PC calculation"

Wolfram Sang (3):
i2c: rcar: enable RuntimePM before registering to the core
i2c: s3c2410: enable RuntimePM before registering to the core
i2c: designware-platdrv: enable RuntimePM before registering to the core

Yao-Wen Mao (1):
USB: Add reset-resume quirk for two Plantronics usb headphones.

Yitian Bu (1):
ASoC: dwc: correct irq clear method

[email protected] (1):
staging: speakup: fix speakup-r regression

shengyong (1):
UBI: return ENOSPC if no enough space available


2015-11-13 00:13:13

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 001/155] isdn_ppp: Add checks for allocation failure in isdn_ppp_open()

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

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

From: Ben Hutchings <[email protected]>

commit 0baa57d8dc32db78369d8b5176ef56c5e2e18ab3 upstream.

Compile-tested only.

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Reference: CVE-2015-7799
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/isdn/i4l/isdn_ppp.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/isdn/i4l/isdn_ppp.c b/drivers/isdn/i4l/isdn_ppp.c
index c4198fa..86f9abe 100644
--- a/drivers/isdn/i4l/isdn_ppp.c
+++ b/drivers/isdn/i4l/isdn_ppp.c
@@ -301,6 +301,8 @@ isdn_ppp_open(int min, struct file *file)
is->compflags = 0;

is->reset = isdn_ppp_ccp_reset_alloc(is);
+ if (!is->reset)
+ return -ENOMEM;

is->lp = NULL;
is->mp_seqno = 0; /* MP sequence number */
@@ -320,6 +322,10 @@ isdn_ppp_open(int min, struct file *file)
* VJ header compression init
*/
is->slcomp = slhc_init(16, 16); /* not necessary for 2. link in bundle */
+ if (!is->slcomp) {
+ isdn_ppp_ccp_reset_free(is);
+ return -ENOMEM;
+ }
#endif
#ifdef CONFIG_IPPP_FILTER
is->pass_filter = NULL;
--
1.9.1

2015-11-13 00:12:10

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 002/155] ppp, slip: Validate VJ compression slot parameters completely

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

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

From: Ben Hutchings <[email protected]>

commit 4ab42d78e37a294ac7bc56901d563c642e03c4ae upstream.

Currently slhc_init() treats out-of-range values of rslots and tslots
as equivalent to 0, except that if tslots is too large it will
dereference a null pointer (CVE-2015-7799).

Add a range-check at the top of the function and make it return an
ERR_PTR() on error instead of NULL. Change the callers accordingly.

Compile-tested only.

Reported-by: 郭永刚 <[email protected]>
References: http://article.gmane.org/gmane.comp.security.oss.general/17908
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/isdn/i4l/isdn_ppp.c | 10 ++++------
drivers/net/ppp/ppp_generic.c | 6 ++----
drivers/net/slip/slhc.c | 12 ++++++++----
drivers/net/slip/slip.c | 2 +-
4 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/isdn/i4l/isdn_ppp.c b/drivers/isdn/i4l/isdn_ppp.c
index 86f9abe..9c1e8ad 100644
--- a/drivers/isdn/i4l/isdn_ppp.c
+++ b/drivers/isdn/i4l/isdn_ppp.c
@@ -322,9 +322,9 @@ isdn_ppp_open(int min, struct file *file)
* VJ header compression init
*/
is->slcomp = slhc_init(16, 16); /* not necessary for 2. link in bundle */
- if (!is->slcomp) {
+ if (IS_ERR(is->slcomp)) {
isdn_ppp_ccp_reset_free(is);
- return -ENOMEM;
+ return PTR_ERR(is->slcomp);
}
#endif
#ifdef CONFIG_IPPP_FILTER
@@ -573,10 +573,8 @@ isdn_ppp_ioctl(int min, struct file *file, unsigned int cmd, unsigned long arg)
is->maxcid = val;
#ifdef CONFIG_ISDN_PPP_VJ
sltmp = slhc_init(16, val);
- if (!sltmp) {
- printk(KERN_ERR "ippp, can't realloc slhc struct\n");
- return -ENOMEM;
- }
+ if (IS_ERR(sltmp))
+ return PTR_ERR(sltmp);
if (is->slcomp)
slhc_free(is->slcomp);
is->slcomp = sltmp;
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 9d15566..cfe49a0 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -715,10 +715,8 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
val &= 0xffff;
}
vj = slhc_init(val2+1, val+1);
- if (!vj) {
- netdev_err(ppp->dev,
- "PPP: no memory (VJ compressor)\n");
- err = -ENOMEM;
+ if (IS_ERR(vj)) {
+ err = PTR_ERR(vj);
break;
}
ppp_lock(ppp);
diff --git a/drivers/net/slip/slhc.c b/drivers/net/slip/slhc.c
index 079f7ad..27ed252 100644
--- a/drivers/net/slip/slhc.c
+++ b/drivers/net/slip/slhc.c
@@ -84,8 +84,9 @@ static long decode(unsigned char **cpp);
static unsigned char * put16(unsigned char *cp, unsigned short x);
static unsigned short pull16(unsigned char **cpp);

-/* Initialize compression data structure
+/* Allocate compression data structure
* slots must be in range 0 to 255 (zero meaning no compression)
+ * Returns pointer to structure or ERR_PTR() on error.
*/
struct slcompress *
slhc_init(int rslots, int tslots)
@@ -94,11 +95,14 @@ slhc_init(int rslots, int tslots)
register struct cstate *ts;
struct slcompress *comp;

+ if (rslots < 0 || rslots > 255 || tslots < 0 || tslots > 255)
+ return ERR_PTR(-EINVAL);
+
comp = kzalloc(sizeof(struct slcompress), GFP_KERNEL);
if (! comp)
goto out_fail;

- if ( rslots > 0 && rslots < 256 ) {
+ if (rslots > 0) {
size_t rsize = rslots * sizeof(struct cstate);
comp->rstate = kzalloc(rsize, GFP_KERNEL);
if (! comp->rstate)
@@ -106,7 +110,7 @@ slhc_init(int rslots, int tslots)
comp->rslot_limit = rslots - 1;
}

- if ( tslots > 0 && tslots < 256 ) {
+ if (tslots > 0) {
size_t tsize = tslots * sizeof(struct cstate);
comp->tstate = kzalloc(tsize, GFP_KERNEL);
if (! comp->tstate)
@@ -141,7 +145,7 @@ out_free2:
out_free:
kfree(comp);
out_fail:
- return NULL;
+ return ERR_PTR(-ENOMEM);
}


diff --git a/drivers/net/slip/slip.c b/drivers/net/slip/slip.c
index 05387b1..a17d86a 100644
--- a/drivers/net/slip/slip.c
+++ b/drivers/net/slip/slip.c
@@ -164,7 +164,7 @@ static int sl_alloc_bufs(struct slip *sl, int mtu)
if (cbuff == NULL)
goto err_exit;
slcomp = slhc_init(16, 16);
- if (slcomp == NULL)
+ if (IS_ERR(slcomp))
goto err_exit;
#endif
spin_lock_bh(&sl->lock);
--
1.9.1

2015-11-12 23:18:50

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 003/155] [media] media/vivid-osd: fix info leak in ioctl

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

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

From: =?UTF-8?q?Salva=20Peir=C3=B3?= <[email protected]>

commit eda98796aff0d9bf41094b06811f5def3b4c333c upstream.

The vivid_fb_ioctl() code fails to initialize the 16 _reserved bytes of
struct fb_vblank after the ->hcount member. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Salva Peiró <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Reference: CVE-2015-7884
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/media/platform/vivid/vivid-osd.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/vivid/vivid-osd.c b/drivers/media/platform/vivid/vivid-osd.c
index 084d346..e15eef6 100644
--- a/drivers/media/platform/vivid/vivid-osd.c
+++ b/drivers/media/platform/vivid/vivid-osd.c
@@ -85,6 +85,7 @@ static int vivid_fb_ioctl(struct fb_info *info, unsigned cmd, unsigned long arg)
case FBIOGET_VBLANK: {
struct fb_vblank vblank;

+ memset(&vblank, 0, sizeof(vblank));
vblank.flags = FB_VBLANK_HAVE_COUNT | FB_VBLANK_HAVE_VCOUNT |
FB_VBLANK_HAVE_VSYNC;
vblank.count = 0;
--
1.9.1

2015-11-13 00:12:11

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 004/155] staging/dgnc: fix info leak in ioctl

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

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

From: =?UTF-8?q?Salva=20Peir=C3=B3?= <[email protected]>

commit 4b6184336ebb5c8dc1eae7f7ab46ee608a748b05 upstream.

The dgnc_mgmt_ioctl() code fails to initialize the 16 _reserved bytes of
struct digi_dinfo after the ->dinfo_nboards member. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Salva Peiró <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Reference: CVE-2015-7885
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/staging/dgnc/dgnc_mgmt.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index 5544a8e..78a8767 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -133,6 +133,7 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, unsigned long arg)

spin_lock_irqsave(&dgnc_global_lock, flags);

+ memset(&ddi, 0, sizeof(ddi));
ddi.dinfo_nboards = dgnc_NumBoards;
sprintf(ddi.dinfo_version, "%s", DG_PART);

--
1.9.1

2015-11-13 00:11:00

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 005/155] tools lib traceevent: Fix string handling in heterogeneous arch environments

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

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

From: Kapileshwar Singh <[email protected]>

commit c2e4b24ff848bb180f9b9cd873a38327cd219ad2 upstream.

When a trace recorded on a 32-bit device is processed with a 64-bit
binary, the higher 32-bits of the address need to ignored.

The lack of this results in the output of the 64-bit pointer
value to the trace as the 32-bit address lookup fails in find_printk().

Before:

burn-1778 [003] 548.600305: bputs: 0xc0046db2s: 2cec5c058d98c

After:

burn-1778 [003] 548.600305: bputs: 0xc0046db2s: RT throttling activated

The problem occurs in PRINT_FIELD when the field is recognized as a
pointer to a string (of the type const char *)

Heterogeneous architectures cases below can arise and should be handled:

* Traces recorded using 32-bit addresses processed on a 64-bit machine
* Traces recorded using 64-bit addresses processed on a 32-bit machine

Reported-by: Juri Lelli <[email protected]>
Signed-off-by: Kapileshwar Singh <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Javi Merino <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
tools/lib/traceevent/event-parse.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index cf3a44b..dfb8be7 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3658,7 +3658,7 @@ static void print_str_arg(struct trace_seq *s, void *data, int size,
struct format_field *field;
struct printk_map *printk;
unsigned long long val, fval;
- unsigned long addr;
+ unsigned long long addr;
char *str;
unsigned char *hex;
int print;
@@ -3691,13 +3691,30 @@ static void print_str_arg(struct trace_seq *s, void *data, int size,
*/
if (!(field->flags & FIELD_IS_ARRAY) &&
field->size == pevent->long_size) {
- addr = *(unsigned long *)(data + field->offset);
+
+ /* Handle heterogeneous recording and processing
+ * architectures
+ *
+ * CASE I:
+ * Traces recorded on 32-bit devices (32-bit
+ * addressing) and processed on 64-bit devices:
+ * In this case, only 32 bits should be read.
+ *
+ * CASE II:
+ * Traces recorded on 64 bit devices and processed
+ * on 32-bit devices:
+ * In this case, 64 bits must be read.
+ */
+ addr = (pevent->long_size == 8) ?
+ *(unsigned long long *)(data + field->offset) :
+ (unsigned long long)*(unsigned int *)(data + field->offset);
+
/* Check if it matches a print format */
printk = find_printk(pevent, addr);
if (printk)
trace_seq_puts(s, printk->printk);
else
- trace_seq_printf(s, "%lx", addr);
+ trace_seq_printf(s, "%llx", addr);
break;
}
str = malloc(len + 1);
--
1.9.1

2015-11-13 00:12:08

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 006/155] perf tools: Fix copying of /proc/kcore

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

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

From: Adrian Hunter <[email protected]>

commit b5cabbcbd157a4bf5a92dfc85134999a3b55342d upstream.

A copy of /proc/kcore containing the kernel text can be made to the
buildid cache. e.g.

perf buildid-cache -v -k /proc/kcore

To workaround objdump limitations, a copy is also made when annotating
against /proc/kcore.

The copying process stops working from libelf about v1.62 onwards (the
problem was found with v1.63).

The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails
because additional validation has been added to gelf_getphdr().

The use of gelf_getphdr() is a misguided attempt to get default
initialization of the Gelf_Phdr structure. That should not be
necessary because every member of the Gelf_Phdr structure is
subsequently assigned. So just remove the call to gelf_getphdr().

Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be
removed also.

Committer notes:

Note to [email protected], from Adrian in the cover letter for this
patchkit:

The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think
it is important enough for stable.

Signed-off-by: Adrian Hunter <[email protected]>
Cc: Jiri Olsa <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
tools/perf/util/symbol-elf.c | 35 +++++++++++++----------------------
1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index eafee11..944ccc6 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -1220,8 +1220,6 @@ out_close:
static int kcore__init(struct kcore *kcore, char *filename, int elfclass,
bool temp)
{
- GElf_Ehdr *ehdr;
-
kcore->elfclass = elfclass;

if (temp)
@@ -1238,9 +1236,7 @@ static int kcore__init(struct kcore *kcore, char *filename, int elfclass,
if (!gelf_newehdr(kcore->elf, elfclass))
goto out_end;

- ehdr = gelf_getehdr(kcore->elf, &kcore->ehdr);
- if (!ehdr)
- goto out_end;
+ memset(&kcore->ehdr, 0, sizeof(GElf_Ehdr));

return 0;

@@ -1297,23 +1293,18 @@ static int kcore__copy_hdr(struct kcore *from, struct kcore *to, size_t count)
static int kcore__add_phdr(struct kcore *kcore, int idx, off_t offset,
u64 addr, u64 len)
{
- GElf_Phdr gphdr;
- GElf_Phdr *phdr;
-
- phdr = gelf_getphdr(kcore->elf, idx, &gphdr);
- if (!phdr)
- return -1;
-
- phdr->p_type = PT_LOAD;
- phdr->p_flags = PF_R | PF_W | PF_X;
- phdr->p_offset = offset;
- phdr->p_vaddr = addr;
- phdr->p_paddr = 0;
- phdr->p_filesz = len;
- phdr->p_memsz = len;
- phdr->p_align = page_size;
-
- if (!gelf_update_phdr(kcore->elf, idx, phdr))
+ GElf_Phdr phdr = {
+ .p_type = PT_LOAD,
+ .p_flags = PF_R | PF_W | PF_X,
+ .p_offset = offset,
+ .p_vaddr = addr,
+ .p_paddr = 0,
+ .p_filesz = len,
+ .p_memsz = len,
+ .p_align = page_size,
+ };
+
+ if (!gelf_update_phdr(kcore->elf, idx, &phdr))
return -1;

return 0;
--
1.9.1

2015-11-12 23:18:48

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 007/155] m68k: Define asmlinkage_protect

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

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

From: Andreas Schwab <[email protected]>

commit 8474ba74193d302e8340dddd1e16c85cc4b98caf upstream.

Make sure the compiler does not modify arguments of syscall functions.
This can happen if the compiler generates a tailcall to another
function. For example, without asmlinkage_protect sys_openat is compiled
into this function:

sys_openat:
clr.l %d0
move.w 18(%sp),%d0
move.l %d0,16(%sp)
jbra do_sys_open

Note how the fourth argument is modified in place, modifying the register
%d4 that gets restored from this stack slot when the function returns to
user-space. The caller may expect the register to be unmodified across
system calls.

Signed-off-by: Andreas Schwab <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/m68k/include/asm/linkage.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)

diff --git a/arch/m68k/include/asm/linkage.h b/arch/m68k/include/asm/linkage.h
index 5a822bb..066e74f 100644
--- a/arch/m68k/include/asm/linkage.h
+++ b/arch/m68k/include/asm/linkage.h
@@ -4,4 +4,34 @@
#define __ALIGN .align 4
#define __ALIGN_STR ".align 4"

+/*
+ * Make sure the compiler doesn't do anything stupid with the
+ * arguments on the stack - they are owned by the *caller*, not
+ * the callee. This just fools gcc into not spilling into them,
+ * and keeps it from doing tailcall recursion and/or using the
+ * stack slots for temporaries, since they are live and "used"
+ * all the way to the end of the function.
+ */
+#define asmlinkage_protect(n, ret, args...) \
+ __asmlinkage_protect##n(ret, ##args)
+#define __asmlinkage_protect_n(ret, args...) \
+ __asm__ __volatile__ ("" : "=r" (ret) : "0" (ret), ##args)
+#define __asmlinkage_protect0(ret) \
+ __asmlinkage_protect_n(ret)
+#define __asmlinkage_protect1(ret, arg1) \
+ __asmlinkage_protect_n(ret, "m" (arg1))
+#define __asmlinkage_protect2(ret, arg1, arg2) \
+ __asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2))
+#define __asmlinkage_protect3(ret, arg1, arg2, arg3) \
+ __asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3))
+#define __asmlinkage_protect4(ret, arg1, arg2, arg3, arg4) \
+ __asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3), \
+ "m" (arg4))
+#define __asmlinkage_protect5(ret, arg1, arg2, arg3, arg4, arg5) \
+ __asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3), \
+ "m" (arg4), "m" (arg5))
+#define __asmlinkage_protect6(ret, arg1, arg2, arg3, arg4, arg5, arg6) \
+ __asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3), \
+ "m" (arg4), "m" (arg5), "m" (arg6))
+
#endif
--
1.9.1

2015-11-12 23:18:51

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 008/155] UBI: Validate data_size

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

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

From: Richard Weinberger <[email protected]>

commit 281fda27673f833a01d516658a64d22a32c8e072 upstream.

Make sure that data_size is less than LEB size.
Otherwise a handcrafted UBI image is able to trigger
an out of bounds memory access in ubi_compare_lebs().

Signed-off-by: Richard Weinberger <[email protected]>
Reviewed-by: David Gstir <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/mtd/ubi/io.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index 396aaa5..ce33030 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -923,6 +923,11 @@ static int validate_vid_hdr(const struct ubi_device *ubi,
goto bad;
}

+ if (data_size > ubi->leb_size) {
+ ubi_err(ubi, "bad data_size");
+ goto bad;
+ }
+
if (vol_type == UBI_VID_STATIC) {
/*
* Although from high-level point of view static volumes may
--
1.9.1

2015-11-13 00:09:50

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 009/155] UBI: return ENOSPC if no enough space available

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

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

From: shengyong <[email protected]>

commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 upstream.

UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI error: init_volumes: not enough PEBs, required 706, available 686
UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
UBI error: ubi_init: cannot attach mtd1

If available PEBs are not enough when initializing volumes, return -ENOSPC
directly. If available PEBs are not enough when initializing WL, return
-ENOSPC instead of -ENOMEM.

Signed-off-by: Sheng Yong <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
Reviewed-by: David Gstir <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/mtd/ubi/vtbl.c | 1 +
drivers/mtd/ubi/wl.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index f8fc308..3a1a368 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ -646,6 +646,7 @@ static int init_volumes(struct ubi_device *ubi,
if (ubi->corr_peb_count)
ubi_err(ubi, "%d PEBs are corrupted and not used",
ubi->corr_peb_count);
+ return -ENOSPC;
}
ubi->rsvd_pebs += reserved_pebs;
ubi->avail_pebs -= reserved_pebs;
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 4e07f81..7e3a141 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1990,6 +1990,7 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
if (ubi->corr_peb_count)
ubi_err(ubi, "%d PEBs are corrupted and not used",
ubi->corr_peb_count);
+ err = -ENOSPC;
goto out_free;
}
ubi->avail_pebs -= reserved_pebs;
--
1.9.1

2015-11-13 00:11:03

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 010/155] drm/radeon: Restore LCD backlight level on resume (>= R5xx)

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

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

From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <[email protected]>

commit 4281f46ef839050d2ef60348f661eb463c21cc2e upstream.

Instead of only enabling the backlight (which seems to set it to max
brightness), just re-set the current backlight level, which also takes
care of enabling the backlight if necessary.

Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop,
the radeon_atom_encoder_dpms_avivo part is only compile tested.

Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/atombios_encoders.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index b8cd797..d8a5db2 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1586,8 +1586,9 @@ radeon_atom_encoder_dpms_avivo(struct drm_encoder *encoder, int mode)
} else
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
- args.ucAction = ATOM_LCD_BLON;
- atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
+ struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+
+ atombios_set_backlight_level(radeon_encoder, dig->backlight_level);
}
break;
case DRM_MODE_DPMS_STANDBY:
@@ -1668,8 +1669,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
}
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
- atombios_dig_transmitter_setup(encoder,
- ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
+ atombios_set_backlight_level(radeon_encoder, dig->backlight_level);
if (ext_encoder)
atombios_external_encoder_setup(encoder, ext_encoder, ATOM_ENABLE);
break;
--
1.9.1

2015-11-13 00:10:59

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 011/155] drm/radeon: move bl encoder assignment into bl init

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

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

From: Alex Deucher <[email protected]>

commit 4cee6a9057d5e13911f0cb6e143d11dc1a3245dd upstream.

So that the bl encoder will be null if the GPU does not
control the backlight.

Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/atombios_encoders.c | 1 +
drivers/gpu/drm/radeon/radeon_encoders.c | 1 -
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 +
3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index d8a5db2..d538ebb 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -236,6 +236,7 @@ void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
backlight_update_status(bd);

DRM_INFO("radeon atom DIG backlight initialized\n");
+ rdev->mode_info.bl_encoder = radeon_encoder;

return;

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index 3a29703..62f1b1c 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -194,7 +194,6 @@ static void radeon_encoder_add_backlight(struct radeon_encoder *radeon_encoder,
radeon_atom_backlight_init(radeon_encoder, connector);
else
radeon_legacy_backlight_init(radeon_encoder, connector);
- rdev->mode_info.bl_encoder = radeon_encoder;
}
}

diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index c89971d..25ee916 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -441,6 +441,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
backlight_update_status(bd);

DRM_INFO("radeon legacy LVDS backlight initialized\n");
+ rdev->mode_info.bl_encoder = radeon_encoder;

return;

--
1.9.1

2015-11-13 00:09:52

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 012/155] drm/radeon: fix dpms when driver backlight control is disabled

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

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

From: Alex Deucher <[email protected]>

commit ae93580ee59c02395c1711d3e6b90546b8137b86 upstream.

If driver backlight control is disabled, either by driver
parameter or default per-asic setting, revert to the old behavior.

Fixes a regression in commit:
4281f46ef839050d2ef60348f661eb463c21cc2e

Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/atombios_encoders.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index d538ebb..1cceeb1 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1587,9 +1587,14 @@ radeon_atom_encoder_dpms_avivo(struct drm_encoder *encoder, int mode)
} else
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
- struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+ if (rdev->mode_info.bl_encoder) {
+ struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;

- atombios_set_backlight_level(radeon_encoder, dig->backlight_level);
+ atombios_set_backlight_level(radeon_encoder, dig->backlight_level);
+ } else {
+ args.ucAction = ATOM_LCD_BLON;
+ atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args);
+ }
}
break;
case DRM_MODE_DPMS_STANDBY:
@@ -1669,8 +1674,13 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
if (ASIC_IS_DCE4(rdev))
atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
}
- if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
- atombios_set_backlight_level(radeon_encoder, dig->backlight_level);
+ if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
+ if (rdev->mode_info.bl_encoder)
+ atombios_set_backlight_level(radeon_encoder, dig->backlight_level);
+ else
+ atombios_dig_transmitter_setup(encoder,
+ ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
+ }
if (ext_encoder)
atombios_external_encoder_setup(encoder, ext_encoder, ATOM_ENABLE);
break;
--
1.9.1

2015-11-13 00:08:58

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 013/155] MIPS: dma-default: Fix 32-bit fall back to GFP_DMA

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

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

From: James Hogan <[email protected]>

commit 53960059d56ecef67d4ddd546731623641a3d2d1 upstream.

If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
will cause DMA memory allocated for devices with a 32..63-bit
coherent_dma_mask to fall back to using __GFP_DMA, even though there may
only be 32-bits of physical address available anyway.

Correct that case to compare against a mask the size of phys_addr_t
instead of always using a 64-bit mask.

Signed-off-by: James Hogan <[email protected]>
Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
Cc: Ralf Baechle <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/9610/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/mips/mm/dma-default.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index af5f046..d5096a5 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -100,7 +100,7 @@ static gfp_t massage_gfp_flags(const struct device *dev, gfp_t gfp)
else
#endif
#if defined(CONFIG_ZONE_DMA) && !defined(CONFIG_ZONE_DMA32)
- if (dev->coherent_dma_mask < DMA_BIT_MASK(64))
+ if (dev->coherent_dma_mask < DMA_BIT_MASK(sizeof(phys_addr_t) * 8))
dma_flag = __GFP_DMA;
else
#endif
--
1.9.1

2015-11-13 00:08:56

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 014/155] MIPS: CPS: Stop dangling delay slot from has_mt.

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

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

From: Paul Burton <[email protected]>

commit 1e5fb282f8eda889776ee83f9214d5df9edaa26d upstream.

The has_mt macro ended with a branch, leaving its callers with a delay
slot that would be executed if Config3.MT is not set. However it would
not be executed if Config3 (or earlier Config registers) don't exist
which makes it somewhat inconsistent at best. Fill the delay slot in the
macro & fix the mips_cps_boot_vpes caller appropriately.

Signed-off-by: Paul Burton <[email protected]>
Cc: Markos Chandras <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/10865/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/mips/kernel/cps-vec.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/kernel/cps-vec.S b/arch/mips/kernel/cps-vec.S
index 55b759a..24b8c0b6 100644
--- a/arch/mips/kernel/cps-vec.S
+++ b/arch/mips/kernel/cps-vec.S
@@ -39,6 +39,7 @@
mfc0 \dest, CP0_CONFIG, 3
andi \dest, \dest, MIPS_CONF3_MT
beqz \dest, \nomt
+ nop
.endm

.section .text.cps-vec
@@ -226,7 +227,6 @@ LEAF(mips_cps_core_init)
#ifdef CONFIG_MIPS_MT
/* Check that the core implements the MT ASE */
has_mt t0, 3f
- nop

.set push
.set mips32r2
@@ -310,8 +310,8 @@ LEAF(mips_cps_boot_vpes)
addu t0, t0, t1

/* Calculate this VPEs ID. If the core doesn't support MT use 0 */
+ li t9, 0
has_mt t6, 1f
- li t9, 0

/* Find the number of VPEs present in the core */
mfc0 t1, CP0_MVPCONF0
--
1.9.1

2015-11-13 00:08:55

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 015/155] MIPS: CPS: Don't include MT code in non-MT kernels.

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

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

From: Paul Burton <[email protected]>

commit a5b0f6db0e6cf6224e50f6585e9c8f0c2d38a8f8 upstream.

The MT-specific code in mips_cps_boot_vpes can safely be omitted from
kernels which don't support MT, with the default VPE==0 case being used
as it would be after the has_mt (Config3.MT) check failed at runtime.
Discarding the code entirely will save us a few bytes & allow cleaner
handling of MT ASE instructions by later patches.

Signed-off-by: Paul Burton <[email protected]>
Cc: Markos Chandras <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/10866/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/mips/kernel/cps-vec.S | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/mips/kernel/cps-vec.S b/arch/mips/kernel/cps-vec.S
index 24b8c0b6..d729a5e 100644
--- a/arch/mips/kernel/cps-vec.S
+++ b/arch/mips/kernel/cps-vec.S
@@ -311,6 +311,7 @@ LEAF(mips_cps_boot_vpes)

/* Calculate this VPEs ID. If the core doesn't support MT use 0 */
li t9, 0
+#ifdef CONFIG_MIPS_MT
has_mt t6, 1f

/* Find the number of VPEs present in the core */
@@ -330,6 +331,7 @@ LEAF(mips_cps_boot_vpes)
/* Retrieve the VPE ID from EBase.CPUNum */
mfc0 t9, $15, 1
and t9, t9, t1
+#endif

1: /* Calculate a pointer to this VPEs struct vpe_boot_config */
li t1, VPEBOOTCFG_SIZE
--
1.9.1

2015-11-13 00:08:31

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 016/155] MIPS: CPS: #ifdef on CONFIG_MIPS_MT_SMP rather than CONFIG_MIPS_MT

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

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

From: Paul Burton <[email protected]>

commit 7a63076d9a31a6c2073da45021eeb4f89d2a8b56 upstream.

The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in
addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot
vector if we're using MT for SMP. Thus switch the config symbol we ifdef
against to CONFIG_MIPS_MT_SMP.

Signed-off-by: Paul Burton <[email protected]>
Cc: Markos Chandras <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/10867/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/mips/kernel/cps-vec.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/mips/kernel/cps-vec.S b/arch/mips/kernel/cps-vec.S
index d729a5e..b38a518 100644
--- a/arch/mips/kernel/cps-vec.S
+++ b/arch/mips/kernel/cps-vec.S
@@ -224,7 +224,7 @@ LEAF(excep_ejtag)
END(excep_ejtag)

LEAF(mips_cps_core_init)
-#ifdef CONFIG_MIPS_MT
+#ifdef CONFIG_MIPS_MT_SMP
/* Check that the core implements the MT ASE */
has_mt t0, 3f

@@ -311,7 +311,7 @@ LEAF(mips_cps_boot_vpes)

/* Calculate this VPEs ID. If the core doesn't support MT use 0 */
li t9, 0
-#ifdef CONFIG_MIPS_MT
+#ifdef CONFIG_MIPS_MT_SMP
has_mt t6, 1f

/* Find the number of VPEs present in the core */
@@ -339,7 +339,7 @@ LEAF(mips_cps_boot_vpes)
lw t7, COREBOOTCFG_VPECONFIG(t0)
addu v0, v0, t7

-#ifdef CONFIG_MIPS_MT
+#ifdef CONFIG_MIPS_MT_SMP

/* If the core doesn't support MT then return */
bnez t6, 1f
@@ -453,7 +453,7 @@ LEAF(mips_cps_boot_vpes)

2: .set pop

-#endif /* CONFIG_MIPS_MT */
+#endif /* CONFIG_MIPS_MT_SMP */

/* Return */
jr ra
--
1.9.1

2015-11-13 00:08:05

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 017/155] Initialize msg/shm IPC objects before doing ipc_addid()

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

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

From: Linus Torvalds <[email protected]>

commit b9a532277938798b53178d5a66af6e2915cb27cf upstream.

As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before
having initialized the IPC object state. Yes, we initialize the IPC
object in a locked state, but with all the lockless RCU lookup work,
that IPC object lock no longer means that the state cannot be seen.

We already did this for the IPC semaphore code (see commit e8577d1f0329:
"ipc/sem.c: fully initialize sem_array before making it visible") but we
clearly forgot about msg and shm.

Reported-by: Dmitry Vyukov <[email protected]>
Cc: Manfred Spraul <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
ipc/msg.c | 14 +++++++-------
ipc/shm.c | 13 +++++++------
ipc/util.c | 8 ++++----
3 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/ipc/msg.c b/ipc/msg.c
index a7261d5..1b8f36f 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -137,13 +137,6 @@ static int newque(struct ipc_namespace *ns, struct ipc_params *params)
return retval;
}

- /* ipc_addid() locks msq upon success. */
- id = ipc_addid(&msg_ids(ns), &msq->q_perm, ns->msg_ctlmni);
- if (id < 0) {
- ipc_rcu_putref(msq, msg_rcu_free);
- return id;
- }
-
msq->q_stime = msq->q_rtime = 0;
msq->q_ctime = get_seconds();
msq->q_cbytes = msq->q_qnum = 0;
@@ -153,6 +146,13 @@ static int newque(struct ipc_namespace *ns, struct ipc_params *params)
INIT_LIST_HEAD(&msq->q_receivers);
INIT_LIST_HEAD(&msq->q_senders);

+ /* ipc_addid() locks msq upon success. */
+ id = ipc_addid(&msg_ids(ns), &msq->q_perm, ns->msg_ctlmni);
+ if (id < 0) {
+ ipc_rcu_putref(msq, msg_rcu_free);
+ return id;
+ }
+
ipc_unlock_object(&msq->q_perm);
rcu_read_unlock();

diff --git a/ipc/shm.c b/ipc/shm.c
index 19633b4..dd5f686 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -550,12 +550,6 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
if (IS_ERR(file))
goto no_file;

- id = ipc_addid(&shm_ids(ns), &shp->shm_perm, ns->shm_ctlmni);
- if (id < 0) {
- error = id;
- goto no_id;
- }
-
shp->shm_cprid = task_tgid_vnr(current);
shp->shm_lprid = 0;
shp->shm_atim = shp->shm_dtim = 0;
@@ -564,6 +558,13 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
shp->shm_nattch = 0;
shp->shm_file = file;
shp->shm_creator = current;
+
+ id = ipc_addid(&shm_ids(ns), &shp->shm_perm, ns->shm_ctlmni);
+ if (id < 0) {
+ error = id;
+ goto no_id;
+ }
+
list_add(&shp->shm_clist, &current->sysvshm.shm_clist);

/*
diff --git a/ipc/util.c b/ipc/util.c
index 106bed0..372dd6ec 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -237,6 +237,10 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int size)
rcu_read_lock();
spin_lock(&new->lock);

+ current_euid_egid(&euid, &egid);
+ new->cuid = new->uid = euid;
+ new->gid = new->cgid = egid;
+
id = idr_alloc(&ids->ipcs_idr, new,
(next_id < 0) ? 0 : ipcid_to_idx(next_id), 0,
GFP_NOWAIT);
@@ -249,10 +253,6 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int size)

ids->in_use++;

- current_euid_egid(&euid, &egid);
- new->cuid = new->uid = euid;
- new->gid = new->cgid = egid;
-
if (next_id < 0) {
new->seq = ids->seq++;
if (ids->seq > IPCID_SEQ_MAX)
--
1.9.1

2015-11-12 23:58:47

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 018/155] x86/asm/entry: Create and use a 'TOP_OF_KERNEL_STACK_PADDING' macro

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

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

From: Andy Lutomirski <[email protected]>

commit 3ee4298f440c81638cbb5ec06f2497fb7a9a9eb4 upstream.

x86_32, unlike x86_64, pads the top of the kernel stack, because the
hardware stack frame formats are variable in size.

Document this padding and give it a name.

This should make no change whatsoever to the compiled kernel
image. It also doesn't fix any of the current bugs in this area.

Signed-off-by: Andy Lutomirski <[email protected]>
Acked-by: Denys Vlasenko <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/02bf2f54b8dcb76a62a142b6dfe07d4ef7fc582e.1426009661.git.luto@amacapital.net
[ Fixed small details, such as a missed magic constant in entry_32.S pointed out by Denys Vlasenko. ]
Signed-off-by: Ingo Molnar <[email protected]>
[ kamal: 3.19-stable prereq for
eddd382 x86/process: Add proper bound checks in 64bit get_wchan() ]
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/include/asm/processor.h | 3 ++-
arch/x86/include/asm/thread_info.h | 27 +++++++++++++++++++++++++++
arch/x86/kernel/entry_32.S | 2 +-
3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index a092a0c..401a988 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -886,7 +886,8 @@ extern unsigned long thread_saved_pc(struct task_struct *tsk);
#define task_pt_regs(task) \
({ \
struct pt_regs *__regs__; \
- __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task))-8); \
+ __regs__ = (struct pt_regs *)(KSTK_TOP(task_stack_page(task)) - \
+ TOP_OF_KERNEL_STACK_PADDING); \
__regs__ - 1; \
})

diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index 547e344..c4d9694 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -13,6 +13,33 @@
#include <asm/types.h>

/*
+ * TOP_OF_KERNEL_STACK_PADDING is a number of unused bytes that we
+ * reserve at the top of the kernel stack. We do it because of a nasty
+ * 32-bit corner case. On x86_32, the hardware stack frame is
+ * variable-length. Except for vm86 mode, struct pt_regs assumes a
+ * maximum-length frame. If we enter from CPL 0, the top 8 bytes of
+ * pt_regs don't actually exist. Ordinarily this doesn't matter, but it
+ * does in at least one case:
+ *
+ * If we take an NMI early enough in SYSENTER, then we can end up with
+ * pt_regs that extends above sp0. On the way out, in the espfix code,
+ * we can read the saved SS value, but that value will be above sp0.
+ * Without this offset, that can result in a page fault. (We are
+ * careful that, in this case, the value we read doesn't matter.)
+ *
+ * In vm86 mode, the hardware frame is much longer still, but we neither
+ * access the extra members from NMI context, nor do we write such a
+ * frame at sp0 at all.
+ *
+ * x86_64 has a fixed-length stack frame.
+ */
+#ifdef CONFIG_X86_32
+# define TOP_OF_KERNEL_STACK_PADDING 8
+#else
+# define TOP_OF_KERNEL_STACK_PADDING 0
+#endif
+
+/*
* low level task data that entry.S needs immediate access to
* - this struct should fit entirely inside of one cache line
* - this struct shares the supervisor stack pages
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 000d419..3890e21 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -398,7 +398,7 @@ sysenter_past_esp:
* A tiny bit of offset fixup is necessary - 4*4 means the 4 words
* pushed above; +8 corresponds to copy_thread's esp0 setting.
*/
- pushl_cfi ((TI_sysenter_return)-THREAD_SIZE+8+4*4)(%esp)
+ pushl_cfi ((TI_sysenter_return)-THREAD_SIZE+TOP_OF_KERNEL_STACK_PADDING+4*4)(%esp)
CFI_REL_OFFSET eip, 0

pushl_cfi %eax
--
1.9.1

2015-11-12 23:59:41

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 019/155] x86/process: Add proper bound checks in 64bit get_wchan()

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

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

From: Thomas Gleixner <[email protected]>

commit eddd3826a1a0190e5235703d1e666affa4d13b96 upstream.

Dmitry Vyukov reported the following using trinity and the memory
error detector AddressSanitizer
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).

[ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on
address ffff88002e280000
[ 124.576801] ffff88002e280000 is located 131938492886538 bytes to
the left of 28857600-byte region [ffffffff81282e0a, ffffffff82e0830a)
[ 124.578633] Accessed by thread T10915:
[ 124.579295] inlined in describe_heap_address
./arch/x86/mm/asan/report.c:164
[ 124.579295] #0 ffffffff810dd277 in asan_report_error
./arch/x86/mm/asan/report.c:278
[ 124.580137] #1 ffffffff810dc6a0 in asan_check_region
./arch/x86/mm/asan/asan.c:37
[ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0
[ 124.581893] #3 ffffffff8107c093 in get_wchan
./arch/x86/kernel/process_64.c:444

The address checks in the 64bit implementation of get_wchan() are
wrong in several ways:

- The lower bound of the stack is not the start of the stack
page. It's the start of the stack page plus sizeof (struct
thread_info)

- The upper bound must be:

top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long).

The 2 * sizeof(unsigned long) is required because the stack pointer
points at the frame pointer. The layout on the stack is: ... IP FP
... IP FP. So we need to make sure that both IP and FP are in the
bounds.

Fix the bound checks and get rid of the mix of numeric constants, u64
and unsigned long. Making all unsigned long allows us to use the same
function for 32bit as well.

Use READ_ONCE() when accessing the stack. This does not prevent a
concurrent wakeup of the task and the stack changing, but at least it
avoids TOCTOU.

Also check task state at the end of the loop. Again that does not
prevent concurrent changes, but it avoids walking for nothing.

Add proper comments while at it.

Reported-by: Dmitry Vyukov <[email protected]>
Reported-by: Sasha Levin <[email protected]>
Based-on-patch-from: Wolfram Gloger <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Reviewed-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Andrey Konovalov <[email protected]>
Cc: Kostya Serebryany <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: kasan-dev <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Wolfram Gloger <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/kernel/process_64.c | 52 +++++++++++++++++++++++++++++++++++---------
1 file changed, 42 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index ec03938..1165b05 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -476,27 +476,59 @@ void set_personality_ia32(bool x32)
}
EXPORT_SYMBOL_GPL(set_personality_ia32);

+/*
+ * Called from fs/proc with a reference on @p to find the function
+ * which called into schedule(). This needs to be done carefully
+ * because the task might wake up and we might look at a stack
+ * changing under us.
+ */
unsigned long get_wchan(struct task_struct *p)
{
- unsigned long stack;
- u64 fp, ip;
+ unsigned long start, bottom, top, sp, fp, ip;
int count = 0;

if (!p || p == current || p->state == TASK_RUNNING)
return 0;
- stack = (unsigned long)task_stack_page(p);
- if (p->thread.sp < stack || p->thread.sp >= stack+THREAD_SIZE)
+
+ start = (unsigned long)task_stack_page(p);
+ if (!start)
+ return 0;
+
+ /*
+ * Layout of the stack page:
+ *
+ * ----------- topmax = start + THREAD_SIZE - sizeof(unsigned long)
+ * PADDING
+ * ----------- top = topmax - TOP_OF_KERNEL_STACK_PADDING
+ * stack
+ * ----------- bottom = start + sizeof(thread_info)
+ * thread_info
+ * ----------- start
+ *
+ * The tasks stack pointer points at the location where the
+ * framepointer is stored. The data on the stack is:
+ * ... IP FP ... IP FP
+ *
+ * We need to read FP and IP, so we need to adjust the upper
+ * bound by another unsigned long.
+ */
+ top = start + THREAD_SIZE - TOP_OF_KERNEL_STACK_PADDING;
+ top -= 2 * sizeof(unsigned long);
+ bottom = start + sizeof(struct thread_info);
+
+ sp = READ_ONCE(p->thread.sp);
+ if (sp < bottom || sp > top)
return 0;
- fp = *(u64 *)(p->thread.sp);
+
+ fp = READ_ONCE(*(unsigned long *)sp);
do {
- if (fp < (unsigned long)stack ||
- fp >= (unsigned long)stack+THREAD_SIZE)
+ if (fp < bottom || fp > top)
return 0;
- ip = *(u64 *)(fp+8);
+ ip = READ_ONCE(*(unsigned long *)(fp + sizeof(unsigned long)));
if (!in_sched_functions(ip))
return ip;
- fp = *(u64 *)fp;
- } while (count++ < 16);
+ fp = READ_ONCE(*(unsigned long *)fp);
+ } while (count++ < 16 && p->state != TASK_RUNNING);
return 0;
}

--
1.9.1

2015-11-12 23:18:52

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 020/155] drm/qxl: recreate the primary surface when the bo is not primary

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

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

From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= <[email protected]>

commit 8d0d94015e96b8853c4f7f06eac3f269e1b3d866 upstream.

When disabling/enabling a crtc the primary area must be updated
independently of which crtc has been disabled/enabled.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735

Signed-off-by: Fabiano Fidêncio <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index 42b3dbb..52921a8 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -618,7 +618,7 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
adjusted_mode->hdisplay,
adjusted_mode->vdisplay);

- if (qcrtc->index == 0)
+ if (bo->is_primary == false)
recreate_primary = true;

if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
--
1.9.1

2015-11-12 23:18:58

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 021/155] genirq: Fix race in register_irq_proc()

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

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

From: Ben Hutchings <[email protected]>

commit 95c2b17534654829db428f11bcf4297c059a2a7e upstream.

Per-IRQ directories in procfs are created only when a handler is first
added to the irqdesc, not when the irqdesc is created. In the case of
a shared IRQ, multiple tasks can race to create a directory. This
race condition seems to have been present forever, but is easier to
hit with async probing.

Signed-off-by: Ben Hutchings <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
kernel/irq/proc.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 9dc9bfd..9791f93 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -12,6 +12,7 @@
#include <linux/seq_file.h>
#include <linux/interrupt.h>
#include <linux/kernel_stat.h>
+#include <linux/mutex.h>

#include "internals.h"

@@ -326,18 +327,29 @@ void register_handler_proc(unsigned int irq, struct irqaction *action)

void register_irq_proc(unsigned int irq, struct irq_desc *desc)
{
+ static DEFINE_MUTEX(register_lock);
char name [MAX_NAMELEN];

- if (!root_irq_dir || (desc->irq_data.chip == &no_irq_chip) || desc->dir)
+ if (!root_irq_dir || (desc->irq_data.chip == &no_irq_chip))
return;

+ /*
+ * irq directories are registered only when a handler is
+ * added, not when the descriptor is created, so multiple
+ * tasks might try to register at the same time.
+ */
+ mutex_lock(&register_lock);
+
+ if (desc->dir)
+ goto out_unlock;
+
memset(name, 0, MAX_NAMELEN);
sprintf(name, "%d", irq);

/* create /proc/irq/1234 */
desc->dir = proc_mkdir(name, root_irq_dir);
if (!desc->dir)
- return;
+ goto out_unlock;

#ifdef CONFIG_SMP
/* create /proc/irq/<irq>/smp_affinity */
@@ -358,6 +370,9 @@ void register_irq_proc(unsigned int irq, struct irq_desc *desc)

proc_create_data("spurious", 0444, desc->dir,
&irq_spurious_proc_fops, (void *)(long)irq);
+
+out_unlock:
+ mutex_unlock(&register_lock);
}

void unregister_irq_proc(unsigned int irq, struct irq_desc *desc)
--
1.9.1

2015-11-12 23:33:58

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 022/155] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down

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

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

From: Matt Fleming <[email protected]>

commit a5caa209ba9c29c6421292e7879d2387a2ef39c9 upstream.

Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
that signals that the firmware PE/COFF loader supports splitting
code and data sections of PE/COFF images into separate EFI
memory map entries. This allows the kernel to map those regions
with strict memory protections, e.g. EFI_MEMORY_RO for code,
EFI_MEMORY_XP for data, etc.

Unfortunately, an unwritten requirement of this new feature is
that the regions need to be mapped with the same offsets
relative to each other as observed in the EFI memory map. If
this is not done crashes like this may occur,

BUG: unable to handle kernel paging request at fffffffefe6086dd
IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
Call Trace:
[<ffffffff8104c90e>] efi_call+0x7e/0x100
[<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef

Here 0xfffffffefe6086dd refers to an address the firmware
expects to be mapped but which the OS never claimed was mapped.
The issue is that included in these regions are relative
addresses to other regions which were emitted by the firmware
toolchain before the "splitting" of sections occurred at
runtime.

Needless to say, we don't satisfy this unwritten requirement on
x86_64 and instead map the EFI memory map entries in reverse
order. The above crash is almost certainly triggerable with any
kernel newer than v3.13 because that's when we rewrote the EFI
runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping"). For kernel versions before
v3.13 things may work by pure luck depending on the
fragmentation of the kernel virtual address space at the time we
map the EFI regions.

Instead of mapping the EFI memory map entries in reverse order,
where entry N has a higher virtual address than entry N+1, map
them in the same order as they appear in the EFI memory map to
preserve this relative offset between regions.

This patch has been kept as small as possible with the intention
that it should be applied aggressively to stable and
distribution kernels. It is very much a bugfix rather than
support for a new feature, since when EFI_PROPERTIES_TABLE is
enabled we must map things as outlined above to even boot - we
have no way of asking the firmware not to split the code/data
regions.

In fact, this patch doesn't even make use of the more strict
memory protections available in UEFI v2.5. That will come later.

Suggested-by: Ard Biesheuvel <[email protected]>
Reported-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Chun-Yi <[email protected]>
Cc: Dave Young <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: James Bottomley <[email protected]>
Cc: Lee, Chun-Yi <[email protected]>
Cc: Leif Lindholm <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Jones <[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: Kamal Mostafa <[email protected]>
---
arch/x86/platform/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index e752f79..c61bdec 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -670,6 +670,70 @@ out:
}

/*
+ * Iterate the EFI memory map in reverse order because the regions
+ * will be mapped top-down. The end result is the same as if we had
+ * mapped things forward, but doesn't require us to change the
+ * existing implementation of efi_map_region().
+ */
+static inline void *efi_map_next_entry_reverse(void *entry)
+{
+ /* Initial call */
+ if (!entry)
+ return memmap.map_end - memmap.desc_size;
+
+ entry -= memmap.desc_size;
+ if (entry < memmap.map)
+ return NULL;
+
+ return entry;
+}
+
+/*
+ * efi_map_next_entry - Return the next EFI memory map descriptor
+ * @entry: Previous EFI memory map descriptor
+ *
+ * This is a helper function to iterate over the EFI memory map, which
+ * we do in different orders depending on the current configuration.
+ *
+ * To begin traversing the memory map @entry must be %NULL.
+ *
+ * Returns %NULL when we reach the end of the memory map.
+ */
+static void *efi_map_next_entry(void *entry)
+{
+ if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
+ /*
+ * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
+ * config table feature requires us to map all entries
+ * in the same order as they appear in the EFI memory
+ * map. That is to say, entry N must have a lower
+ * virtual address than entry N+1. This is because the
+ * firmware toolchain leaves relative references in
+ * the code/data sections, which are split and become
+ * separate EFI memory regions. Mapping things
+ * out-of-order leads to the firmware accessing
+ * unmapped addresses.
+ *
+ * Since we need to map things this way whether or not
+ * the kernel actually makes use of
+ * EFI_PROPERTIES_TABLE, let's just switch to this
+ * scheme by default for 64-bit.
+ */
+ return efi_map_next_entry_reverse(entry);
+ }
+
+ /* Initial call */
+ if (!entry)
+ return memmap.map;
+
+ entry += memmap.desc_size;
+ if (entry >= memmap.map_end)
+ return NULL;
+
+ return entry;
+}
+
+/*
* Map the efi memory ranges of the runtime services and update new_mmap with
* virtual addresses.
*/
@@ -679,7 +743,8 @@ static void * __init efi_map_regions(int *count, int *pg_shift)
unsigned long left = 0;
efi_memory_desc_t *md;

- for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+ p = NULL;
+ while ((p = efi_map_next_entry(p))) {
md = p;
if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
#ifdef CONFIG_X86_64
--
1.9.1

2015-11-12 23:18:56

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 023/155] KVM: nSVM: Check for NRIPS support before updating control field

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

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

From: Bandan Das <[email protected]>

commit f104765b4f81fd74d69e0eb161e89096deade2db upstream.

If hardware doesn't support DecodeAssist - a feature that provides
more information about the intercept in the VMCB, KVM decodes the
instruction and then updates the next_rip vmcb control field.
However, NRIP support itself depends on cpuid Fn8000_000A_EDX[NRIPS].
Since skip_emulated_instruction() doesn't verify nrip support
before accepting control.next_rip as valid, avoid writing this
field if support isn't present.

Signed-off-by: Bandan Das <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/kvm/svm.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 67f8457..dd68f32 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -511,8 +511,10 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);

- if (svm->vmcb->control.next_rip != 0)
+ if (svm->vmcb->control.next_rip != 0) {
+ WARN_ON(!static_cpu_has(X86_FEATURE_NRIPS));
svm->next_rip = svm->vmcb->control.next_rip;
+ }

if (!svm->next_rip) {
if (emulate_instruction(vcpu, EMULTYPE_SKIP) !=
@@ -4315,7 +4317,9 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu,
break;
}

- vmcb->control.next_rip = info->next_rip;
+ /* TODO: Advertise NRIPS to guest hypervisor unconditionally */
+ if (static_cpu_has(X86_FEATURE_NRIPS))
+ vmcb->control.next_rip = info->next_rip;
vmcb->control.exit_code = icpt_info.exit_code;
vmexit = nested_svm_exit_handled(svm);

--
1.9.1

2015-11-13 00:05:52

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 024/155] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

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

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

From: =?UTF-8?q?Dirk=20M=C3=BCller?= <[email protected]>

commit d2922422c48df93f3edff7d872ee4f3191fefb08 upstream.

The cpu feature flags are not ever going to change, so warning
everytime can cause a lot of kernel log spam
(in our case more than 10GB/hour).

The warning seems to only occur when nested virtualization is
enabled, so it's probably triggered by a KVM bug. This is a
sensible and safe change anyway, and the KVM bug fix might not
be suitable for stable releases anyway.

Signed-off-by: Dirk Mueller <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index dd68f32..fe5d87e 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -512,7 +512,7 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
struct vcpu_svm *svm = to_svm(vcpu);

if (svm->vmcb->control.next_rip != 0) {
- WARN_ON(!static_cpu_has(X86_FEATURE_NRIPS));
+ WARN_ON_ONCE(!static_cpu_has(X86_FEATURE_NRIPS));
svm->next_rip = svm->vmcb->control.next_rip;
}

--
1.9.1

2015-11-12 23:19:01

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 025/155] mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault

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

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

From: Mel Gorman <[email protected]>

commit 2f84a8990ebbe235c59716896e017c6b2ca1200f upstream.

SunDong reported the following on

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

I think I find a linux bug, I have the test cases is constructed. I
can stable recurring problems in fedora22(4.0.4) kernel version,
arch for x86_64. I construct transparent huge page, when the parent
and child process with MAP_SHARE, MAP_PRIVATE way to access the same
huge page area, it has the opportunity to lead to huge page copy on
write failure, and then it will munmap the child corresponding mmap
area, but then the child mmap area with VM_MAYSHARE attributes, child
process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
functions (vma - > vm_flags & VM_MAYSHARE).

There were a number of problems with the report (e.g. it's hugetlbfs that
triggers this, not transparent huge pages) but it was fundamentally
correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
looks like this

vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
prot 8000000000000027 anon_vma (null) vm_ops ffffffff8182a7a0
pgoff 0 file ffff88106bdb9800 private_data (null)
flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
------------
kernel BUG at mm/hugetlb.c:462!
SMP
Modules linked in: xt_pkttype xt_LOG xt_limit [..]
CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
set_vma_resv_flags+0x2d/0x30

The VM_BUG_ON is correct because private and shared mappings have
different reservation accounting but the warning clearly shows that the
VMA is shared.

When a private COW fails to allocate a new page then only the process
that created the VMA gets the page -- all the children unmap the page.
If the children access that data in the future then they get killed.

The problem is that the same file is mapped shared and private. During
the COW, the allocation fails, the VMAs are traversed to unmap the other
private pages but a shared VMA is found and the bug is triggered. This
patch identifies such VMAs and skips them.

Signed-off-by: Mel Gorman <[email protected]>
Reported-by: SunDong <[email protected]>
Reviewed-by: Michal Hocko <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Naoya Horiguchi <[email protected]>
Cc: David Rientjes <[email protected]>
Reviewed-by: Naoya Horiguchi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
mm/hugetlb.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2870d90..cf17e90 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2788,6 +2788,14 @@ static void unmap_ref_private(struct mm_struct *mm, struct vm_area_struct *vma,
continue;

/*
+ * Shared VMAs have their own reserves and do not affect
+ * MAP_PRIVATE accounting but it is possible that a shared
+ * VMA is using the same page so check and skip such VMAs.
+ */
+ if (iter_vma->vm_flags & VM_MAYSHARE)
+ continue;
+
+ /*
* Unmap the page from other VMAs without their own reserves.
* They get marked to be SIGKILLed if they fault in these
* areas. This is because a future no-page fault on this VMA
--
1.9.1

2015-11-13 00:07:13

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 026/155] drm/dp/mst: fixup handling hotplug on port removal.

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

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

From: Dave Airlie <[email protected]>

commit df4839fdc9b3c922586b945f062f38cbbda022bb upstream.

output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.

In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.

In the case were we add the port to the destroy
list we need to send a hotplug if we destroy
any connectors, so userspace knows to reprobe
stuff.

this patch also handles port->connector allocation
failing which should be a rare event, but makes
the code consistent.

Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++++++++++++++++++++++++----------
1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6c0a1b0..ce40117 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -859,29 +859,33 @@ static void drm_dp_destroy_port(struct kref *kref)
{
struct drm_dp_mst_port *port = container_of(kref, struct drm_dp_mst_port, kref);
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
+
if (!port->input) {
port->vcpi.num_slots = 0;

kfree(port->cached_edid);

- /* we can't destroy the connector here, as
- we might be holding the mode_config.mutex
- from an EDID retrieval */
+ /*
+ * The only time we don't have a connector
+ * on an output port is if the connector init
+ * fails.
+ */
if (port->connector) {
+ /* we can't destroy the connector here, as
+ * we might be holding the mode_config.mutex
+ * from an EDID retrieval */
+
mutex_lock(&mgr->destroy_connector_lock);
list_add(&port->next, &mgr->destroy_connector_list);
mutex_unlock(&mgr->destroy_connector_lock);
schedule_work(&mgr->destroy_connector_work);
return;
}
+ /* no need to clean up vcpi
+ * as if we have no connector we never setup a vcpi */
drm_dp_port_teardown_pdt(port, port->pdt);
-
- if (!port->input && port->vcpi.vcpi > 0)
- drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
}
kfree(port);
-
- (*mgr->cbs->hotplug)(mgr);
}

static void drm_dp_put_port(struct drm_dp_mst_port *port)
@@ -1111,12 +1115,21 @@ static void drm_dp_add_port(struct drm_dp_mst_branch *mstb,
char proppath[255];
build_mst_prop_path(port, mstb, proppath, sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr, port, proppath);
-
+ if (!port->connector) {
+ /* remove it from the port list */
+ mutex_lock(&mstb->mgr->lock);
+ list_del(&port->next);
+ mutex_unlock(&mstb->mgr->lock);
+ /* drop port list reference */
+ drm_dp_put_port(port);
+ goto out;
+ }
if (port->port_num >= 8) {
port->cached_edid = drm_get_edid(port->connector, &port->aux.ddc);
}
}

+out:
/* put reference to this port */
drm_dp_put_port(port);
}
@@ -2643,7 +2656,7 @@ static void drm_dp_destroy_connector_work(struct work_struct *work)
{
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct drm_dp_mst_topology_mgr, destroy_connector_work);
struct drm_dp_mst_port *port;
-
+ bool send_hotplug = false;
/*
* Not a regular list traverse as we have to drop the destroy
* connector lock before destroying the connector, to avoid AB->BA
@@ -2666,7 +2679,10 @@ static void drm_dp_destroy_connector_work(struct work_struct *work)
if (!port->input && port->vcpi.vcpi > 0)
drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
kfree(port);
+ send_hotplug = true;
}
+ if (send_hotplug)
+ (*mgr->cbs->hotplug)(mgr);
}

/**
--
1.9.1

2015-11-13 00:05:53

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 027/155] drm/dp/mst: drop cancel work sync in the mstb destroy path (v2)

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

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

From: Dave Airlie <[email protected]>

commit 274d83524895fe41ca8debae4eec60ede7252bb5 upstream.

Since 9eb1e57f564d4e6e10991402726cc83fe0b9172f
drm/dp/mst: make sure mst_primary mstb is valid in work function

we validate the mstb structs in the work function, and doing
that takes a reference. So we should never get here with the
work function running using the mstb device, only if the work
function hasn't run yet or is running for another mstb.

So we don't need to sync the work here, this was causing
lockdep spew as below.

[ +0.000160] =============================================
[ +0.000001] [ INFO: possible recursive locking detected ]
[ +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G W ------------
[ +0.000001] ---------------------------------------------
[ +0.000001] kworker/4:2/1262 is trying to acquire lock:
[ +0.000001] ((&mgr->work)){+.+.+.}, at: [<ffffffff810b29a5>] flush_work+0x5/0x2e0
[ +0.000007]
but task is already holding lock:
[ +0.000001] ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[ +0.000004]
other info that might help us debug this:
[ +0.000001] Possible unsafe locking scenario:

[ +0.000002] CPU0
[ +0.000000] ----
[ +0.000001] lock((&mgr->work));
[ +0.000002] lock((&mgr->work));
[ +0.000001]
*** DEADLOCK ***

[ +0.000001] May be due to missing lock nesting notation

[ +0.000002] 2 locks held by kworker/4:2/1262:
[ +0.000001] #0: (events_long){.+.+.+}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[ +0.000004] #1: ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[ +0.000003]
stack backtrace:
[ +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G W ------------ 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1
[ +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015
[ +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
[ +0.000001] ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d
[ +0.000004] ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003
[ +0.000002] ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00
[ +0.000003] Call Trace:
[ +0.000004] [<ffffffff816fe04d>] dump_stack+0x19/0x1b
[ +0.000004] [<ffffffff8110f47f>] __lock_acquire+0x115f/0x1250
[ +0.000002] [<ffffffff8110fd49>] lock_acquire+0x99/0x1e0
[ +0.000002] [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
[ +0.000002] [<ffffffff810b29ee>] flush_work+0x4e/0x2e0
[ +0.000002] [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
[ +0.000004] [<ffffffff81025905>] ? native_sched_clock+0x35/0x80
[ +0.000002] [<ffffffff81025959>] ? sched_clock+0x9/0x10
[ +0.000002] [<ffffffff810da1f5>] ? local_clock+0x25/0x30
[ +0.000002] [<ffffffff8110dca9>] ? mark_held_locks+0xb9/0x140
[ +0.000003] [<ffffffff810b4ed5>] ? __cancel_work_timer+0x95/0x160
[ +0.000002] [<ffffffff810b4ee8>] __cancel_work_timer+0xa8/0x160
[ +0.000002] [<ffffffff810b4fb0>] cancel_work_sync+0x10/0x20
[ +0.000007] [<ffffffffa0160d17>] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper]
[ +0.000006] [<ffffffffa0163968>] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper]
[ +0.000002] [<ffffffff810b5850>] process_one_work+0x220/0x710
[ +0.000002] [<ffffffff810b57e4>] ? process_one_work+0x1b4/0x710
[ +0.000005] [<ffffffff810b5e5b>] worker_thread+0x11b/0x3a0
[ +0.000003] [<ffffffff810b5d40>] ? process_one_work+0x710/0x710
[ +0.000002] [<ffffffff810beced>] kthread+0xed/0x100
[ +0.000003] [<ffffffff810bec00>] ? insert_kthread_work+0x80/0x80
[ +0.000003] [<ffffffff817121d8>] ret_from_fork+0x58/0x90

v2: add flush_work.

Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index ce40117..d7ee25a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -800,8 +800,6 @@ static void drm_dp_destroy_mst_branch_device(struct kref *kref)
struct drm_dp_mst_port *port, *tmp;
bool wake_tx = false;

- cancel_work_sync(&mstb->mgr->work);
-
/*
* destroy all ports - don't need lock
* as there are no more references to the mst branch
@@ -1986,6 +1984,8 @@ void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr)
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
DP_MST_EN | DP_UPSTREAM_IS_SRC);
mutex_unlock(&mgr->lock);
+ flush_work(&mgr->work);
+ flush_work(&mgr->destroy_connector_work);
}
EXPORT_SYMBOL(drm_dp_mst_topology_mgr_suspend);

@@ -2735,6 +2735,7 @@ EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
*/
void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr)
{
+ flush_work(&mgr->work);
flush_work(&mgr->destroy_connector_work);
mutex_lock(&mgr->payload_lock);
kfree(mgr->payloads);
--
1.9.1

2015-11-12 23:49:48

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 028/155] x86/kexec: Fix kexec crash in syscall kexec_file_load()

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

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

From: "Lee, Chun-Yi" <[email protected]>

commit e3c41e37b0f4b18cbd4dac76cbeece5a7558b909 upstream.

The original bug is a page fault crash that sometimes happens
on big machines when preparing ELF headers:

BUG: unable to handle kernel paging request at ffffc90613fc9000
IP: [<ffffffff8103d645>] prepare_elf64_ram_headers_callback+0x165/0x260

The bug is caused by us under-counting the number of memory ranges
and subsequently not allocating enough ELF header space for them.
The bug is typically masked on smaller systems, because the ELF header
allocation is rounded up to the next page.

This patch modifies the code in fill_up_crash_elf_data() by using
walk_system_ram_res() instead of walk_system_ram_range() to correctly
count the max number of crash memory ranges. That's because the
walk_system_ram_range() filters out small memory regions that
reside in the same page, but walk_system_ram_res() does not.

Here's how I found the bug:

After tracing prepare_elf64_headers() and prepare_elf64_ram_headers_callback(),
the code uses walk_system_ram_res() to fill-in crash memory regions information
to the program header, so it counts those small memory regions that
reside in a page area.

But, when the kernel was using walk_system_ram_range() in
fill_up_crash_elf_data() to count the number of crash memory regions,
it filters out small regions.

I printed those small memory regions, for example:

kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0

Based on the code in walk_system_ram_range(), this memory region
will be filtered out:

pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) is FALSE

So, the max_nr_ranges that's counted by the kernel doesn't include
small memory regions - causing us to under-allocate the required space.
That causes the page fault crash that happens in a later code path
when preparing ELF headers.

This bug is not easy to reproduce on small machines that have few
CPUs, because the allocated page aligned ELF buffer has more free
space to cover those small memory regions' PT_LOAD headers.

Signed-off-by: Lee, Chun-Yi <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Jiang Liu <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: Vivek Goyal <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/kernel/crash.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index aceb2f9..58a47b5 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -184,10 +184,9 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
}

#ifdef CONFIG_KEXEC_FILE
-static int get_nr_ram_ranges_callback(unsigned long start_pfn,
- unsigned long nr_pfn, void *arg)
+static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
{
- int *nr_ranges = arg;
+ unsigned int *nr_ranges = arg;

(*nr_ranges)++;
return 0;
@@ -213,7 +212,7 @@ static void fill_up_crash_elf_data(struct crash_elf_data *ced,

ced->image = image;

- walk_system_ram_range(0, -1, &nr_ranges,
+ walk_system_ram_res(0, -1, &nr_ranges,
get_nr_ram_ranges_callback);

ced->max_nr_ranges = nr_ranges;
--
1.9.1

2015-11-12 23:19:07

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 029/155] x86/mm: Set NX on gap between __ex_table and rodata

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

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

From: Stephen Smalley <[email protected]>

commit ab76f7b4ab2397ffdd2f1eb07c55697d19991d10 upstream.

Unused space between the end of __ex_table and the start of
rodata can be left W+x in the kernel page tables. Extend the
setting of the NX bit to cover this gap by starting from
text_end rather than rodata_start.

Before:
---[ High Kernel Mapping ]---
0xffffffff80000000-0xffffffff81000000 16M pmd
0xffffffff81000000-0xffffffff81600000 6M ro PSE GLB x pmd
0xffffffff81600000-0xffffffff81754000 1360K ro GLB x pte
0xffffffff81754000-0xffffffff81800000 688K RW GLB x pte
0xffffffff81800000-0xffffffff81a00000 2M ro PSE GLB NX pmd
0xffffffff81a00000-0xffffffff81b3b000 1260K ro GLB NX pte
0xffffffff81b3b000-0xffffffff82000000 4884K RW GLB NX pte
0xffffffff82000000-0xffffffff82200000 2M RW PSE GLB NX pmd
0xffffffff82200000-0xffffffffa0000000 478M pmd

After:
---[ High Kernel Mapping ]---
0xffffffff80000000-0xffffffff81000000 16M pmd
0xffffffff81000000-0xffffffff81600000 6M ro PSE GLB x pmd
0xffffffff81600000-0xffffffff81754000 1360K ro GLB x pte
0xffffffff81754000-0xffffffff81800000 688K RW GLB NX pte
0xffffffff81800000-0xffffffff81a00000 2M ro PSE GLB NX pmd
0xffffffff81a00000-0xffffffff81b3b000 1260K ro GLB NX pte
0xffffffff81b3b000-0xffffffff82000000 4884K RW GLB NX pte
0xffffffff82000000-0xffffffff82200000 2M RW PSE GLB NX pmd
0xffffffff82200000-0xffffffffa0000000 478M pmd

Signed-off-by: Stephen Smalley <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[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: Kamal Mostafa <[email protected]>
---
arch/x86/mm/init_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 30eb05a..9d6e27eb 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1146,7 +1146,7 @@ void mark_rodata_ro(void)
* has been zapped already via cleanup_highmem().
*/
all_end = roundup((unsigned long)_brk_end, PMD_SIZE);
- set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
+ set_memory_nx(text_end, (all_end - text_end) >> PAGE_SHIFT);

rodata_test();

--
1.9.1

2015-11-13 00:04:54

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 030/155] md/raid0: update queue parameter in a safer location.

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

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

From: NeilBrown <[email protected]>

commit 199dc6ed5179251fa6158a461499c24bdd99c836 upstream.

When a (e.g.) RAID5 array is reshaped to RAID0, the updating
of queue parameters (e.g. max number of sectors per bio) is
done in the wrong place.
It should be part of ->run, but it is actually part of ->takeover.
This means it happens before level_store() calls:

blk_set_stacking_limits(&mddev->queue->limits);

and so it ineffective. This can lead to errors from underlying
devices.

So move all the relevant settings out of create_stripe_zones()
and into raid0_run().

As this can lead to a bug-on it is suitable for any -stable
kernel which supports reshape to RAID0. So 2.6.35 or later.
As the bug has been present for five years there is no urgency,
so no need to rush into -stable.

Fixes: 9af204cf720c ("md: Add support for Raid5->Raid0 and Raid10->Raid0 takeover")
Reported-by: Yi Zhang <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
[ kamal: backport to 3.19-stable: context ]
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/raid0.c | 69 ++++++++++++++++++++++++++++++------------------------
1 file changed, 39 insertions(+), 30 deletions(-)

diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index b974ff2..910edd2 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -87,7 +87,7 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf)
char b[BDEVNAME_SIZE];
char b2[BDEVNAME_SIZE];
struct r0conf *conf = kzalloc(sizeof(*conf), GFP_KERNEL);
- bool discard_supported = false;
+ unsigned short blksize = 512;

if (!conf)
return -ENOMEM;
@@ -102,6 +102,9 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf)
sector_div(sectors, mddev->chunk_sectors);
rdev1->sectors = sectors * mddev->chunk_sectors;

+ blksize = max(blksize, queue_logical_block_size(
+ rdev1->bdev->bd_disk->queue));
+
rdev_for_each(rdev2, mddev) {
pr_debug("md/raid0:%s: comparing %s(%llu)"
" with %s(%llu)\n",
@@ -138,6 +141,18 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf)
}
pr_debug("md/raid0:%s: FINAL %d zones\n",
mdname(mddev), conf->nr_strip_zones);
+ /*
+ * now since we have the hard sector sizes, we can make sure
+ * chunk size is a multiple of that sector size
+ */
+ if ((mddev->chunk_sectors << 9) % blksize) {
+ printk(KERN_ERR "md/raid0:%s: chunk_size of %d not multiple of block size %d\n",
+ mdname(mddev),
+ mddev->chunk_sectors << 9, blksize);
+ err = -EINVAL;
+ goto abort;
+ }
+
err = -ENOMEM;
conf->strip_zone = kzalloc(sizeof(struct strip_zone)*
conf->nr_strip_zones, GFP_KERNEL);
@@ -192,18 +207,12 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf)
}
dev[j] = rdev1;

- disk_stack_limits(mddev->gendisk, rdev1->bdev,
- rdev1->data_offset << 9);
-
if (rdev1->bdev->bd_disk->queue->merge_bvec_fn)
conf->has_merge_bvec = 1;

if (!smallest || (rdev1->sectors < smallest->sectors))
smallest = rdev1;
cnt++;
-
- if (blk_queue_discard(bdev_get_queue(rdev1->bdev)))
- discard_supported = true;
}
if (cnt != mddev->raid_disks) {
printk(KERN_ERR "md/raid0:%s: too few disks (%d of %d) - "
@@ -266,26 +275,6 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf)
mddev->queue->backing_dev_info.congested_fn = raid0_congested;
mddev->queue->backing_dev_info.congested_data = mddev;

- /*
- * now since we have the hard sector sizes, we can make sure
- * chunk size is a multiple of that sector size
- */
- if ((mddev->chunk_sectors << 9) % queue_logical_block_size(mddev->queue)) {
- printk(KERN_ERR "md/raid0:%s: chunk_size of %d not valid\n",
- mdname(mddev),
- mddev->chunk_sectors << 9);
- goto abort;
- }
-
- blk_queue_io_min(mddev->queue, mddev->chunk_sectors << 9);
- blk_queue_io_opt(mddev->queue,
- (mddev->chunk_sectors << 9) * mddev->raid_disks);
-
- if (!discard_supported)
- queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
- else
- queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
-
pr_debug("md/raid0:%s: done.\n", mdname(mddev));
*private_conf = conf;

@@ -436,9 +425,6 @@ static int raid0_run(struct mddev *mddev)
}
if (md_check_no_bitmap(mddev))
return -EINVAL;
- blk_queue_max_hw_sectors(mddev->queue, mddev->chunk_sectors);
- blk_queue_max_write_same_sectors(mddev->queue, mddev->chunk_sectors);
- blk_queue_max_discard_sectors(mddev->queue, mddev->chunk_sectors);

/* if private is not null, we are here after takeover */
if (mddev->private == NULL) {
@@ -448,6 +434,29 @@ static int raid0_run(struct mddev *mddev)
mddev->private = conf;
}
conf = mddev->private;
+ if (mddev->queue) {
+ struct md_rdev *rdev;
+ bool discard_supported = false;
+
+ rdev_for_each(rdev, mddev) {
+ disk_stack_limits(mddev->gendisk, rdev->bdev,
+ rdev->data_offset << 9);
+ if (blk_queue_discard(bdev_get_queue(rdev->bdev)))
+ discard_supported = true;
+ }
+ blk_queue_max_hw_sectors(mddev->queue, mddev->chunk_sectors);
+ blk_queue_max_write_same_sectors(mddev->queue, mddev->chunk_sectors);
+ blk_queue_max_discard_sectors(mddev->queue, mddev->chunk_sectors);
+
+ blk_queue_io_min(mddev->queue, mddev->chunk_sectors << 9);
+ blk_queue_io_opt(mddev->queue,
+ (mddev->chunk_sectors << 9) * mddev->raid_disks);
+
+ if (!discard_supported)
+ queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
+ else
+ queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
+ }

/* calculate array device size */
md_set_array_sectors(mddev, raid0_size(mddev, 0, 0));
--
1.9.1

2015-11-13 00:04:53

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 031/155] md/raid0: apply base queue limits *before* disk_stack_limits

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

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

From: NeilBrown <[email protected]>

commit 66eefe5de11db1e0d8f2edc3880d50e7c36a9d43 upstream.

Calling e.g. blk_queue_max_hw_sectors() after calls to
disk_stack_limits() discards the settings determined by
disk_stack_limits().
So we need to make those calls first.

Fixes: 199dc6ed5179 ("md/raid0: update queue parameter in a safer location.")
Reported-by: Jes Sorensen <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/raid0.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index 910edd2..ff028ae 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -438,12 +438,6 @@ static int raid0_run(struct mddev *mddev)
struct md_rdev *rdev;
bool discard_supported = false;

- rdev_for_each(rdev, mddev) {
- disk_stack_limits(mddev->gendisk, rdev->bdev,
- rdev->data_offset << 9);
- if (blk_queue_discard(bdev_get_queue(rdev->bdev)))
- discard_supported = true;
- }
blk_queue_max_hw_sectors(mddev->queue, mddev->chunk_sectors);
blk_queue_max_write_same_sectors(mddev->queue, mddev->chunk_sectors);
blk_queue_max_discard_sectors(mddev->queue, mddev->chunk_sectors);
@@ -452,6 +446,12 @@ static int raid0_run(struct mddev *mddev)
blk_queue_io_opt(mddev->queue,
(mddev->chunk_sectors << 9) * mddev->raid_disks);

+ rdev_for_each(rdev, mddev) {
+ disk_stack_limits(mddev->gendisk, rdev->bdev,
+ rdev->data_offset << 9);
+ if (blk_queue_discard(bdev_get_queue(rdev->bdev)))
+ discard_supported = true;
+ }
if (!discard_supported)
queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
else
--
1.9.1

2015-11-13 00:04:33

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 032/155] arm64: ftrace: fix function_graph tracer panic

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

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

From: Li Bin <[email protected]>

commit ee556d00cf20012e889344a0adbbf809ab5015a3 upstream.

When function graph tracer is enabled, the following operation
will trigger panic:

mount -t debugfs nodev /sys/kernel
echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
echo function_graph > /sys/kernel/tracing/current_tracer
ls /proc/

------------[ cut here ]------------
[ 198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316
[ 198.506126] pgd = ffffffc008f79000
[ 198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000
[ 198.517726] Internal error: Oops: 94000005 [#1] SMP
[ 198.518798] Modules linked in:
[ 198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
[ 198.521800] Hardware name: linux,dummy-virt (DT)
[ 198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000
[ 198.524306] PC is at next_tgid+0x30/0x100
[ 198.525205] LR is at return_to_handler+0x0/0x20
[ 198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145
[ 198.527392] sp : ffffffc0f9ab3d40
[ 198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000
[ 198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8
[ 198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00
[ 198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002
[ 198.533202] x21: ffffffc000d85050 x20: 0000000000000002
[ 198.534446] x19: 0000000000000002 x18: 0000000000000000
[ 198.535719] x17: 000000000049fa08 x16: ffffffc000242efc
[ 198.537030] x15: 0000007fa472b54c x14: ffffffffff000000
[ 198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001
[ 198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70
[ 198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40
[ 198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015
[ 198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0
[ 198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
[ 198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050
[ 198.547432]
[ 198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020)
[ 198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000)
[ 198.582568] Call trace:
[ 198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
[ 198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[ 198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[ 198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[ 198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
[ 198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
[ 198.591092] ---[ end trace 6a346f8f20949ac8 ]---

This is because when using function graph tracer, if the traced
function return value is in multi regs ([x0-x7]), return_to_handler
may corrupt them. So in return_to_handler, the parameter regs should
be protected properly.

Signed-off-by: Li Bin <[email protected]>
Acked-by: AKASHI Takahiro <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm64/kernel/entry-ftrace.S | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 08cafc5..0f03a8f 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -178,6 +178,24 @@ ENTRY(ftrace_stub)
ENDPROC(ftrace_stub)

#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ /* save return value regs*/
+ .macro save_return_regs
+ sub sp, sp, #64
+ stp x0, x1, [sp]
+ stp x2, x3, [sp, #16]
+ stp x4, x5, [sp, #32]
+ stp x6, x7, [sp, #48]
+ .endm
+
+ /* restore return value regs*/
+ .macro restore_return_regs
+ ldp x0, x1, [sp]
+ ldp x2, x3, [sp, #16]
+ ldp x4, x5, [sp, #32]
+ ldp x6, x7, [sp, #48]
+ add sp, sp, #64
+ .endm
+
/*
* void ftrace_graph_caller(void)
*
@@ -204,11 +222,11 @@ ENDPROC(ftrace_graph_caller)
* only when CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST is enabled.
*/
ENTRY(return_to_handler)
- str x0, [sp, #-16]!
+ save_return_regs
mov x0, x29 // parent's fp
bl ftrace_return_to_handler// addr = ftrace_return_to_hander(fp);
mov x30, x0 // restore the original return address
- ldr x0, [sp], #16
+ restore_return_regs
ret
END(return_to_handler)
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
--
1.9.1

2015-11-13 00:01:38

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 033/155] clocksource: Fix abs() usage w/ 64bit values

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

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

From: John Stultz <[email protected]>

commit 67dfae0cd72fec5cd158b6e5fb1647b7dbe0834c upstream.

This patch fixes one cases where abs() was being used with 64-bit
nanosecond values, where the result may be capped at 32-bits.

This potentially could cause watchdog false negatives on 32-bit
systems, so this patch addresses the issue by using abs64().

Signed-off-by: John Stultz <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Richard Cochran <[email protected]>
Cc: Ingo Molnar <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
kernel/time/clocksource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index b79f39b..de800df 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -296,7 +296,7 @@ static void clocksource_watchdog(unsigned long data)
continue;

/* Check the deviation from the watchdog clocksource. */
- if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
+ if (abs64(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) {
clocksource_unstable(cs, cs_nsec - wd_nsec);
continue;
}
--
1.9.1

2015-11-13 00:03:11

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 034/155] dmaengine: dw: properly read DWC_PARAMS register

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

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

From: Andy Shevchenko <[email protected]>

commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf upstream.

In case we have less than maximum allowed channels (8) and autoconfiguration is
enabled the DWC_PARAMS read is wrong because it uses different arithmetic to
what is needed for channel priority setup.

Re-do the caclulations properly. This now works on AVR32 board well.

Fixes: fed2574b3c9f (dw_dmac: introduce software emulation of LLP transfers)
Cc: [email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/dma/dw/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 5c06254..de55fb8 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1582,7 +1582,6 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
INIT_LIST_HEAD(&dw->dma.channels);
for (i = 0; i < nr_channels; i++) {
struct dw_dma_chan *dwc = &dw->chan[i];
- int r = nr_channels - i - 1;

dwc->chan.device = &dw->dma;
dma_cookie_init(&dwc->chan);
@@ -1594,7 +1593,7 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)

/* 7 is highest priority & 0 is lowest. */
if (pdata->chan_priority == CHAN_PRIORITY_ASCENDING)
- dwc->priority = r;
+ dwc->priority = nr_channels - i - 1;
else
dwc->priority = i;

@@ -1613,6 +1612,7 @@ int dw_dma_probe(struct dw_dma_chip *chip, struct dw_dma_platform_data *pdata)
/* Hardware configuration */
if (autocfg) {
unsigned int dwc_params;
+ unsigned int r = DW_DMA_MAX_NR_CHANNELS - i - 1;
void __iomem *addr = chip->regs + r * sizeof(u32);

dwc_params = dma_read_byaddr(addr, DWC_PARAMS);
--
1.9.1

2015-11-13 00:00:46

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 035/155] mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1)

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

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

From: Joonsoo Kim <[email protected]>

commit 03a2d2a3eafe4015412cf4e9675ca0e2d9204074 upstream.

Commit description is copied from the original post of this bug:

http://comments.gmane.org/gmane.linux.kernel.mm/135349

Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next
larger cache size than the size index INDEX_NODE mapping. In kernels
3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.

However, sometimes we can't get the right output we expected via
kmalloc_size(INDEX_NODE + 1), causing a BUG().

The mapping table in the latest kernel is like:
index = {0, 1, 2 , 3, 4, 5, 6, n}
size = {0, 96, 192, 8, 16, 32, 64, 2^n}
The mapping table before 3.10 is like this:
index = {0 , 1 , 2, 3, 4 , 5 , 6, n}
size = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}

The problem on my mips64 machine is as follows:

(1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
&& DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
kmalloc_index(sizeof(struct kmem_cache_node))

(2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.

(3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
= PAGE_SIZE".

(4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
"flags |= CFLGS_OFF_SLAB" will be covered.

(5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
"cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
here may be NULL while kernel bootup.

(6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
BUG info as the following shows (may be only mips64 has this problem):

This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes
the BUG by adding 'size >= 256' check to guarantee that all necessary
small sized slabs are initialized regardless sequence of slab size in
mapping table.

Fixes: e33660165c90 ("slab: Use common kmalloc_index/kmalloc_size...")
Signed-off-by: Joonsoo Kim <[email protected]>
Reported-by: Liuhailong <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: David Rientjes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
mm/slab.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 65b5dcb..2aa29f3 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2175,9 +2175,16 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
- if (size >= kmalloc_size(INDEX_NODE + 1)
- && cachep->object_size > cache_line_size()
- && ALIGN(size, cachep->align) < PAGE_SIZE) {
+ /*
+ * To activate debug pagealloc, off-slab management is necessary
+ * requirement. In early phase of initialization, small sized slab
+ * doesn't get initialized so it would not be possible. So, we need
+ * to check size >= 256. It guarantees that all necessary small
+ * sized slab is initialized in current slab initialization sequence.
+ */
+ if (!slab_early_init && size >= kmalloc_size(INDEX_NODE) &&
+ size >= 256 && cachep->object_size > cache_line_size() &&
+ ALIGN(size, cachep->align) < PAGE_SIZE) {
cachep->obj_offset += PAGE_SIZE - ALIGN(size, cachep->align);
size = PAGE_SIZE;
}
--
1.9.1

2015-11-13 00:04:08

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 036/155] regmap: debugfs: Ensure we don't underflow when printing access masks

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

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

From: Mark Brown <[email protected]>

commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 upstream.

If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.

Reported-by: Rasmus Villemoes <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/base/regmap/regmap-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
index 5799a0b..1f6cd15 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -432,7 +432,7 @@ static ssize_t regmap_access_read_file(struct file *file,
/* If we're in the region the user is trying to read */
if (p >= *ppos) {
/* ...but not beyond it */
- if (buf_pos >= count - 1 - tot_len)
+ if (buf_pos + tot_len + 1 >= count)
break;

/* Format the register */
--
1.9.1

2015-11-13 00:03:48

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 037/155] regmap: debugfs: Don't bother actually printing when calculating max length

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

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

From: Mark Brown <[email protected]>

commit 176fc2d5770a0990eebff903ba680d2edd32e718 upstream.

The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.

Reported-by: Rasmus Villemoes <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/base/regmap/regmap-debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
index 1f6cd15..c8941f3 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -32,8 +32,7 @@ static DEFINE_MUTEX(regmap_debugfs_early_lock);
/* Calculate the length of a fixed format */
static size_t regmap_calc_reg_len(int max_val, char *buf, size_t buf_size)
{
- snprintf(buf, buf_size, "%x", max_val);
- return strlen(buf);
+ return snprintf(NULL, 0, "%x", max_val);
}

static ssize_t regmap_name_read_file(struct file *file,
--
1.9.1

2015-11-13 00:03:13

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 038/155] mtd: nand: sunxi: fix OOB handling in ->write_xxx() functions

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

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

From: Boris BREZILLON <[email protected]>

commit 03a0e8a7c5ea29b5c4e72dfd64900b47a8fb6f2d upstream.

The USER_DATA register cannot be accessed using byte accessors on A13
SoCs, thus triggering a bug when using memcpy_toio on this register.
Declare an helper macros to convert an OOB buffer into a suitable
USER_DATA value and vice-versa.

This patch also fixes an error in the oob_required logic (some OOB data
are not written even if the user required it) by removing the
oob_required condition, which is perfectly valid since the core already
fill ->oob_poi with FFs when oob_required is false.

Signed-off-by: Boris Brezillon <[email protected]>
Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Signed-off-by: Brian Norris <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/mtd/nand/sunxi_nand.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index ccaa8e2..d753659 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -138,6 +138,10 @@
#define NFC_ECC_MODE GENMASK(15, 12)
#define NFC_RANDOM_SEED GENMASK(30, 16)

+/* NFC_USER_DATA helper macros */
+#define NFC_BUF_TO_USER_DATA(buf) ((buf)[0] | ((buf)[1] << 8) | \
+ ((buf)[2] << 16) | ((buf)[3] << 24))
+
#define NFC_DEFAULT_TIMEOUT_MS 1000

#define NFC_SRAM_SIZE 1024
@@ -632,15 +636,9 @@ static int sunxi_nfc_hw_ecc_write_page(struct mtd_info *mtd,
offset = layout->eccpos[i * ecc->bytes] - 4 + mtd->writesize;

/* Fill OOB data in */
- if (oob_required) {
- tmp = 0xffffffff;
- memcpy_toio(nfc->regs + NFC_REG_USER_DATA_BASE, &tmp,
- 4);
- } else {
- memcpy_toio(nfc->regs + NFC_REG_USER_DATA_BASE,
- chip->oob_poi + offset - mtd->writesize,
- 4);
- }
+ writel(NFC_BUF_TO_USER_DATA(chip->oob_poi +
+ layout->oobfree[i].offset),
+ nfc->regs + NFC_REG_USER_DATA_BASE);

chip->cmdfunc(mtd, NAND_CMD_RNDIN, offset, -1);

@@ -770,14 +768,8 @@ static int sunxi_nfc_hw_syndrome_ecc_write_page(struct mtd_info *mtd,
offset += ecc->size;

/* Fill OOB data in */
- if (oob_required) {
- tmp = 0xffffffff;
- memcpy_toio(nfc->regs + NFC_REG_USER_DATA_BASE, &tmp,
- 4);
- } else {
- memcpy_toio(nfc->regs + NFC_REG_USER_DATA_BASE, oob,
- 4);
- }
+ writel(NFC_BUF_TO_USER_DATA(oob),
+ nfc->regs + NFC_REG_USER_DATA_BASE);

tmp = NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD | NFC_ACCESS_DIR |
(1 << 30);
--
1.9.1

2015-11-13 00:01:37

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 039/155] mtd: nand: sunxi: fix sunxi_nand_chips_cleanup()

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

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

From: Boris BREZILLON <[email protected]>

commit 8e375ccda31ccc73b087134e263c48d2114534f4 upstream.

The sunxi_nand_chips_cleanup() function is missing a call to list_del()
which generates a double free error.

Reported-by: Priit Laes <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Tested-by: Priit Laes <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/mtd/nand/sunxi_nand.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index d753659..fbb4c76 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1306,6 +1306,7 @@ static void sunxi_nand_chips_cleanup(struct sunxi_nfc *nfc)
node);
nand_release(&chip->mtd);
sunxi_nand_ecc_cleanup(&chip->nand.ecc);
+ list_del(&chip->node);
}
}

--
1.9.1

2015-11-13 00:01:36

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 040/155] ARM: dts: fix usb pin control for imx-rex dts

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

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

From: "Felipe F. Tonello" <[email protected]>

commit 0af822110871400908d5b6f83a8908c45f881d8f upstream.

This fixes a duplicated pin control causing this error:

imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
requested by regulators:regulator@2; cannot claim for 2184000.usb
imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
(MX6Q_PAD_GPIO_1) from group usbotggrp on device 20e0000.iomuxc
imx_usb 2184000.usb: Error applying setting, reverse things
back
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already
requested by regulators:regulator@1; cannot claim for 2184200.usb
imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
from group usbh1grp on device 20e0000.iomuxc
imx_usb 2184200.usb: Error applying setting, reverse things
back

Signed-off-by: Felipe F. Tonello <[email protected]>
Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support")
Signed-off-by: Shawn Guo <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm/boot/dts/imx6qdl-rex.dtsi | 2 --
1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-rex.dtsi b/arch/arm/boot/dts/imx6qdl-rex.dtsi
index 488a640..394a4ac 100644
--- a/arch/arm/boot/dts/imx6qdl-rex.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-rex.dtsi
@@ -35,7 +35,6 @@
compatible = "regulator-fixed";
reg = <1>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbh1>;
regulator-name = "usbh1_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
@@ -47,7 +46,6 @@
compatible = "regulator-fixed";
reg = <2>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbotg>;
regulator-name = "usb_otg_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
--
1.9.1

2015-11-13 00:01:34

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 041/155] ASoC: db1200: Fix DAI link format for db1300 and db1550

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

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

From: Lars-Peter Clausen <[email protected]>

commit e74679b38c9417c1c524081121cdcdb36f82264d upstream.

Commit b4508d0f95fa ("ASoC: db1200: Use static DAI format setup") switched
the db1200 driver over to using static DAI format setup instead of a
callback function. But the commit only added the dai_fmt field to one of
the three DAI links in the driver. This breaks audio on db1300 and db1550.

Add the two missing dai_fmt settings to fix the issue.

Fixes: b4508d0f95fa ("ASoC: db1200: Use static DAI format setup")
Reported-by: Manuel Lauss <[email protected]>
Tested-by: Manuel Lauss <[email protected]>
Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/soc/au1x/db1200.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/sound/soc/au1x/db1200.c b/sound/soc/au1x/db1200.c
index a747ac0..d9d95b5 100644
--- a/sound/soc/au1x/db1200.c
+++ b/sound/soc/au1x/db1200.c
@@ -142,6 +142,8 @@ static struct snd_soc_dai_link db1300_i2s_dai = {
.cpu_dai_name = "au1xpsc_i2s.2",
.platform_name = "au1xpsc-pcm.2",
.codec_name = "wm8731.0-001b",
+ .dai_fmt = SND_SOC_DAIFMT_LEFT_J | SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM,
.ops = &db1200_i2s_wm8731_ops,
};

@@ -159,6 +161,8 @@ static struct snd_soc_dai_link db1550_i2s_dai = {
.cpu_dai_name = "au1xpsc_i2s.3",
.platform_name = "au1xpsc-pcm.3",
.codec_name = "wm8731.0-001b",
+ .dai_fmt = SND_SOC_DAIFMT_LEFT_J | SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM,
.ops = &db1200_i2s_wm8731_ops,
};

--
1.9.1

2015-11-13 00:00:18

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 042/155] x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

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

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

From: Vitaly Kuznetsov <[email protected]>

commit 0b34a166f291d255755be46e43ed5497cdd194f2 upstream.

Currently there is a number of issues preventing PVHVM Xen guests from
doing successful kexec/kdump:

- Bound event channels.
- Registered vcpu_info.
- PIRQ/emuirq mappings.
- shared_info frame after XENMAPSPACE_shared_info operation.
- Active grant mappings.

Basically, newly booted kernel stumbles upon already set up Xen
interfaces and there is no way to reestablish them. In Xen-4.7 a new
feature called 'soft reset' is coming. A guest performing kexec/kdump
operation is supposed to call SCHEDOP_shutdown hypercall with
SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
(with some help from toolstack) will do full domain cleanup (but
keeping its memory and vCPU contexts intact) returning the guest to
the state it had when it was first booted and thus allowing it to
start over.

Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
probably OK as by default all unknown shutdown reasons cause domain
destroy with a message in toolstack log: 'Unknown shutdown reason code
5. Destroying domain.' which gives a clue to what the problem is and
eliminates false expectations.

Signed-off-by: Vitaly Kuznetsov <[email protected]>
Signed-off-by: David Vrabel <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/xen/enlighten.c | 23 +++++++++++++++++++++++
include/xen/interface/sched.h | 8 ++++++++
2 files changed, 31 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index f94ad30..2339a33 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,10 @@
#include <linux/memblock.h>
#include <linux/edd.h>

+#ifdef CONFIG_KEXEC_CORE
+#include <linux/kexec.h>
+#endif
+
#include <xen/xen.h>
#include <xen/events.h>
#include <xen/interface/xen.h>
@@ -1867,6 +1871,21 @@ static struct notifier_block xen_hvm_cpu_notifier = {
.notifier_call = xen_hvm_cpu_notify,
};

+#ifdef CONFIG_KEXEC_CORE
+static void xen_hvm_shutdown(void)
+{
+ native_machine_shutdown();
+ if (kexec_in_progress)
+ xen_reboot(SHUTDOWN_soft_reset);
+}
+
+static void xen_hvm_crash_shutdown(struct pt_regs *regs)
+{
+ native_machine_crash_shutdown(regs);
+ xen_reboot(SHUTDOWN_soft_reset);
+}
+#endif
+
static void __init xen_hvm_guest_init(void)
{
init_hvm_pv_info();
@@ -1883,6 +1902,10 @@ static void __init xen_hvm_guest_init(void)
x86_init.irqs.intr_init = xen_init_IRQ;
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
+#ifdef CONFIG_KEXEC_CORE
+ machine_ops.shutdown = xen_hvm_shutdown;
+ machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
+#endif
}

static bool xen_nopv = false;
diff --git a/include/xen/interface/sched.h b/include/xen/interface/sched.h
index 9ce0839..f184909 100644
--- a/include/xen/interface/sched.h
+++ b/include/xen/interface/sched.h
@@ -107,5 +107,13 @@ struct sched_watchdog {
#define SHUTDOWN_suspend 2 /* Clean up, save suspend info, kill. */
#define SHUTDOWN_crash 3 /* Tell controller we've crashed. */
#define SHUTDOWN_watchdog 4 /* Restart because watchdog time expired. */
+/*
+ * Domain asked to perform 'soft reset' for it. The expected behavior is to
+ * reset internal Xen state for the domain returning it to the point where it
+ * was created but leaving the domain's memory contents and vCPU contexts
+ * intact. This will allow the domain to start over and set up all Xen specific
+ * interfaces again.
+ */
+#define SHUTDOWN_soft_reset 5

#endif /* __XEN_PUBLIC_SCHED_H__ */
--
1.9.1

2015-11-13 00:00:47

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 043/155] x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

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

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

From: Malcolm Crossley <[email protected]>

commit 64c98e7f49100b637cd20a6c63508caed6bbba7a upstream.

Sanitizing the e820 map may produce extra E820 entries which would result in
the topmost E820 entries being removed. The removed entries would typically
include the top E820 usable RAM region and thus result in the domain having
signicantly less RAM available to it.

Fix by allowing sanitize_e820_map to use the full size of the allocated E820
array.

Signed-off-by: Malcolm Crossley <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Signed-off-by: David Vrabel <[email protected]>
[ kamal: backport to 3.19-stable: context ]
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/xen/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 865e56c..8b9240b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -621,7 +621,7 @@ char * __init xen_memory_setup(void)
xen_ignore_unusable(map, memmap.nr_entries);

/* Make sure the Xen-supplied memory map is well-ordered. */
- sanitize_e820_map(map, memmap.nr_entries, &memmap.nr_entries);
+ sanitize_e820_map(map, ARRAY_SIZE(map), &memmap.nr_entries);

max_pages = xen_get_max_pages();
if (max_pages > max_pfn)
--
1.9.1

2015-11-13 00:00:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 044/155] s390/boot/decompression: disable floating point in decompressor

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

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

From: Christian Borntraeger <[email protected]>

commit adc0b7fbf6fe9967505c0254d9535ec7288186ae upstream.

my gcc 5.1 used an ldgr instruction with a register != 0,2,4,6 for
spilling/filling into a floating point register in our decompressor.

This will cause an AFP-register data exception as the decompressor
did not setup the additional floating point registers via cr0.
That causes a program check loop that looked like a hang with
one "Uncompressing Linux... " message (directly booted via kvm)
or a loop of "Uncompressing Linux... " messages (when booted via
zipl boot loader).

The offending code in my build was

48e400: e3 c0 af ff ff 71 lay %r12,-1(%r10)
-->48e406: b3 c1 00 1c ldgr %f1,%r12
48e40a: ec 6c 01 22 02 7f clij %r6,2,12,0x48e64e

but gcc could do spilling into an fpr at any function. We can
simply disable floating point support at that early stage.

Signed-off-by: Christian Borntraeger <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/s390/boot/compressed/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/boot/compressed/Makefile b/arch/s390/boot/compressed/Makefile
index f90d1fc..f70b232 100644
--- a/arch/s390/boot/compressed/Makefile
+++ b/arch/s390/boot/compressed/Makefile
@@ -12,7 +12,7 @@ targets += misc.o piggy.o sizes.h head$(BITS).o

KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
-KBUILD_CFLAGS += $(cflags-y) -fno-delete-null-pointer-checks
+KBUILD_CFLAGS += $(cflags-y) -fno-delete-null-pointer-checks -msoft-float
KBUILD_CFLAGS += $(call cc-option,-mpacked-stack)
KBUILD_CFLAGS += $(call cc-option,-ffreestanding)

--
1.9.1

2015-11-12 23:59:40

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 045/155] svcrdma: handle rdma read with a non-zero initial page offset

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

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

From: Steve Wise <[email protected]>

commit c91aed9896946721bb30705ea2904edb3725dd61 upstream.

The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr() functions
were not taking into account the initial page_offset when determining
the rdma read length. This resulted in a read who's starting address
and length exceeded the base/bounds of the frmr.

The server gets an async error from the rdma device and kills the
connection, and the client then reconnects and resends. This repeats
indefinitely, and the application hangs.

Most work loads don't tickle this bug apparently, but one test hit it
every time: building the linux kernel on a 16 core node with 'make -j
16 O=/mnt/0' where /mnt/0 is a ramdisk mounted via NFSRDMA.

This bug seems to only be tripped with devices having small fastreg page
list depths. I didn't see it with mlx4, for instance.

Fixes: 0bf4828983df ('svcrdma: refactor marshalling logic')
Signed-off-by: Steve Wise <[email protected]>
Tested-by: Chuck Lever <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <[email protected]>

Signed-off-by: Kamal Mostafa <[email protected]>
---
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
index e011027..a9f8c0c 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
@@ -157,7 +157,8 @@ static int rdma_read_chunk_lcl(struct svcxprt_rdma *xprt,
ctxt->read_hdr = head;
pages_needed =
min_t(int, pages_needed, rdma_read_max_sge(xprt, pages_needed));
- read = min_t(int, pages_needed << PAGE_SHIFT, rs_length);
+ read = min_t(int, (pages_needed << PAGE_SHIFT) - *page_offset,
+ rs_length);

for (pno = 0; pno < pages_needed; pno++) {
int len = min_t(int, rs_length, PAGE_SIZE - pg_off);
@@ -256,7 +257,8 @@ static int rdma_read_chunk_frmr(struct svcxprt_rdma *xprt,
ctxt->direction = DMA_FROM_DEVICE;
ctxt->frmr = frmr;
pages_needed = min_t(int, pages_needed, xprt->sc_frmr_pg_list_len);
- read = min_t(int, pages_needed << PAGE_SHIFT, rs_length);
+ read = min_t(int, (pages_needed << PAGE_SHIFT) - *page_offset,
+ rs_length);

frmr->kva = page_address(rqstp->rq_arg.pages[pg_no]);
frmr->direction = DMA_FROM_DEVICE;
--
1.9.1

2015-11-12 23:19:21

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 046/155] ASoC: sgtl5000: fix wrong register MIC_BIAS_VOLTAGE setup on probe

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

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

From: Gianluca Renzi <[email protected]>

commit e256da84a04ea31c3c215997c847609af224e8f4 upstream.

Signed-off-by: Gianluca Renzi <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/soc/codecs/sgtl5000.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 10d2415..d91790e 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1337,8 +1337,8 @@ static int sgtl5000_probe(struct snd_soc_codec *codec)
sgtl5000->micbias_resistor << SGTL5000_BIAS_R_SHIFT);

snd_soc_update_bits(codec, SGTL5000_CHIP_MIC_CTRL,
- SGTL5000_BIAS_R_MASK,
- sgtl5000->micbias_voltage << SGTL5000_BIAS_R_SHIFT);
+ SGTL5000_BIAS_VOLT_MASK,
+ sgtl5000->micbias_voltage << SGTL5000_BIAS_VOLT_SHIFT);
/*
* disable DAP
* TODO:
--
1.9.1

2015-11-12 23:19:27

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 047/155] dm: fix AB-BA deadlock in __dm_destroy()

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

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

From: Junichi Nomura <[email protected]>

commit 2a708cff93f1845b9239bc7d6310aef54e716c6a upstream.

__dm_destroy() takes io_barrier SRCU lock (dm_get_live_table) and
suspend_lock in reverse order. Doing so can cause AB-BA deadlock:

__dm_destroy dm_swap_table
---------------------------------------------------
mutex_lock(suspend_lock)
dm_get_live_table()
srcu_read_lock(io_barrier)
dm_sync_table()
synchronize_srcu(io_barrier)
.. waiting for dm_put_live_table()
mutex_lock(suspend_lock)
.. waiting for suspend_lock

Fix this by taking the locks in proper order.

Signed-off-by: Jun'ichi Nomura <[email protected]>
Fixes: ab7c7bb6f4ab ("dm: hold suspend_lock while suspending device during device deletion")
Acked-by: Mikulas Patocka <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 82fe47d..bda831f 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2544,14 +2544,14 @@ static void __dm_destroy(struct mapped_device *md, bool wait)
* do not race with internal suspend.
*/
mutex_lock(&md->suspend_lock);
+ map = dm_get_live_table(md, &srcu_idx);
if (!dm_suspended_md(md)) {
dm_table_presuspend_targets(map);
dm_table_postsuspend_targets(map);
}
- mutex_unlock(&md->suspend_lock);
-
/* dm_put_live_table must be before msleep, otherwise deadlock is possible */
dm_put_live_table(md, srcu_idx);
+ mutex_unlock(&md->suspend_lock);

/*
* Rare, but there may be I/O requests still going to complete,
--
1.9.1

2015-11-12 23:58:46

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 048/155] [SMB3] Do not fall back to SMBWriteX in set_file_size error cases

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

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

From: Steve French <[email protected]>

commit 646200a041203f440fb6fcf9cacd9efeda9de74c upstream.

The error paths in set_file_size for cifs and smb3 are incorrect.

In the unlikely event that a server did not support set file info
of the file size, the code incorrectly falls back to trying SMBWriteX
(note that only the original core SMB Write, used for example by DOS,
can set the file size this way - this actually does not work for the more
recent SMBWriteX). The idea was since the old DOS SMB Write could set
the file size if you write zero bytes at that offset then use that if
server rejects the normal set file info call.

Fortunately the SMBWriteX will never be sent on the wire (except when
file size is zero) since the length and offset fields were reversed
in the two places in this function that call SMBWriteX causing
the fall back path to return an error. It is also important to never call
an SMB request from an SMB2/sMB3 session (which theoretically would
be possible, and can cause a brief session drop, although the client
recovers) so this should be fixed. In practice this path does not happen
with modern servers but the error fall back to SMBWriteX is clearly wrong.

Removing the calls to SMBWriteX in the error paths in cifs_set_file_size

Pointed out by PaX/grsecurity team

Signed-off-by: Steve French <[email protected]>
Reported-by: PaX Team <[email protected]>
CC: Emese Revfy <[email protected]>
CC: Brad Spengler <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
fs/cifs/inode.c | 34 ----------------------------------
1 file changed, 34 deletions(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 0c3ce464..c88a827 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -2010,7 +2010,6 @@ cifs_set_file_size(struct inode *inode, struct iattr *attrs,
struct tcon_link *tlink = NULL;
struct cifs_tcon *tcon = NULL;
struct TCP_Server_Info *server;
- struct cifs_io_parms io_parms;

/*
* To avoid spurious oplock breaks from server, in the case of
@@ -2032,18 +2031,6 @@ cifs_set_file_size(struct inode *inode, struct iattr *attrs,
rc = -ENOSYS;
cifsFileInfo_put(open_file);
cifs_dbg(FYI, "SetFSize for attrs rc = %d\n", rc);
- if ((rc == -EINVAL) || (rc == -EOPNOTSUPP)) {
- unsigned int bytes_written;
-
- io_parms.netfid = open_file->fid.netfid;
- io_parms.pid = open_file->pid;
- io_parms.tcon = tcon;
- io_parms.offset = 0;
- io_parms.length = attrs->ia_size;
- rc = CIFSSMBWrite(xid, &io_parms, &bytes_written,
- NULL, NULL, 1);
- cifs_dbg(FYI, "Wrt seteof rc %d\n", rc);
- }
} else
rc = -EINVAL;

@@ -2069,28 +2056,7 @@ cifs_set_file_size(struct inode *inode, struct iattr *attrs,
else
rc = -ENOSYS;
cifs_dbg(FYI, "SetEOF by path (setattrs) rc = %d\n", rc);
- if ((rc == -EINVAL) || (rc == -EOPNOTSUPP)) {
- __u16 netfid;
- int oplock = 0;

- rc = SMBLegacyOpen(xid, tcon, full_path, FILE_OPEN,
- GENERIC_WRITE, CREATE_NOT_DIR, &netfid,
- &oplock, NULL, cifs_sb->local_nls,
- cifs_remap(cifs_sb));
- if (rc == 0) {
- unsigned int bytes_written;
-
- io_parms.netfid = netfid;
- io_parms.pid = current->tgid;
- io_parms.tcon = tcon;
- io_parms.offset = 0;
- io_parms.length = attrs->ia_size;
- rc = CIFSSMBWrite(xid, &io_parms, &bytes_written, NULL,
- NULL, 1);
- cifs_dbg(FYI, "wrt seteof rc %d\n", rc);
- CIFSSMBClose(xid, tcon, netfid);
- }
- }
if (tlink)
cifs_put_tlink(tlink);

--
1.9.1

2015-11-12 23:19:24

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 049/155] clk: ti: fix dual-registration of uart4_ick

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

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

From: Ben Dooks <[email protected]>

commit 19e79687de22f23bcfb5e79cce3daba20af228d1 upstream.

On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power management to /dev/ttyO3 to fail
when trying to wake the device up.

This solves the following oops:

[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c

Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file")
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Ben Dooks <[email protected]>
Signed-off-by: Tero Kristo <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/clk/ti/clk-3xxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 0d1750a..088930c 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -170,7 +170,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
- DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
@@ -313,6 +312,7 @@ static struct ti_dt_clk am35xx_clks[] = {
static struct ti_dt_clk omap36xx_clks[] = {
DT_CLK(NULL, "omap_192m_alwon_fck", "omap_192m_alwon_fck"),
DT_CLK(NULL, "uart4_fck", "uart4_fck"),
+ DT_CLK(NULL, "uart4_ick", "uart4_ick"),
{ .node_name = NULL },
};

--
1.9.1

2015-11-12 23:57:57

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 050/155] ASoC: dwc: correct irq clear method

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

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

From: Yitian Bu <[email protected]>

commit 4873867e5f2bd90faad861dd94865099fc3140f3 upstream.

from Designware I2S datasheet, tx/rx XRUN irq is cleared by
reading register TOR/ROR, rather than by writing into them.

Signed-off-by: Yitian Bu <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/soc/dwc/designware_i2s.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 8d18bbd..ee0a392 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -100,10 +100,10 @@ static inline void i2s_clear_irqs(struct dw_i2s_dev *dev, u32 stream)

if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
for (i = 0; i < 4; i++)
- i2s_write_reg(dev->i2s_base, TOR(i), 0);
+ i2s_read_reg(dev->i2s_base, TOR(i));
} else {
for (i = 0; i < 4; i++)
- i2s_write_reg(dev->i2s_base, ROR(i), 0);
+ i2s_read_reg(dev->i2s_base, ROR(i));
}
}

--
1.9.1

2015-11-12 23:19:18

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 051/155] dm raid: fix round up of default region size

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

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

From: Mikulas Patocka <[email protected]>

commit 042745ee53a0a7c1f5aff191a4a24213c6dcfb52 upstream.

Commit 3a0f9aaee028 ("dm raid: round region_size to power of two")
intended to make sure that the default region size is a power of two.
However, the logic in that commit is incorrect and sets the variable
region_size to 0 or 1, depending on whether min_region_size is a power
of two.

Fix this logic, using roundup_pow_of_two(), so that region_size is
properly rounded up to the next power of two.

Signed-off-by: Mikulas Patocka <[email protected]>
Fixes: 3a0f9aaee028 ("dm raid: round region_size to power of two")
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/dm-raid.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 07c0fa0..e5d97da 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -327,8 +327,7 @@ static int validate_region_size(struct raid_set *rs, unsigned long region_size)
*/
if (min_region_size > (1 << 13)) {
/* If not a power of 2, make it the next power of 2 */
- if (min_region_size & (min_region_size - 1))
- region_size = 1 << fls(region_size);
+ region_size = roundup_pow_of_two(min_region_size);
DMINFO("Choosing default region size of %lu sectors",
region_size);
} else {
--
1.9.1

2015-11-12 23:19:28

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 052/155] ALSA: hda: Add dock support for ThinkPad T550

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

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

From: Laura Abbott <[email protected]>

commit d05ea7da0e8f6df3c62cfee75538f347cb3d89ef upstream.

Much like all the other Lenovo laptops, add a quirk to make
sound work with docking.

Reported-and-tested-by: [email protected]
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index fdb4dae..b16b63c 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4980,6 +4980,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x2212, "Thinkpad T440", ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2214, "Thinkpad X240", ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2215, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
+ SND_PCI_QUIRK(0x17aa, 0x2223, "ThinkPad T550", ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x2226, "ThinkPad X250", ALC292_FIXUP_TPT440_DOCK),
SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
SND_PCI_QUIRK(0x17aa, 0x3978, "IdeaPad Y410P", ALC269_FIXUP_NO_SHUTUP),
--
1.9.1

2015-11-12 23:58:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 053/155] ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1

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

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

From: John Flatness <[email protected]>

commit e8ff581f7ac2bc3b8886094b7ca635dcc4d1b0e9 upstream.

The MacBookPro 12,1 has the same setup as the 11 for controlling the
status of the optical audio light. Simply apply the existing workaround
to the subsystem ID for the 12,1.

[sorted the fixup entry by tiwai]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105401
Signed-off-by: John Flatness <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/pci/hda/patch_cirrus.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index e5dac8e..1b3b38d 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -634,6 +634,7 @@ static const struct snd_pci_quirk cs4208_mac_fixup_tbl[] = {
SND_PCI_QUIRK(0x106b, 0x5e00, "MacBookPro 11,2", CS4208_MBP11),
SND_PCI_QUIRK(0x106b, 0x7100, "MacBookAir 6,1", CS4208_MBA6),
SND_PCI_QUIRK(0x106b, 0x7200, "MacBookAir 6,2", CS4208_MBA6),
+ SND_PCI_QUIRK(0x106b, 0x7b00, "MacBookPro 12,1", CS4208_MBP11),
{} /* terminator */
};

--
1.9.1

2015-11-12 23:57:58

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 054/155] USB: Add reset-resume quirk for two Plantronics usb headphones.

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

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

From: Yao-Wen Mao <[email protected]>

commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 upstream.

These two headphones need a reset-resume quirk to properly resume to
original volume level.

Signed-off-by: Yao-Wen Mao <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/usb/core/quirks.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 41e510a..0db4270 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -78,6 +78,12 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Philips PSC805 audio device */
{ USB_DEVICE(0x0471, 0x0155), .driver_info = USB_QUIRK_RESET_RESUME },

+ /* Plantronic Audio 655 DSP */
+ { USB_DEVICE(0x047f, 0xc008), .driver_info = USB_QUIRK_RESET_RESUME },
+
+ /* Plantronic Audio 648 USB */
+ { USB_DEVICE(0x047f, 0xc013), .driver_info = USB_QUIRK_RESET_RESUME },
+
/* Artisman Watchdog Dongle */
{ USB_DEVICE(0x04b4, 0x0526), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
--
1.9.1

2015-11-12 23:57:56

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 055/155] usb: Add device quirk for Logitech PTZ cameras

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

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

From: Vincent Palatin <[email protected]>

commit 72194739f54607bbf8cfded159627a2015381557 upstream.

Add a device quirk for the Logitech PTZ Pro Camera and its sibling the
ConferenceCam CC3000e Camera.
This fixes the failed camera enumeration on some boot, particularly on
machines with fast CPU.

Tested by connecting a Logitech PTZ Pro Camera to a machine with a
Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles
while recording the kernel logs and taking camera picture after each boot.
Before the patch, more than 7% of the boots show some enumeration transfer
failures and in a few of them, the kernel is giving up before actually
enumerating the webcam. After the patch, the enumeration has been correct
on every reboot.

Signed-off-by: Vincent Palatin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/usb/core/quirks.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 0db4270..8a77a41 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -54,6 +54,13 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT },
{ USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT },

+ /* Logitech ConferenceCam CC3000e */
+ { USB_DEVICE(0x046d, 0x0847), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x046d, 0x0848), .driver_info = USB_QUIRK_DELAY_INIT },
+
+ /* Logitech PTZ Pro Camera */
+ { USB_DEVICE(0x046d, 0x0853), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Logitech Quickcam Fusion */
{ USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME },

--
1.9.1

2015-11-12 23:56:23

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 056/155] tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

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

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

From: Kosuke Tatsukawa <[email protected]>

commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream.

My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty. kernel stack for the stuck process looks like below.
#0 [ffff88303d107b58] __schedule at ffffffff815c4b20
#1 [ffff88303d107bd0] schedule at ffffffff815c513e
#2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
#3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
#4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
#5 [ffff88303d107dd0] tty_read at ffffffff81368013
#6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
#7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
#8 [ffff88303d107f00] sys_read at ffffffff811a4306
#9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7

There seems to be two problems causing this issue.

First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
updates ldata->commit_head using smp_store_release() and then checks
the wait queue using waitqueue_active(). However, since there is no
memory barrier, __receive_buf() could return without calling
wake_up_interactive_poll(), and at the same time, n_tty_read() could
start to wait in wait_woken() as in the following chart.

__receive_buf() n_tty_read()
------------------------------------------------------------------------
if (waitqueue_active(&tty->read_wait))
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
add_wait_queue(&tty->read_wait, &wait);
...
if (!input_available_p(tty, 0)) {
smp_store_release(&ldata->commit_head,
ldata->read_head);
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------

The second problem is that n_tty_read() also lacks a memory barrier
call and could also cause __receive_buf() to return without calling
wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
as in the chart below.

__receive_buf() n_tty_read()
------------------------------------------------------------------------
spin_lock_irqsave(&q->lock, flags);
/* from add_wait_queue() */
...
if (!input_available_p(tty, 0)) {
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
smp_store_release(&ldata->commit_head,
ldata->read_head);
if (waitqueue_active(&tty->read_wait))
__add_wait_queue(q, wait);
spin_unlock_irqrestore(&q->lock,flags);
/* from add_wait_queue() */
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------

There are also other places in drivers/tty/n_tty.c which have similar
calls to waitqueue_active(), so instead of adding many memory barrier
calls, this patch simply removes the call to waitqueue_active(),
leaving just wake_up*() behind.

This fixes both problems because, even though the memory access before
or after the spinlocks in both wake_up*() and add_wait_queue() can
sneak into the critical section, it cannot go past it and the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.

Latency measurement using a ping-pong test over a pty doesn't show any
visible performance drop.

Signed-off-by: Kosuke Tatsukawa <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/tty/n_tty.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 3ecbd91..ba88b43 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -365,8 +365,7 @@ static void n_tty_packet_mode_flush(struct tty_struct *tty)
spin_lock_irqsave(&tty->ctrl_lock, flags);
tty->ctrl_status |= TIOCPKT_FLUSHREAD;
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
- if (waitqueue_active(&tty->link->read_wait))
- wake_up_interruptible(&tty->link->read_wait);
+ wake_up_interruptible(&tty->link->read_wait);
}
}

@@ -1387,8 +1386,7 @@ handle_newline:
put_tty_queue(c, ldata);
ldata->canon_head = ldata->read_head;
kill_fasync(&tty->fasync, SIGIO, POLL_IN);
- if (waitqueue_active(&tty->read_wait))
- wake_up_interruptible_poll(&tty->read_wait, POLLIN);
+ wake_up_interruptible_poll(&tty->read_wait, POLLIN);
return 0;
}
}
@@ -1671,8 +1669,7 @@ static void __receive_buf(struct tty_struct *tty, const unsigned char *cp,
if ((!ldata->icanon && (read_cnt(ldata) >= ldata->minimum_to_wake)) ||
L_EXTPROC(tty)) {
kill_fasync(&tty->fasync, SIGIO, POLL_IN);
- if (waitqueue_active(&tty->read_wait))
- wake_up_interruptible_poll(&tty->read_wait, POLLIN);
+ wake_up_interruptible_poll(&tty->read_wait, POLLIN);
}
}

@@ -1891,10 +1888,8 @@ static void n_tty_set_termios(struct tty_struct *tty, struct ktermios *old)
}

/* The termios change make the tty ready for I/O */
- if (waitqueue_active(&tty->write_wait))
- wake_up_interruptible(&tty->write_wait);
- if (waitqueue_active(&tty->read_wait))
- wake_up_interruptible(&tty->read_wait);
+ wake_up_interruptible(&tty->write_wait);
+ wake_up_interruptible(&tty->read_wait);
}

/**
--
1.9.1

2015-11-12 23:56:25

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 057/155] serial: 8250: add uart_config entry for PORT_RT2880

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

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

From: Mans Rullgard <[email protected]>

commit 3c5a0357fdb3a9116a48dbdb0abb91fd23fbff80 upstream.

This adds an entry to the uart_config table for PORT_RT2880
enabling rx/tx FIFOs. The UART is actually a Palmchip BK-3103
which is found in several devices from Alchemy/RMI, Ralink, and
Sigma Designs.

Signed-off-by: Mans Rullgard <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
[ kamal: backport to 3.19-stable: file rename ]
---
drivers/tty/serial/8250/8250_core.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index ea1a8da..bacc588 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -329,6 +329,14 @@ static const struct serial8250_config uart_config[] = {
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE,
},
+ [PORT_RT2880] = {
+ .name = "Palmchip BK-3103",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO,
+ },
};

/* Uart divisor latch read */
--
1.9.1

2015-11-12 23:56:21

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 058/155] drivers/tty: require read access for controlling terminal

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

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

From: Jann Horn <[email protected]>

commit 0c55627167870255158db1cde0d28366f91c8872 upstream.

This is mostly a hardening fix, given that write-only access to other
users' ttys is usually only given through setgid tty executables.

Signed-off-by: Jann Horn <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/tty/tty_io.c | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 2bb4dfc..27051e29 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2138,8 +2138,24 @@ retry_open:
if (!noctty &&
current->signal->leader &&
!current->signal->tty &&
- tty->session == NULL)
- __proc_set_tty(tty);
+ tty->session == NULL) {
+ /*
+ * Don't let a process that only has write access to the tty
+ * obtain the privileges associated with having a tty as
+ * controlling terminal (being able to reopen it with full
+ * access through /dev/tty, being able to perform pushback).
+ * Many distributions set the group of all ttys to "tty" and
+ * grant write-only access to all terminals for setgid tty
+ * binaries, which should not imply full privileges on all ttys.
+ *
+ * This could theoretically break old code that performs open()
+ * on a write-only file descriptor. In that case, it might be
+ * necessary to also permit this if
+ * inode_permission(inode, MAY_READ) == 0.
+ */
+ if (filp->f_mode & FMODE_READ)
+ __proc_set_tty(tty);
+ }
spin_unlock_irq(&current->sighand->siglock);
read_unlock(&tasklist_lock);
tty_unlock(tty);
@@ -2428,7 +2444,7 @@ static int fionbio(struct file *file, int __user *p)
* Takes ->siglock() when updating signal->tty
*/

-static int tiocsctty(struct tty_struct *tty, int arg)
+static int tiocsctty(struct tty_struct *tty, struct file *file, int arg)
{
int ret = 0;

@@ -2462,6 +2478,13 @@ static int tiocsctty(struct tty_struct *tty, int arg)
goto unlock;
}
}
+
+ /* See the comment in tty_open(). */
+ if ((file->f_mode & FMODE_READ) == 0 && !capable(CAP_SYS_ADMIN)) {
+ ret = -EPERM;
+ goto unlock;
+ }
+
proc_set_tty(tty);
unlock:
read_unlock(&tasklist_lock);
@@ -2854,7 +2877,7 @@ long tty_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
no_tty();
return 0;
case TIOCSCTTY:
- return tiocsctty(tty, arg);
+ return tiocsctty(tty, file, arg);
case TIOCGPGRP:
return tiocgpgrp(tty, real_tty, p);
case TIOCSPGRP:
--
1.9.1

2015-11-12 23:56:20

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 059/155] staging: speakup: fix speakup-r regression

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

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

From: "[email protected]" <[email protected]>

commit b1d562acc78f0af46de0dfe447410bc40bdb7ece upstream.

Here is a patch to make speakup-r work again.

It broke in 3.6 due to commit 4369c64c79a22b98d3b7eff9d089196cd878a10a
"Input: Send events one packet at a time)

The problem was that the fakekey.c routine to fake a down arrow no
longer functioned properly and putting the input_sync fixed it.

Fixes: 4369c64c79a22b98d3b7eff9d089196cd878a10a
Acked-by: Samuel Thibault <[email protected]>
Signed-off-by: John Covici <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/staging/speakup/fakekey.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/staging/speakup/fakekey.c b/drivers/staging/speakup/fakekey.c
index 4299cf4..5e1f16c 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -81,6 +81,7 @@ void speakup_fake_down_arrow(void)
__this_cpu_write(reporting_keystroke, true);
input_report_key(virt_keyboard, KEY_DOWN, PRESSED);
input_report_key(virt_keyboard, KEY_DOWN, RELEASED);
+ input_sync(virt_keyboard);
__this_cpu_write(reporting_keystroke, false);

/* reenable preemption */
--
1.9.1

2015-11-12 23:56:19

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 060/155] ALSA: synth: Fix conflicting OSS device registration on AWE32

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

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

From: Takashi Iwai <[email protected]>

commit 225db5762dc1a35b26850477ffa06e5cd0097243 upstream.

When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel
warnings like:
WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80()
sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0'

It's because both emux synth and opl3 drivers try to register their
OSS device object with the same static index number 0. This hasn't
been a big problem until the recent rewrite of device management code
(that exposes sysfs at the same time), but it's been an obvious bug.

This patch works around it just by using a different index number of
emux synth object. There can be a more elegant way to fix, but it's
enough for now, as this code won't be touched so often, in anyway.

Reported-and-tested-by: Michael Shell <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/synth/emux/emux_oss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/synth/emux/emux_oss.c b/sound/synth/emux/emux_oss.c
index daf61ab..646b667 100644
--- a/sound/synth/emux/emux_oss.c
+++ b/sound/synth/emux/emux_oss.c
@@ -69,7 +69,8 @@ snd_emux_init_seq_oss(struct snd_emux *emu)
struct snd_seq_oss_reg *arg;
struct snd_seq_device *dev;

- if (snd_seq_device_new(emu->card, 0, SNDRV_SEQ_DEV_ID_OSS,
+ /* using device#1 here for avoiding conflicts with OPL3 */
+ if (snd_seq_device_new(emu->card, 1, SNDRV_SEQ_DEV_ID_OSS,
sizeof(struct snd_seq_oss_reg), &dev) < 0)
return;

--
1.9.1

2015-11-12 23:53:41

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 061/155] arm64: readahead: fault retry breaks mmap file read random detection

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

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

From: Mark Salyzyn <[email protected]>

commit 569ba74a7ba69f46ce2950bf085b37fea2408385 upstream.

This is the arm64 portion of commit 45cac65b0fcd ("readahead: fault
retry breaks mmap file read random detection"), which was absent from
the initial port and has since gone unnoticed. The original commit says:

> .fault now can retry. The retry can break state machine of .fault. In
> filemap_fault, if page is miss, ra->mmap_miss is increased. In the second
> try, since the page is in page cache now, ra->mmap_miss is decreased. And
> these are done in one fault, so we can't detect random mmap file access.
>
> Add a new flag to indicate .fault is tried once. In the second try, skip
> ra->mmap_miss decreasing. The filemap_fault state machine is ok with it.

With this change, Mark reports that:

> Random read improves by 250%, sequential read improves by 40%, and
> random write by 400% to an eMMC device with dm crypto wrapped around it.

Cc: Shaohua Li <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Wu Fengguang <[email protected]>
Signed-off-by: Mark Salyzyn <[email protected]>
Signed-off-by: Riley Andrews <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm64/mm/fault.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index c11cd27..44422df 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -279,6 +279,7 @@ retry:
* starvation.
*/
mm_flags &= ~FAULT_FLAG_ALLOW_RETRY;
+ mm_flags |= FAULT_FLAG_TRIED;
goto retry;
}
}
--
1.9.1

2015-11-12 23:55:43

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 062/155] ASoC: tas2552: Correct the Speaker Driver Playback Volume (PGA_GAIN)

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

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

From: Peter Ujfalusi <[email protected]>

commit dd6ae3bcfe0fa9cf1bdb6f952c617f2070c57b37 upstream.

The last parameter for DECLARE_TLV_DB_SCALE() is to tell if the gain will
be muted or not when it is set to raw 0. IN this case it is not muted.
The PGA_GAIN is in 0-4 bits in the register. Fix the offset in the
SOC_SINGLE_TLV() for this.

Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/soc/codecs/tas2552.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index 8f9d1e6..6c76015 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -333,11 +333,11 @@ static struct snd_soc_dai_driver tas2552_dai[] = {
/*
* DAC digital volumes. From -7 to 24 dB in 1 dB steps
*/
-static DECLARE_TLV_DB_SCALE(dac_tlv, -7, 100, 24);
+static DECLARE_TLV_DB_SCALE(dac_tlv, -7, 100, 0);

static const struct snd_kcontrol_new tas2552_snd_controls[] = {
SOC_SINGLE_TLV("Speaker Driver Playback Volume",
- TAS2552_PGA_GAIN, 0, 0x1f, 1, dac_tlv),
+ TAS2552_PGA_GAIN, 0, 0x1f, 0, dac_tlv),
};

static const struct reg_default tas2552_init_regs[] = {
--
1.9.1

2015-11-12 23:54:41

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 063/155] ASoC: tas2552: fix dBscale-min declaration

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

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

From: Andreas Dannenberg <[email protected]>

commit e2600460bc3aa14ca1df86318a327cbbabedf9a8 upstream.

The minimum volume level for the TAS2552 (control register value 0x00)
is -7dB however the driver declares it as -0.07dB.

Running amixer before the patch reports:
dBscale-min=-0.07dB,step=1.00dB,mute=0

Running amixer with the patch applied reports:
dBscale-min=-7.00dB,step=1.00dB,mute=0

Signed-off-by: Andreas Dannenberg <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/soc/codecs/tas2552.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index 6c76015..8cca1be 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -333,7 +333,7 @@ static struct snd_soc_dai_driver tas2552_dai[] = {
/*
* DAC digital volumes. From -7 to 24 dB in 1 dB steps
*/
-static DECLARE_TLV_DB_SCALE(dac_tlv, -7, 100, 0);
+static DECLARE_TLV_DB_SCALE(dac_tlv, -700, 100, 0);

static const struct snd_kcontrol_new tas2552_snd_controls[] = {
SOC_SINGLE_TLV("Speaker Driver Playback Volume",
--
1.9.1

2015-11-12 23:52:37

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 064/155] sched/core: Fix TASK_DEAD race in finish_task_switch()

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

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

From: Peter Zijlstra <[email protected]>

commit 95913d97914f44db2b81271c2e2ebd4d2ac2df83 upstream.

So the problem this patch is trying to address is as follows:

CPU0 CPU1

context_switch(A, B)
ttwu(A)
LOCK A->pi_lock
A->on_cpu == 0
finish_task_switch(A)
prev_state = A->state <-.
WMB |
A->on_cpu = 0; |
UNLOCK rq0->lock |
| context_switch(C, A)
`-- A->state = TASK_DEAD
prev_state == TASK_DEAD
put_task_struct(A)
context_switch(A, C)
finish_task_switch(A)
A->state == TASK_DEAD
put_task_struct(A)

The argument being that the WMB will allow the load of A->state on CPU0
to cross over and observe CPU1's store of A->state, which will then
result in a double-drop and use-after-free.

Now the comment states (and this was true once upon a long time ago)
that we need to observe A->state while holding rq->lock because that
will order us against the wakeup; however the wakeup will not in fact
acquire (that) rq->lock; it takes A->pi_lock these days.

We can obviously fix this by upgrading the WMB to an MB, but that is
expensive, so we'd rather avoid that.

The alternative this patch takes is: smp_store_release(&A->on_cpu, 0),
which avoids the MB on some archs, but not important ones like ARM.

Reported-by: Oleg Nesterov <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Fixes: e4a52bcb9a18 ("sched: Remove rq->lock from the first half of ttwu()")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
kernel/sched/core.c | 10 +++++-----
kernel/sched/sched.h | 5 +++--
2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2ef0f5e..7ee38f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2267,11 +2267,11 @@ static struct rq *finish_task_switch(struct task_struct *prev)
* If a task dies, then it sets TASK_DEAD in tsk->state and calls
* schedule one last time. The schedule call will never return, and
* the scheduled task must drop that reference.
- * The test for TASK_DEAD must occur while the runqueue locks are
- * still held, otherwise prev could be scheduled on another cpu, die
- * there before we look at prev->state, and then the reference would
- * be dropped twice.
- * Manfred Spraul <[email protected]>
+ *
+ * We must observe prev->state before clearing prev->on_cpu (in
+ * finish_lock_switch), otherwise a concurrent wakeup can get prev
+ * running on another CPU and we could rave with its RUNNING -> DEAD
+ * transition, resulting in a double drop.
*/
prev_state = prev->state;
vtime_task_switch(prev);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 9a2a45c..6183e4b 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1031,9 +1031,10 @@ static inline void finish_lock_switch(struct rq *rq, struct task_struct *prev)
* After ->on_cpu is cleared, the task can be moved to a different CPU.
* We must ensure this doesn't happen until the switch is completely
* finished.
+ *
+ * Pairs with the control dependency and rmb in try_to_wake_up().
*/
- smp_wmb();
- prev->on_cpu = 0;
+ smp_store_release(&prev->on_cpu, 0);
#endif
#ifdef CONFIG_DEBUG_SPINLOCK
/* this is a valid case when another task releases the spinlock */
--
1.9.1

2015-11-12 23:55:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 065/155] dm cache: fix NULL pointer when switching from cleaner policy

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

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

From: Joe Thornber <[email protected]>

commit 2bffa1503c5c06192eb1459180fac4416575a966 upstream.

The cleaner policy doesn't make use of the per cache block hint space in
the metadata (unlike the other policies). When switching from the
cleaner policy to mq or smq a NULL pointer crash (in dm_tm_new_block)
was observed. The crash was caused by bugs in dm-cache-metadata.c
when trying to skip creation of the hint btree.

The minimal fix is to change hint size for the cleaner policy to 4 bytes
(only hint size supported).

Signed-off-by: Joe Thornber <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/dm-cache-policy-cleaner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/dm-cache-policy-cleaner.c b/drivers/md/dm-cache-policy-cleaner.c
index 004e463..8308f4b 100644
--- a/drivers/md/dm-cache-policy-cleaner.c
+++ b/drivers/md/dm-cache-policy-cleaner.c
@@ -435,7 +435,7 @@ static struct dm_cache_policy *wb_create(dm_cblock_t cache_size,
static struct dm_cache_policy_type wb_policy_type = {
.name = "cleaner",
.version = {1, 0, 0},
- .hint_size = 0,
+ .hint_size = 4,
.owner = THIS_MODULE,
.create = wb_create
};
--
1.9.1

2015-11-12 23:54:40

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 066/155] 3w-9xxx: don't unmap bounce buffered commands

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

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

From: Christoph Hellwig <[email protected]>

commit 15e3d5a285ab9283136dba34bbf72886d9146706 upstream.

3w controller don't dma map small single SGL entry commands but instead
bounce buffer them. Add a helper to identify these commands and don't
call scsi_dma_unmap for them.

Based on an earlier patch from James Bottomley.

Fixes: 118c85 ("3w-9xxx: fix command completion race")
Reported-by: Tóth Attila <[email protected]>
Tested-by: Tóth Attila <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Adam Radford <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/scsi/3w-9xxx.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index 1f9e8d2..4e8209a 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -212,6 +212,17 @@ static const struct file_operations twa_fops = {
.llseek = noop_llseek,
};

+/*
+ * The controllers use an inline buffer instead of a mapped SGL for small,
+ * single entry buffers. Note that we treat a zero-length transfer like
+ * a mapped SGL.
+ */
+static bool twa_command_mapped(struct scsi_cmnd *cmd)
+{
+ return scsi_sg_count(cmd) != 1 ||
+ scsi_bufflen(cmd) >= TW_MIN_SGL_LENGTH;
+}
+
/* This function will complete an aen request from the isr */
static int twa_aen_complete(TW_Device_Extension *tw_dev, int request_id)
{
@@ -1338,7 +1349,8 @@ static irqreturn_t twa_interrupt(int irq, void *dev_instance)
}

/* Now complete the io */
- scsi_dma_unmap(cmd);
+ if (twa_command_mapped(cmd))
+ scsi_dma_unmap(cmd);
cmd->scsi_done(cmd);
tw_dev->state[request_id] = TW_S_COMPLETED;
twa_free_request_id(tw_dev, request_id);
@@ -1581,7 +1593,8 @@ static int twa_reset_device_extension(TW_Device_Extension *tw_dev)
struct scsi_cmnd *cmd = tw_dev->srb[i];

cmd->result = (DID_RESET << 16);
- scsi_dma_unmap(cmd);
+ if (twa_command_mapped(cmd))
+ scsi_dma_unmap(cmd);
cmd->scsi_done(cmd);
}
}
@@ -1764,12 +1777,14 @@ static int twa_scsi_queue_lck(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_
retval = twa_scsiop_execute_scsi(tw_dev, request_id, NULL, 0, NULL);
switch (retval) {
case SCSI_MLQUEUE_HOST_BUSY:
- scsi_dma_unmap(SCpnt);
+ if (twa_command_mapped(SCpnt))
+ scsi_dma_unmap(SCpnt);
twa_free_request_id(tw_dev, request_id);
break;
case 1:
SCpnt->result = (DID_ERROR << 16);
- scsi_dma_unmap(SCpnt);
+ if (twa_command_mapped(SCpnt))
+ scsi_dma_unmap(SCpnt);
done(SCpnt);
tw_dev->state[request_id] = TW_S_COMPLETED;
twa_free_request_id(tw_dev, request_id);
@@ -1830,8 +1845,7 @@ static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int request_id,
/* Map sglist from scsi layer to cmd packet */

if (scsi_sg_count(srb)) {
- if ((scsi_sg_count(srb) == 1) &&
- (scsi_bufflen(srb) < TW_MIN_SGL_LENGTH)) {
+ if (!twa_command_mapped(srb)) {
if (srb->sc_data_direction == DMA_TO_DEVICE ||
srb->sc_data_direction == DMA_BIDIRECTIONAL)
scsi_sg_copy_to_buffer(srb,
@@ -1904,7 +1918,7 @@ static void twa_scsiop_execute_scsi_complete(TW_Device_Extension *tw_dev, int re
{
struct scsi_cmnd *cmd = tw_dev->srb[request_id];

- if (scsi_bufflen(cmd) < TW_MIN_SGL_LENGTH &&
+ if (!twa_command_mapped(cmd) &&
(cmd->sc_data_direction == DMA_FROM_DEVICE ||
cmd->sc_data_direction == DMA_BIDIRECTIONAL)) {
if (scsi_sg_count(cmd) == 1) {
--
1.9.1

2015-11-12 23:53:01

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 067/155] workqueue: make sure delayed work run in local cpu

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

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

From: Shaohua Li <[email protected]>

commit 874bbfe600a660cba9c776b3957b1ce393151b76 upstream.

My system keeps crashing with below message. vmstat_update() schedules a delayed
work in current cpu and expects the work runs in the cpu.
schedule_delayed_work() is expected to make delayed work run in local cpu. The
problem is timer can be migrated with NO_HZ. __queue_work() queues work in
timer handler, which could run in a different cpu other than where the delayed
work is scheduled. The end result is the delayed work runs in different cpu.
The patch makes __queue_delayed_work records local cpu earlier. Where the timer
runs doesn't change where the work runs with the change.

[ 28.010131] ------------[ cut here ]------------
[ 28.010609] kernel BUG at ../mm/vmstat.c:1392!
[ 28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
[ 28.011860] Modules linked in:
[ 28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G W4.3.0-rc3+ #634
[ 28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
[ 28.014160] Workqueue: events vmstat_update
[ 28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000
[ 28.015445] RIP: 0010:[<ffffffff8115f921>] [<ffffffff8115f921>]vmstat_update+0x31/0x80
[ 28.016282] RSP: 0018:ffff8800ba42fd80 EFLAGS: 00010297
[ 28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000
[ 28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d
[ 28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000
[ 28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640
[ 28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000
[ 28.020071] FS: 0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000
[ 28.020071] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0
[ 28.020071] Stack:
[ 28.020071] ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88
[ 28.020071] ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8
[ 28.020071] ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340
[ 28.020071] Call Trace:
[ 28.020071] [<ffffffff8106bd88>] process_one_work+0x1c8/0x540
[ 28.020071] [<ffffffff8106bd0b>] ? process_one_work+0x14b/0x540
[ 28.020071] [<ffffffff8106c214>] worker_thread+0x114/0x460
[ 28.020071] [<ffffffff8106c100>] ? process_one_work+0x540/0x540
[ 28.020071] [<ffffffff81071bf8>] kthread+0xf8/0x110
[ 28.020071] [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
[ 28.020071] [<ffffffff81a6522f>] ret_from_fork+0x3f/0x70
[ 28.020071] [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200

Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
kernel/workqueue.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 82d0c8d..e80693f 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1442,13 +1442,13 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq,
timer_stats_timer_set_start_info(&dwork->timer);

dwork->wq = wq;
+ /* timer isn't guaranteed to run in this cpu, record earlier */
+ if (cpu == WORK_CPU_UNBOUND)
+ cpu = raw_smp_processor_id();
dwork->cpu = cpu;
timer->expires = jiffies + delay;

- if (unlikely(cpu != WORK_CPU_UNBOUND))
- add_timer_on(timer, cpu);
- else
- add_timer(timer);
+ add_timer_on(timer, cpu);
}

/**
--
1.9.1

2015-11-12 23:53:43

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 068/155] drm/radeon: add pm sysfs files late

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

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

From: Alex Deucher <[email protected]>

commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 upstream.

They were added relatively early in the driver init process
which meant that in some cases the driver was not finished
initializing before external tools tried to use them which
could result in a crash depending on the timing.

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/radeon_display.c | 14 ++------
drivers/gpu/drm/radeon/radeon_pm.c | 63 ++++++++++++++++++++-------------
2 files changed, 40 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 913fafa..99a5494 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1620,18 +1620,8 @@ int radeon_modeset_init(struct radeon_device *rdev)
radeon_fbdev_init(rdev);
drm_kms_helper_poll_init(rdev->ddev);

- if (rdev->pm.dpm_enabled) {
- /* do dpm late init */
- ret = radeon_pm_late_init(rdev);
- if (ret) {
- rdev->pm.dpm_enabled = false;
- DRM_ERROR("radeon_pm_late_init failed, disabling dpm\n");
- }
- /* set the dpm state for PX since there won't be
- * a modeset to call this.
- */
- radeon_pm_compute_clocks(rdev);
- }
+ /* do pm late init */
+ ret = radeon_pm_late_init(rdev);

return 0;
}
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
index 1d94b54..d22cf0d 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1192,14 +1192,6 @@ static int radeon_pm_init_old(struct radeon_device *rdev)
INIT_DELAYED_WORK(&rdev->pm.dynpm_idle_work, radeon_dynpm_idle_work_handler);

if (rdev->pm.num_power_states > 1) {
- /* where's the best place to put these? */
- ret = device_create_file(rdev->dev, &dev_attr_power_profile);
- if (ret)
- DRM_ERROR("failed to create device file for power profile\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_method);
- if (ret)
- DRM_ERROR("failed to create device file for power method\n");
-
if (radeon_debugfs_pm_init(rdev)) {
DRM_ERROR("Failed to register debugfs file for PM!\n");
}
@@ -1257,20 +1249,6 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev)
goto dpm_failed;
rdev->pm.dpm_enabled = true;

- ret = device_create_file(rdev->dev, &dev_attr_power_dpm_state);
- if (ret)
- DRM_ERROR("failed to create device file for dpm state\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_dpm_force_performance_level);
- if (ret)
- DRM_ERROR("failed to create device file for dpm state\n");
- /* XXX: these are noops for dpm but are here for backwards compat */
- ret = device_create_file(rdev->dev, &dev_attr_power_profile);
- if (ret)
- DRM_ERROR("failed to create device file for power profile\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_method);
- if (ret)
- DRM_ERROR("failed to create device file for power method\n");
-
if (radeon_debugfs_pm_init(rdev)) {
DRM_ERROR("Failed to register debugfs file for dpm!\n");
}
@@ -1411,9 +1389,44 @@ int radeon_pm_late_init(struct radeon_device *rdev)
int ret = 0;

if (rdev->pm.pm_method == PM_METHOD_DPM) {
- mutex_lock(&rdev->pm.mutex);
- ret = radeon_dpm_late_enable(rdev);
- mutex_unlock(&rdev->pm.mutex);
+ if (rdev->pm.dpm_enabled) {
+ ret = device_create_file(rdev->dev, &dev_attr_power_dpm_state);
+ if (ret)
+ DRM_ERROR("failed to create device file for dpm state\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_dpm_force_performance_level);
+ if (ret)
+ DRM_ERROR("failed to create device file for dpm state\n");
+ /* XXX: these are noops for dpm but are here for backwards compat */
+ ret = device_create_file(rdev->dev, &dev_attr_power_profile);
+ if (ret)
+ DRM_ERROR("failed to create device file for power profile\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_method);
+ if (ret)
+ DRM_ERROR("failed to create device file for power method\n");
+
+ mutex_lock(&rdev->pm.mutex);
+ ret = radeon_dpm_late_enable(rdev);
+ mutex_unlock(&rdev->pm.mutex);
+ if (ret) {
+ rdev->pm.dpm_enabled = false;
+ DRM_ERROR("radeon_pm_late_init failed, disabling dpm\n");
+ } else {
+ /* set the dpm state for PX since there won't be
+ * a modeset to call this.
+ */
+ radeon_pm_compute_clocks(rdev);
+ }
+ }
+ } else {
+ if (rdev->pm.num_power_states > 1) {
+ /* where's the best place to put these? */
+ ret = device_create_file(rdev->dev, &dev_attr_power_profile);
+ if (ret)
+ DRM_ERROR("failed to create device file for power profile\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_method);
+ if (ret)
+ DRM_ERROR("failed to create device file for power method\n");
+ }
}
return ret;
}
--
1.9.1

2015-11-12 23:53:04

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 069/155] drm/radeon: add quirk for MSI R7 370

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

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

From: Maxim Sheviakov <[email protected]>

commit e78654799135a788a941bacad3452fbd7083e518 upstream.

Just adds the quirk for MSI R7 370 Armor 2X
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91294

Signed-off-by: Maxim Sheviakov <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/si_dpm.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index fe252b0..c884df8 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2923,6 +2923,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6810, 0x1462, 0x3036, 0, 120000 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 120000 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 90000 },
+ { PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 120000 },
{ 0, 0, 0, 0 },
};

--
1.9.1

2015-11-12 23:53:40

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 070/155] drm/radeon: add quirk for ASUS R7 370

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

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

From: Alex Deucher <[email protected]>

commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 upstream.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92260

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/si_dpm.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index c884df8..d67ce4c 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2924,6 +2924,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 120000 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 90000 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 120000 },
+ { PCI_VENDOR_ID_ATI, 0x6811, 0x1043, 0x2015, 0, 120000 },
{ 0, 0, 0, 0 },
};

--
1.9.1

2015-11-12 23:50:52

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 071/155] cxl: Fix number of allocated pages in SPA

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

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

From: Christophe Lombard <[email protected]>

commit 4108efb02daa09cbb5db048ada55a5b021b5183d upstream.

The scheduled process area is currently allocated before assigning the
correct maximum processes to the AFU, which will mean we only ever
allocate a fixed number of pages for the scheduled process area. This
will limit us to 958 processes with 2 x 64K pages. If we try to use more
processes than that we'd probably overrun the buffer and corrupt memory
or crash.

AFUs that require three or more interrupts per process will not be
affected as they are already limited to less processes than that, but we
could hit it on an AFU that requires 0, 1 or 2 interrupts per process,
or when using 4K pages.

This patch moves the initialisation of the num_procs to before the SPA
allocation so that enough pages will be allocated for the number of
processes that the AFU supports.

Signed-off-by: Christophe Lombard <[email protected]>
Signed-off-by: Ian Munsie <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/misc/cxl/native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
index f2b37b4..84fd936 100644
--- a/drivers/misc/cxl/native.c
+++ b/drivers/misc/cxl/native.c
@@ -377,6 +377,7 @@ static int activate_afu_directed(struct cxl_afu *afu)

dev_info(&afu->dev, "Activating AFU directed mode\n");

+ afu->num_procs = afu->max_procs_virtualised;
if (alloc_spa(afu))
return -ENOMEM;

@@ -385,7 +386,6 @@ static int activate_afu_directed(struct cxl_afu *afu)
cxl_p1n_write(afu, CXL_PSL_ID_An, CXL_PSL_ID_An_F | CXL_PSL_ID_An_L);

afu->current_mode = CXL_MODE_DIRECTED;
- afu->num_procs = afu->max_procs_virtualised;

if ((rc = cxl_chardev_m_afu_add(afu)))
return rc;
--
1.9.1

2015-11-12 23:51:47

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 072/155] crypto: sparc - initialize blkcipher.ivsize

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

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

From: Dave Kleikamp <[email protected]>

commit a66d7f724a96d6fd279bfbd2ee488def6b081bea upstream.

Some of the crypto algorithms write to the initialization vector,
but no space has been allocated for it. This clobbers adjacent memory.

Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/sparc/crypto/aes_glue.c | 2 ++
arch/sparc/crypto/camellia_glue.c | 1 +
arch/sparc/crypto/des_glue.c | 2 ++
3 files changed, 5 insertions(+)

diff --git a/arch/sparc/crypto/aes_glue.c b/arch/sparc/crypto/aes_glue.c
index 7054087..ef08705 100644
--- a/arch/sparc/crypto/aes_glue.c
+++ b/arch/sparc/crypto/aes_glue.c
@@ -433,6 +433,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
+ .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt = cbc_encrypt,
.decrypt = cbc_decrypt,
@@ -452,6 +453,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
+ .ivsize = AES_BLOCK_SIZE,
.setkey = aes_set_key,
.encrypt = ctr_crypt,
.decrypt = ctr_crypt,
diff --git a/arch/sparc/crypto/camellia_glue.c b/arch/sparc/crypto/camellia_glue.c
index 641f55c..eb87d6d 100644
--- a/arch/sparc/crypto/camellia_glue.c
+++ b/arch/sparc/crypto/camellia_glue.c
@@ -274,6 +274,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize = CAMELLIA_MIN_KEY_SIZE,
.max_keysize = CAMELLIA_MAX_KEY_SIZE,
+ .ivsize = CAMELLIA_BLOCK_SIZE,
.setkey = camellia_set_key,
.encrypt = cbc_encrypt,
.decrypt = cbc_decrypt,
diff --git a/arch/sparc/crypto/des_glue.c b/arch/sparc/crypto/des_glue.c
index d115009..1359bfc 100644
--- a/arch/sparc/crypto/des_glue.c
+++ b/arch/sparc/crypto/des_glue.c
@@ -429,6 +429,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize = DES_KEY_SIZE,
.max_keysize = DES_KEY_SIZE,
+ .ivsize = DES_BLOCK_SIZE,
.setkey = des_set_key,
.encrypt = cbc_encrypt,
.decrypt = cbc_decrypt,
@@ -485,6 +486,7 @@ static struct crypto_alg algs[] = { {
.blkcipher = {
.min_keysize = DES3_EDE_KEY_SIZE,
.max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
.setkey = des3_ede_set_key,
.encrypt = cbc3_encrypt,
.decrypt = cbc3_decrypt,
--
1.9.1

2015-11-12 23:50:53

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 073/155] drm: Fix locking for sysfs dpms file

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

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

From: Daniel Vetter <[email protected]>

commit 621bd0f6982badd6483acb191eb7b6226a578328 upstream.

With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.

To make it clear that we play tricks use the READ_ONCE compiler
barrier (and also for paranoia).

Note that there's not really anything bad going on since even with the
new atomic paths we eventually end up not chasing any pointers (and
hence possibly freed memory and other fun stuff). The locking WARNING
has been added in

commit 88a48e297b3a3bac6022c03babfb038f1a886cea
Author: Rob Clark <[email protected]>
Date: Thu Dec 18 16:01:50 2014 -0500

drm: add atomic properties

but since drivers are converting not everyone will have seen this from
the start.

Jens reported this and submitted a patch to just grab the
mode_config.connection_mutex, but we can do a bit better.

v2: Remove unused variables I failed to git add for real.

Reference: http://mid.gmane.org/[email protected]
Reported-by: Jens Axboe <[email protected]>
Tested-by: Jens Axboe <[email protected]>
Cc: Rob Clark <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/drm_sysfs.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index cc3d6d6..b15b1d1 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -190,18 +190,12 @@ static ssize_t dpms_show(struct device *device,
char *buf)
{
struct drm_connector *connector = to_drm_connector(device);
- struct drm_device *dev = connector->dev;
- uint64_t dpms_status;
- int ret;
+ int dpms;

- ret = drm_object_property_get_value(&connector->base,
- dev->mode_config.dpms_property,
- &dpms_status);
- if (ret)
- return 0;
+ dpms = READ_ONCE(connector->dpms);

return snprintf(buf, PAGE_SIZE, "%s\n",
- drm_get_dpms_name((int)dpms_status));
+ drm_get_dpms_name(dpms));
}

static ssize_t enabled_show(struct device *device,
--
1.9.1

2015-11-12 23:51:49

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 074/155] drm/nouveau/fbcon: take runpm reference when userspace has an open fd

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

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

From: Ben Skeggs <[email protected]>

commit f231976c2e8964ceaa9250e57d27c35ff03825c2 upstream.

We need to do this in order to prevent accesses to the device while it's
powered down. Userspace may have an mmap of the fb, and there's no good
way (that I know of) to prevent it from touching the device otherwise.

This fixes some nasty races between runpm and plymouth on some systems,
which result in the GPU getting very upset and hanging the boot.

Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 3ed12a8..2d0ba16 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -178,8 +178,30 @@ nouveau_fbcon_sync(struct fb_info *info)
return 0;
}

+static int
+nouveau_fbcon_open(struct fb_info *info, int user)
+{
+ struct nouveau_fbdev *fbcon = info->par;
+ struct nouveau_drm *drm = nouveau_drm(fbcon->dev);
+ int ret = pm_runtime_get_sync(drm->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return ret;
+ return 0;
+}
+
+static int
+nouveau_fbcon_release(struct fb_info *info, int user)
+{
+ struct nouveau_fbdev *fbcon = info->par;
+ struct nouveau_drm *drm = nouveau_drm(fbcon->dev);
+ pm_runtime_put(drm->dev->dev);
+ return 0;
+}
+
static struct fb_ops nouveau_fbcon_ops = {
.owner = THIS_MODULE,
+ .fb_open = nouveau_fbcon_open,
+ .fb_release = nouveau_fbcon_release,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_fillrect = nouveau_fbcon_fillrect,
@@ -195,6 +217,8 @@ static struct fb_ops nouveau_fbcon_ops = {

static struct fb_ops nouveau_fbcon_sw_ops = {
.owner = THIS_MODULE,
+ .fb_open = nouveau_fbcon_open,
+ .fb_release = nouveau_fbcon_release,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_fillrect = cfb_fillrect,
--
1.9.1

2015-11-12 23:51:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 075/155] arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419

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

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

From: Will Deacon <[email protected]>

commit b6dd8e0719c0d2d01429639a11b7bc2677de240c upstream.

Commit df057cc7b4fa ("arm64: errata: add module build workaround for
erratum #843419") sets CFLAGS_MODULE to ensure that the large memory
model is used by the compiler when building kernel modules.

However, CFLAGS_MODULE is an environment variable and intended to be
overridden on the command line, which appears to be the case with the
Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead.

Cc: Ard Biesheuvel <[email protected]>
Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419")
Reported-by: Dann Frazier <[email protected]>
Tested-by: Dann Frazier <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm64/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 661928f..7cf8a29 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -33,7 +33,7 @@ endif
CHECKFLAGS += -D__aarch64__

ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
-CFLAGS_MODULE += -mcmodel=large
+KBUILD_CFLAGS_MODULE += -mcmodel=large
endif

# Default value
--
1.9.1

2015-11-12 23:49:47

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 076/155] crypto: ahash - ensure statesize is non-zero

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

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

From: Russell King <[email protected]>

commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a upstream.

Unlike shash algorithms, ahash drivers must implement export
and import as their descriptors may contain hardware state and
cannot be exported as is. Unfortunately some ahash drivers did
not provide them and end up causing crashes with algif_hash.

This patch adds a check to prevent these drivers from registering
ahash algorithms until they are fixed.

Signed-off-by: Russell King <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
crypto/ahash.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/ahash.c b/crypto/ahash.c
index f6a36a5..c1d8591 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -543,7 +543,8 @@ static int ahash_prepare_alg(struct ahash_alg *alg)
struct crypto_alg *base = &alg->halg.base;

if (alg->halg.digestsize > PAGE_SIZE / 8 ||
- alg->halg.statesize > PAGE_SIZE / 8)
+ alg->halg.statesize > PAGE_SIZE / 8 ||
+ alg->halg.statesize == 0)
return -EINVAL;

base->cra_type = &crypto_ahash_type;
--
1.9.1

2015-11-12 23:50:54

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 077/155] dm thin: fix missing pool reference count decrement in pool_ctr error path

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

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

From: Mike Snitzer <[email protected]>

commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd upstream.

Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed")
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/dm-thin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index d0a8ee4..734254f 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -2958,7 +2958,7 @@ static int pool_ctr(struct dm_target *ti, unsigned argc, char **argv)
metadata_low_callback,
pool);
if (r)
- goto out_free_pt;
+ goto out_flags_changed;

pt->callbacks.congested_fn = pool_is_congested;
dm_table_add_target_callbacks(ti->table, &pt->callbacks);
--
1.9.1

2015-11-12 23:48:43

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 078/155] btrfs: check unsupported filters in balance arguments

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

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

From: David Sterba <[email protected]>

commit 8eb934591f8bf584969454a658f629cd06e59f3a upstream.

We don't verify that all the balance filter arguments supplemented by
the flags are actually known to the kernel. Thus we let it silently pass
and do nothing.

At the moment this means only the 'limit' filter, but we're going to add
a few more soon so it's better to have that fixed. Also in older stable
kernels so that it works with newer userspace tools.

Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
fs/btrfs/ioctl.c | 5 +++++
fs/btrfs/volumes.h | 8 ++++++++
2 files changed, 13 insertions(+)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index d054504..8f07947 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -4483,6 +4483,11 @@ locked:
bctl->flags |= BTRFS_BALANCE_TYPE_MASK;
}

+ if (bctl->flags & ~(BTRFS_BALANCE_ARGS_MASK | BTRFS_BALANCE_TYPE_MASK)) {
+ ret = -EINVAL;
+ goto out_bargs;
+ }
+
do_balance:
/*
* Ownership of bctl and mutually_exclusive_operation_running
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index d6fe73c..1b74e6b 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -364,6 +364,14 @@ struct map_lookup {
#define BTRFS_BALANCE_ARGS_VRANGE (1ULL << 4)
#define BTRFS_BALANCE_ARGS_LIMIT (1ULL << 5)

+#define BTRFS_BALANCE_ARGS_MASK \
+ (BTRFS_BALANCE_ARGS_PROFILES | \
+ BTRFS_BALANCE_ARGS_USAGE | \
+ BTRFS_BALANCE_ARGS_DEVID | \
+ BTRFS_BALANCE_ARGS_DRANGE | \
+ BTRFS_BALANCE_ARGS_VRANGE | \
+ BTRFS_BALANCE_ARGS_LIMIT)
+
/*
* Profile changing flags. When SOFT is set we won't relocate chunk if
* it already has the target profile (even though it may be
--
1.9.1

2015-11-12 23:49:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 079/155] btrfs: fix use after free iterating extrefs

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

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

From: Chris Mason <[email protected]>

commit dc6c5fb3b514221f2e9d21ee626a9d95d3418dff upstream.

The code for btrfs inode-resolve has never worked properly for
files with enough hard links to trigger extrefs. It was trying to
get the leaf out of a path after freeing the path:

btrfs_release_path(path);
leaf = path->nodes[0];
item_size = btrfs_item_size_nr(leaf, slot);

The fix here is to use the extent buffer we cloned just a little higher
up to avoid deadlocks caused by using the leaf in the path.

Signed-off-by: Chris Mason <[email protected]>
cc: Mark Fasheh <[email protected]>
Reviewed-by: Filipe Manana <[email protected]>
Reviewed-by: Mark Fasheh <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
fs/btrfs/backref.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 8729cf6..6a659c2 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1785,7 +1785,6 @@ static int iterate_inode_extrefs(u64 inum, struct btrfs_root *fs_root,
int found = 0;
struct extent_buffer *eb;
struct btrfs_inode_extref *extref;
- struct extent_buffer *leaf;
u32 item_size;
u32 cur_offset;
unsigned long ptr;
@@ -1813,9 +1812,8 @@ static int iterate_inode_extrefs(u64 inum, struct btrfs_root *fs_root,
btrfs_set_lock_blocking_rw(eb, BTRFS_READ_LOCK);
btrfs_release_path(path);

- leaf = path->nodes[0];
- item_size = btrfs_item_size_nr(leaf, slot);
- ptr = btrfs_item_ptr_offset(leaf, slot);
+ item_size = btrfs_item_size_nr(eb, slot);
+ ptr = btrfs_item_ptr_offset(eb, slot);
cur_offset = 0;

while (cur_offset < item_size) {
@@ -1829,7 +1827,7 @@ static int iterate_inode_extrefs(u64 inum, struct btrfs_root *fs_root,
if (ret)
break;

- cur_offset += btrfs_inode_extref_name_len(leaf, extref);
+ cur_offset += btrfs_inode_extref_name_len(eb, extref);
cur_offset += sizeof(*extref);
}
btrfs_tree_read_unlock_blocking(eb);
--
1.9.1

2015-11-12 23:48:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 080/155] drm/dp/mst: make mst i2c transfer code more robust.

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

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

From: Dave Airlie <[email protected]>

commit ae491542cbbbcca0ec8938c37d4079a985e58440 upstream.

This zeroes the msg so no random stack data ends up getting
sent, it also limits the function to not accepting > 4
i2c msgs.

Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
include/drm/drm_dp_mst_helper.h | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index d7ee25a..1133179 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2771,12 +2771,13 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs
if (msgs[num - 1].flags & I2C_M_RD)
reading = true;

- if (!reading) {
+ if (!reading || (num - 1 > DP_REMOTE_I2C_READ_MAX_TRANSACTIONS)) {
DRM_DEBUG_KMS("Unsupported I2C transaction for MST device\n");
ret = -EIO;
goto out;
}

+ memset(&msg, 0, sizeof(msg));
msg.req_type = DP_REMOTE_I2C_READ;
msg.u.i2c_read.num_transactions = num - 1;
msg.u.i2c_read.port_number = port->port_num;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 180f8a3..50d6eb3 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -253,6 +253,7 @@ struct drm_dp_remote_dpcd_write {
u8 *bytes;
};

+#define DP_REMOTE_I2C_READ_MAX_TRANSACTIONS 4
struct drm_dp_remote_i2c_read {
u8 num_transactions;
u8 port_number;
@@ -262,7 +263,7 @@ struct drm_dp_remote_i2c_read {
u8 *bytes;
u8 no_stop_bit;
u8 i2c_transaction_delay;
- } transactions[4];
+ } transactions[DP_REMOTE_I2C_READ_MAX_TRANSACTIONS];
u8 read_i2c_device_id;
u8 num_bytes_read;
};
--
1.9.1

2015-11-12 23:48:42

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 081/155] i2c: rcar: enable RuntimePM before registering to the core

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

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

From: Wolfram Sang <[email protected]>

commit 4f7effddf4549d57114289f273710f077c4c330a upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/i2c/busses/i2c-rcar.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 71a6e07..7a37ea1 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -690,15 +690,16 @@ static int rcar_i2c_probe(struct platform_device *pdev)
return ret;
}

+ pm_runtime_enable(dev);
+ platform_set_drvdata(pdev, priv);
+
ret = i2c_add_numbered_adapter(adap);
if (ret < 0) {
dev_err(dev, "reg adap failed: %d\n", ret);
+ pm_runtime_disable(dev);
return ret;
}

- pm_runtime_enable(dev);
- platform_set_drvdata(pdev, priv);
-
dev_info(dev, "probed\n");

return 0;
--
1.9.1

2015-11-12 23:48:41

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 082/155] i2c: s3c2410: enable RuntimePM before registering to the core

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

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

From: Wolfram Sang <[email protected]>

commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Signed-off-by: Wolfram Sang <[email protected]>
Tested-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Kukjin Kim <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/i2c/busses/i2c-s3c2410.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 297e9c9..4247942 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1243,17 +1243,19 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
i2c->adap.nr = i2c->pdata->bus_num;
i2c->adap.dev.of_node = pdev->dev.of_node;

+ platform_set_drvdata(pdev, i2c);
+
+ pm_runtime_enable(&pdev->dev);
+
ret = i2c_add_numbered_adapter(&i2c->adap);
if (ret < 0) {
dev_err(&pdev->dev, "failed to add bus to i2c core\n");
+ pm_runtime_disable(&pdev->dev);
s3c24xx_i2c_deregister_cpufreq(i2c);
clk_unprepare(i2c->clk);
return ret;
}

- platform_set_drvdata(pdev, i2c);
-
- pm_runtime_enable(&pdev->dev);
pm_runtime_enable(&i2c->adap.dev);

dev_info(&pdev->dev, "%s: S3C I2C adapter\n", dev_name(&i2c->adap.dev));
--
1.9.1

2015-11-12 23:42:03

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 083/155] i2c: designware-platdrv: enable RuntimePM before registering to the core

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

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

From: Wolfram Sang <[email protected]>

commit 36d48fb5766aee9717e429f772046696b215282d upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail.

Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
[ kamal: backport to 3.19-stable: context ]
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/i2c/busses/i2c-designware-platdrv.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 2b463c3..bd20110 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -251,17 +251,18 @@ static int dw_i2c_probe(struct platform_device *pdev)
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;

+ pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(&pdev->dev, "failure adding adapter\n");
+ pm_runtime_disable(&pdev->dev);
return r;
}

- pm_runtime_set_autosuspend_delay(&pdev->dev, 1000);
- pm_runtime_use_autosuspend(&pdev->dev);
- pm_runtime_set_active(&pdev->dev);
- pm_runtime_enable(&pdev->dev);
-
return 0;
}

--
1.9.1

2015-11-12 23:41:29

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 084/155] memcg: convert threshold to bytes

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

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

From: Shaohua Li <[email protected]>

commit 424cdc14138088ada1b0e407a2195b2783c6e5ef upstream.

page_counter_memparse() returns pages for the threshold, while
mem_cgroup_usage() returns bytes for memory usage. Convert the
threshold to bytes.

Fixes: 3e32cb2e0a12b6915 ("memcg: rename cgroup_event to mem_cgroup_event").
Signed-off-by: Shaohua Li <[email protected]>
Cc: Johannes Weiner <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
mm/memcontrol.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2f6893c..28253e5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3904,6 +3904,7 @@ static int __mem_cgroup_usage_register_event(struct mem_cgroup *memcg,
ret = page_counter_memparse(args, &threshold);
if (ret)
return ret;
+ threshold <<= PAGE_SHIFT;

mutex_lock(&memcg->thresholds_lock);

--
1.9.1

2015-11-12 23:41:31

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 085/155] i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

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

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

From: Mika Westerberg <[email protected]>

commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 upstream.

ACPI SSCN/FMCN methods were originally added because then the platform can
provide the most accurate HCNT/LCNT values to the driver. However, this
seems not to be true for Dell Inspiron 7348 where using these causes the
touchpad to fail in boot:

i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
i2c_designware INT3433:00: controller timed out

The values received from ACPI are (in fast mode):

HCNT: 72
LCNT: 160

this translates to following timings (input clock is 100MHz on Broadwell):

tHIGH: 720 ns (spec min 600 ns)
tLOW: 1600 ns (spec min 1300 ns)
Bus period: 2920 ns (assuming 300 ns tf and tr)
Bus speed: 342.5 kHz

Both tHIGH and tLOW are within the I2C specification.

The calculated values when ACPI parameters are not used are (in fast mode):

HCNT: 87
LCNT: 159

which translates to:

tHIGH: 870 ns (spec min 600 ns)
tLOW: 1590 ns (spec min 1300 ns)
Bus period 3060 ns (assuming 300 ns tf and tr)
Bus speed 326.8 kHz

These values are also within the I2C specification.

Since both ACPI and calculated values meet the I2C specification timing
requirements it is hard to say why the touchpad does not function properly
with the ACPI values except that the bus speed is higher in this case (but
still well below the max 400kHz).

Solve this by adding DMI quirk to the driver that disables using ACPI
parameters on this particulare machine.

Reported-by: Pavel Roskin <[email protected]>
Signed-off-by: Mika Westerberg <[email protected]>
Tested-by: Pavel Roskin <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/i2c/busses/i2c-designware-platdrv.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index bd20110..cf4fb08 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -24,6 +24,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/delay.h>
+#include <linux/dmi.h>
#include <linux/i2c.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
@@ -51,6 +52,22 @@ static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
}

#ifdef CONFIG_ACPI
+/*
+ * The HCNT/LCNT information coming from ACPI should be the most accurate
+ * for given platform. However, some systems get it wrong. On such systems
+ * we get better results by calculating those based on the input clock.
+ */
+static const struct dmi_system_id dw_i2c_no_acpi_params[] = {
+ {
+ .ident = "Dell Inspiron 7348",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 7348"),
+ },
+ },
+ { }
+};
+
static void dw_i2c_acpi_params(struct platform_device *pdev, char method[],
u16 *hcnt, u16 *lcnt, u32 *sda_hold)
{
@@ -58,6 +75,9 @@ static void dw_i2c_acpi_params(struct platform_device *pdev, char method[],
acpi_handle handle = ACPI_HANDLE(&pdev->dev);
union acpi_object *obj;

+ if (dmi_check_system(dw_i2c_no_acpi_params))
+ return;
+
if (ACPI_FAILURE(acpi_evaluate_object(handle, method, NULL, &buf)))
return;

--
1.9.1

2015-11-12 23:40:46

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 086/155] pinctrl: imx25: ensure that a pin with id i is at position i in the info array

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

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

From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <[email protected]>

commit 9911a2d5e9d14e39692b751929a92cb5a1d9d0e0 upstream.

The code in pinctrl-imx.c only works correctly if in the
imx_pinctrl_soc_info passed to imx_pinctrl_probe we have:

info->pins[i].number = i
conf_reg(info->pins[i]) = 4 * i

(which conf_reg(pin) being the offset of the pin's configuration
register).

When the imx25 specific part was introduced in b4a87c9b966f ("pinctrl:
pinctrl-imx: add imx25 pinctrl driver") we had:

info->pins[i].number = i + 1
conf_reg(info->pins[i]) = 4 * i

. Commit 34027ca2bbc6 ("pinctrl: imx25: fix numbering for pins") tried
to fix that but made the situation:

info->pins[i-1].number = i
conf_reg(info->pins[i-1]) = 4 * i

which is hardly better but fixed the error seen back then.

So insert another reserved entry in the array to finally yield:

info->pins[i].number = i
conf_reg(info->pins[i]) = 4 * i

Fixes: 34027ca2bbc6 ("pinctrl: imx25: fix numbering for pins")
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/pinctrl/freescale/pinctrl-imx25.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx25.c b/drivers/pinctrl/freescale/pinctrl-imx25.c
index faf6356..293ed43 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx25.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx25.c
@@ -26,7 +26,8 @@
#include "pinctrl-imx.h"

enum imx25_pads {
- MX25_PAD_RESERVE0 = 1,
+ MX25_PAD_RESERVE0 = 0,
+ MX25_PAD_RESERVE1 = 1,
MX25_PAD_A10 = 2,
MX25_PAD_A13 = 3,
MX25_PAD_A14 = 4,
@@ -169,6 +170,7 @@ enum imx25_pads {
/* Pad names for the pinmux subsystem */
static const struct pinctrl_pin_desc imx25_pinctrl_pads[] = {
IMX_PINCTRL_PIN(MX25_PAD_RESERVE0),
+ IMX_PINCTRL_PIN(MX25_PAD_RESERVE1),
IMX_PINCTRL_PIN(MX25_PAD_A10),
IMX_PINCTRL_PIN(MX25_PAD_A13),
IMX_PINCTRL_PIN(MX25_PAD_A14),
--
1.9.1

2015-11-12 23:40:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 087/155] l2tp: protect tunnel->del_work by ref_count

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

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

From: Alexander Couzens <[email protected]>

[ Upstream commit 06a15f51cf3618e32a73871ee6a547ef7fd902b5 ]

There is a small chance that tunnel_free() is called before tunnel->del_work scheduled
resulting in a zero pointer dereference.

Signed-off-by: Alexander Couzens <[email protected]>
Acked-by: James Chapman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/l2tp/l2tp_core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 895348e..508154a 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1319,7 +1319,7 @@ static void l2tp_tunnel_del_work(struct work_struct *work)
tunnel = container_of(work, struct l2tp_tunnel, del_work);
sk = l2tp_tunnel_sock_lookup(tunnel);
if (!sk)
- return;
+ goto out;

sock = sk->sk_socket;

@@ -1340,6 +1340,8 @@ static void l2tp_tunnel_del_work(struct work_struct *work)
}

l2tp_tunnel_sock_put(sk);
+out:
+ l2tp_tunnel_dec_refcount(tunnel);
}

/* Create a socket for the tunnel, if one isn't set up by
@@ -1639,8 +1641,13 @@ EXPORT_SYMBOL_GPL(l2tp_tunnel_create);
*/
int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel)
{
+ l2tp_tunnel_inc_refcount(tunnel);
l2tp_tunnel_closeall(tunnel);
- return (false == queue_work(l2tp_wq, &tunnel->del_work));
+ if (false == queue_work(l2tp_wq, &tunnel->del_work)) {
+ l2tp_tunnel_dec_refcount(tunnel);
+ return 1;
+ }
+ return 0;
}
EXPORT_SYMBOL_GPL(l2tp_tunnel_delete);

--
1.9.1

2015-11-12 23:19:48

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 088/155] af_unix: Convert the unix_sk macro to an inline function for type safety

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

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

From: Aaron Conole <[email protected]>

[ Upstream commit 4613012db1d911f80897f9446a49de817b2c4c47 ]

As suggested by Eric Dumazet this change replaces the
#define with a static inline function to enjoy
complaints by the compiler when misusing the API.

Signed-off-by: Aaron Conole <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
include/net/af_unix.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a175ba4..dfe4ddf 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -64,7 +64,11 @@ struct unix_sock {
#define UNIX_GC_MAYBE_CYCLE 1
struct socket_wq peer_wq;
};
-#define unix_sk(__sk) ((struct unix_sock *)__sk)
+
+static inline struct unix_sock *unix_sk(struct sock *sk)
+{
+ return (struct unix_sock *)sk;
+}

#define peer_wait peer_wq.wait

--
1.9.1

2015-11-12 23:19:47

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 089/155] af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag

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

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

From: Aaron Conole <[email protected]>

[ Upstream commit 9f389e35674f5b086edd70ed524ca0f287259725 ]

AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag
is set.

This is referenced in kernel bugzilla #12323 @
https://bugzilla.kernel.org/show_bug.cgi?id=12323

As described both in the BZ and lkml thread @
http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an
AF_UNIX socket only reads a single skb, where the desired effect is
to return as much skb data has been queued, until hitting the recv
buffer size (whichever comes first).

The modified MSG_PEEK path will now move to the next skb in the tree
and jump to the again: label, rather than following the natural loop
structure. This requires duplicating some of the loop head actions.

This was tested using the python socketpair python code attached to
the bugzilla issue.

Signed-off-by: Aaron Conole <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/unix/af_unix.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index a8b4284..ca5fa61 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2069,8 +2069,20 @@ again:
if (UNIXCB(skb).fp)
siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);

- sk_peek_offset_fwd(sk, chunk);
+ if (skip) {
+ sk_peek_offset_fwd(sk, chunk);
+ skip -= chunk;
+ }
+
+ if (UNIXCB(skb).fp)
+ break;

+ last = skb;
+ unix_state_lock(sk);
+ skb = skb_peek_next(skb, &sk->sk_receive_queue);
+ if (skb)
+ goto again;
+ unix_state_unlock(sk);
break;
}
} while (size);
--
1.9.1

2015-11-12 23:19:41

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 090/155] net/unix: fix logic about sk_peek_offset

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

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

From: Andrey Vagin <[email protected]>

[ Upstream commit e9193d60d363e4dff75ff6d43a48f22be26d59c7 ]

Now send with MSG_PEEK can return data from multiple SKBs.

Unfortunately we take into account the peek offset for each skb,
that is wrong. We need to apply the peek offset only once.

In addition, the peek offset should be used only if MSG_PEEK is set.

Cc: "David S. Miller" <[email protected]> (maintainer:NETWORKING
Cc: Eric Dumazet <[email protected]> (commit_signer:1/14=7%)
Cc: Aaron Conole <[email protected]>
Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag")
Signed-off-by: Andrey Vagin <[email protected]>
Tested-by: Aaron Conole <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/unix/af_unix.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ca5fa61..6fab713 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1961,6 +1961,11 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
goto out;
}

+ if (flags & MSG_PEEK)
+ skip = sk_peek_offset(sk, flags);
+ else
+ skip = 0;
+
do {
int chunk;
struct sk_buff *skb, *last;
@@ -2007,7 +2012,6 @@ again:
break;
}

- skip = sk_peek_offset(sk, flags);
while (skip >= unix_skb_len(skb)) {
skip -= unix_skb_len(skb);
last = skb;
@@ -2069,14 +2073,12 @@ again:
if (UNIXCB(skb).fp)
siocb->scm->fp = scm_fp_dup(UNIXCB(skb).fp);

- if (skip) {
- sk_peek_offset_fwd(sk, chunk);
- skip -= chunk;
- }
+ sk_peek_offset_fwd(sk, chunk);

if (UNIXCB(skb).fp)
break;

+ skip = 0;
last = skb;
unix_state_lock(sk);
skb = skb_peek_next(skb, &sk->sk_receive_queue);
--
1.9.1

2015-11-12 23:19:45

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 091/155] skbuff: Fix skb checksum flag on skb pull

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

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

From: Pravin B Shelar <[email protected]>

[ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ]

VXLAN device can receive skb with checksum partial. But the checksum
offset could be in outer header which is pulled on receive. This results
in negative checksum offset for the skb. Such skb can cause the assert
failure in skb_checksum_help(). Following patch fixes the bug by setting
checksum-none while pulling outer header.

Following is the kernel panic msg from old kernel hitting the bug.

------------[ cut here ]------------
kernel BUG at net/core/dev.c:1906!
RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
Call Trace:
<IRQ>
[<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
[<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
[<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
[<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
[<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
[<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
[<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
[<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
[<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
[<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
[<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
[<ffffffff81550128>] ip_local_deliver+0x88/0x90
[<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
[<ffffffff81550365>] ip_rcv+0x235/0x300
[<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
[<ffffffff8151c360>] netif_receive_skb+0x80/0x90
[<ffffffff81459935>] virtnet_poll+0x555/0x6f0
[<ffffffff8151cd04>] net_rx_action+0x134/0x290
[<ffffffff810683d8>] __do_softirq+0xa8/0x210
[<ffffffff8162fe6c>] call_softirq+0x1c/0x30
[<ffffffff810161a5>] do_softirq+0x65/0xa0
[<ffffffff810687be>] irq_exit+0x8e/0xb0
[<ffffffff81630733>] do_IRQ+0x63/0xe0
[<ffffffff81625f2e>] common_interrupt+0x6e/0x6e

Reported-by: Anupam Chanda <[email protected]>
Signed-off-by: Pravin B Shelar <[email protected]>
Acked-by: Tom Herbert <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
include/linux/skbuff.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 5fcc606..8271178 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2575,6 +2575,9 @@ static inline void skb_postpull_rcsum(struct sk_buff *skb,
{
if (skb->ip_summed == CHECKSUM_COMPLETE)
skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0));
+ else if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb_checksum_start_offset(skb) <= len)
+ skb->ip_summed = CHECKSUM_NONE;
}

unsigned char *skb_pull_rcsum(struct sk_buff *skb, unsigned int len);
--
1.9.1

2015-11-12 23:19:44

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 092/155] skbuff: Fix skb checksum partial check.

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

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

From: Pravin B Shelar <[email protected]>

[ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ]

Earlier patch 6ae459bda tried to detect void ckecksum partial
skb by comparing pull length to checksum offset. But it does
not work for all cases since checksum-offset depends on
updates to skb->data.

Following patch fixes it by validating checksum start offset
after skb-data pointer is updated. Negative value of checksum
offset start means there is no need to checksum.

Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull")
Reported-by: Andrew Vagin <[email protected]>
Signed-off-by: Pravin B Shelar <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
include/linux/skbuff.h | 2 +-
net/core/skbuff.c | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8271178..b0e064e 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2576,7 +2576,7 @@ static inline void skb_postpull_rcsum(struct sk_buff *skb,
if (skb->ip_summed == CHECKSUM_COMPLETE)
skb->csum = csum_sub(skb->csum, csum_partial(start, len, 0));
else if (skb->ip_summed == CHECKSUM_PARTIAL &&
- skb_checksum_start_offset(skb) <= len)
+ skb_checksum_start_offset(skb) < 0)
skb->ip_summed = CHECKSUM_NONE;
}

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0998af7..ce3b085 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2979,11 +2979,12 @@ EXPORT_SYMBOL(skb_append_datato_frags);
*/
unsigned char *skb_pull_rcsum(struct sk_buff *skb, unsigned int len)
{
+ unsigned char *data = skb->data;
+
BUG_ON(len > skb->len);
- skb->len -= len;
- BUG_ON(skb->len < skb->data_len);
- skb_postpull_rcsum(skb, skb->data, len);
- return skb->data += len;
+ __skb_pull(skb, len);
+ skb_postpull_rcsum(skb, data, len);
+ return skb->data;
}
EXPORT_SYMBOL_GPL(skb_pull_rcsum);

--
1.9.1

2015-11-12 23:19:39

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 093/155] net: add pfmemalloc check in sk_add_backlog()

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit c7c49b8fde26b74277188bdc6c9dca38db6fa35b ]

Greg reported crashes hitting the following check in __sk_backlog_rcv()

BUG_ON(!sock_flag(sk, SOCK_MEMALLOC));

The pfmemalloc bit is currently checked in sk_filter().

This works correctly for TCP, because sk_filter() is ran in
tcp_v[46]_rcv() before hitting the prequeue or backlog checks.

For UDP or other protocols, this does not work, because the sk_filter()
is ran from sock_queue_rcv_skb(), which might be called _after_ backlog
queuing if socket is owned by user by the time packet is processed by
softirq handler.

Fixes: b4b9e35585089 ("netvm: set PF_MEMALLOC as appropriate during SKB processing")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Greg Thelen <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
include/net/sock.h | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/include/net/sock.h b/include/net/sock.h
index 45b54d3..173743e 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -825,6 +825,14 @@ static inline __must_check int sk_add_backlog(struct sock *sk, struct sk_buff *s
if (sk_rcvqueues_full(sk, limit))
return -ENOBUFS;

+ /*
+ * If the skb was allocated from pfmemalloc reserves, only
+ * allow SOCK_MEMALLOC sockets to use it as this socket is
+ * helping free memory
+ */
+ if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC))
+ return -ENOMEM;
+
__sk_add_backlog(sk, skb);
sk->sk_backlog.len += skb->truesize;
return 0;
--
1.9.1

2015-11-12 23:40:01

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 094/155] ppp: don't override sk->sk_state in pppoe_flush_dev()

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

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

From: Guillaume Nault <[email protected]>

[ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ]

Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
following oops:

[ 570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
[ 570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[ 570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
[ 570.144601] Oops: 0000 [#1] SMP
[ 570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
[ 570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
[ 570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
[ 570.144601] RIP: 0010:[<ffffffffa018c701>] [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[ 570.144601] RSP: 0018:ffff880036b63e08 EFLAGS: 00010202
[ 570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
[ 570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
[ 570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
[ 570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
[ 570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
[ 570.144601] FS: 00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
[ 570.144601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
[ 570.144601] Stack:
[ 570.144601] ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
[ 570.144601] ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
[ 570.144601] ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
[ 570.144601] Call Trace:
[ 570.144601] [<ffffffff812caabe>] sock_release+0x1a/0x75
[ 570.144601] [<ffffffff812cabad>] sock_close+0xd/0x11
[ 570.144601] [<ffffffff811347f5>] __fput+0xff/0x1a5
[ 570.144601] [<ffffffff811348cb>] ____fput+0x9/0xb
[ 570.144601] [<ffffffff81056682>] task_work_run+0x66/0x90
[ 570.144601] [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
[ 570.144601] [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
[ 570.144601] [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
[ 570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
[ 570.144601] RIP [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[ 570.144601] RSP <ffff880036b63e08>
[ 570.144601] CR2: 00000000000004e0
[ 570.200518] ---[ end trace 46956baf17349563 ]---

pppoe_flush_dev() has no reason to override sk->sk_state with
PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
PPPOX_DEAD, which is the correct state given that sk is unbound and
po->pppoe_dev is NULL.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Tested-by: Oleksii Berezhniak <[email protected]>
Signed-off-by: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/ppp/pppoe.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index d2408a5..84f5584 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -313,7 +313,6 @@ static void pppoe_flush_dev(struct net_device *dev)
if (po->pppoe_dev == dev &&
sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {
pppox_unbind_sock(sk);
- sk->sk_state = PPPOX_ZOMBIE;
sk->sk_state_change(sk);
po->pppoe_dev = NULL;
dev_put(dev);
--
1.9.1

2015-11-12 23:40:00

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 095/155] ovs: do not allocate memory from offline numa node

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

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

From: Konstantin Khlebnikov <[email protected]>

[ Upstream commit 598c12d0ba6de9060f04999746eb1e015774044b ]

When openvswitch tries allocate memory from offline numa node 0:
stats = kmem_cache_alloc_node(flow_stats_cache, GFP_KERNEL | __GFP_ZERO, 0)
It catches VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid))
[ replaced with VM_WARN_ON(!node_online(nid)) recently ] in linux/gfp.h
This patch disables numa affinity in this case.

Signed-off-by: Konstantin Khlebnikov <[email protected]>
Acked-by: Pravin B Shelar <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/openvswitch/flow_table.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 514c6233..1124365 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -90,7 +90,8 @@ struct sw_flow *ovs_flow_alloc(void)

/* Initialize the default stat node. */
stats = kmem_cache_alloc_node(flow_stats_cache,
- GFP_KERNEL | __GFP_ZERO, 0);
+ GFP_KERNEL | __GFP_ZERO,
+ node_online(0) ? 0 : NUMA_NO_NODE);
if (!stats)
goto err;

--
1.9.1

2015-11-12 23:37:32

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 096/155] ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings

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

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

From: Joe Perches <[email protected]>

[ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ]

It seems that kernel memory can leak into userspace by a
kmalloc, ethtool_get_strings, then copy_to_user sequence.

Avoid this by using kcalloc to zero fill the copied buffer.

Signed-off-by: Joe Perches <[email protected]>
Acked-by: Ben Hutchings <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/core/ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 550892c..0a62917 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1272,7 +1272,7 @@ static int ethtool_get_strings(struct net_device *dev, void __user *useraddr)

gstrings.len = ret;

- data = kmalloc(gstrings.len * ETH_GSTRING_LEN, GFP_USER);
+ data = kcalloc(gstrings.len, ETH_GSTRING_LEN, GFP_USER);
if (!data)
return -ENOMEM;

--
1.9.1

2015-11-12 23:37:31

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 097/155] netlink: Trim skb to alloc size to avoid MSG_TRUNC

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

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

From: "Arad, Ronen" <[email protected]>

[ Upstream commit db65a3aaf29ecce2e34271d52e8d2336b97bd9fe ]

netlink_dump() allocates skb based on the calculated min_dump_alloc or
a per socket max_recvmsg_len.
min_alloc_size is maximum space required for any single netdev
attributes as calculated by rtnl_calcit().
max_recvmsg_len tracks the user provided buffer to netlink_recvmsg.
It is capped at 16KiB.
The intention is to avoid small allocations and to minimize the number
of calls required to obtain dump information for all net devices.

netlink_dump packs as many small messages as could fit within an skb
that was sized for the largest single netdev information. The actual
space available within an skb is larger than what is requested. It could
be much larger and up to near 2x with align to next power of 2 approach.

Allowing netlink_dump to use all the space available within the
allocated skb increases the buffer size a user has to provide to avoid
truncaion (i.e. MSG_TRUNG flag set).

It was observed that with many VLANs configured on at least one netdev,
a larger buffer of near 64KiB was necessary to avoid "Message truncated"
error in "ip link" or "bridge [-c[ompressvlans]] vlan show" when
min_alloc_size was only little over 32KiB.

This patch trims skb to allocated size in order to allow the user to
avoid truncation with more reasonable buffer size.

Signed-off-by: Ronen Arad <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/netlink/af_netlink.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4e37b2a..d78848d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2657,6 +2657,7 @@ static int netlink_dump(struct sock *sk)
struct sk_buff *skb = NULL;
struct nlmsghdr *nlh;
int len, err = -ENOBUFS;
+ int alloc_min_size;
int alloc_size;

mutex_lock(nlk->cb_mutex);
@@ -2665,9 +2666,6 @@ static int netlink_dump(struct sock *sk)
goto errout_skb;
}

- cb = &nlk->cb;
- alloc_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
-
if (!netlink_rx_is_mmaped(sk) &&
atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
goto errout_skb;
@@ -2677,23 +2675,35 @@ static int netlink_dump(struct sock *sk)
* to reduce number of system calls on dump operations, if user
* ever provided a big enough buffer.
*/
- if (alloc_size < nlk->max_recvmsg_len) {
- skb = netlink_alloc_skb(sk,
- nlk->max_recvmsg_len,
- nlk->portid,
+ cb = &nlk->cb;
+ alloc_min_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
+
+ if (alloc_min_size < nlk->max_recvmsg_len) {
+ alloc_size = nlk->max_recvmsg_len;
+ skb = netlink_alloc_skb(sk, alloc_size, nlk->portid,
GFP_KERNEL |
__GFP_NOWARN |
__GFP_NORETRY);
- /* available room should be exact amount to avoid MSG_TRUNC */
- if (skb)
- skb_reserve(skb, skb_tailroom(skb) -
- nlk->max_recvmsg_len);
}
- if (!skb)
+ if (!skb) {
+ alloc_size = alloc_min_size;
skb = netlink_alloc_skb(sk, alloc_size, nlk->portid,
GFP_KERNEL);
+ }
if (!skb)
goto errout_skb;
+
+ /* Trim skb to allocated size. User is expected to provide buffer as
+ * large as max(min_dump_alloc, 16KiB (mac_recvmsg_len capped at
+ * netlink_recvmsg())). dump will pack as many smaller messages as
+ * could fit within the allocated skb. skb is typically allocated
+ * with larger space than required (could be as much as near 2x the
+ * requested size with align to next power of 2 approach). Allowing
+ * dump to use the excess space makes it difficult for a user to have a
+ * reasonable static buffer based on the expected largest dump of a
+ * single netdev. The outcome is MSG_TRUNC error.
+ */
+ skb_reserve(skb, skb_tailroom(skb) - alloc_size);
netlink_skb_set_owner_r(skb, sk);

len = cb->dump(skb, cb);
--
1.9.1

2015-11-12 23:37:29

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 098/155] ath9k: declare required extra tx headroom

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

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

From: Felix Fietkau <[email protected]>

commit 029cd0370241641eb70235d205aa0b90c84dce44 upstream.

ath9k inserts padding between the 802.11 header and the data area (to
align it). Since it didn't declare this extra required headroom, this
led to some nasty issues like randomly dropped packets in some setups.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/ath/ath9k/init.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index d1c3934..82d4f0a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -855,6 +855,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
hw->max_rate_tries = 10;
hw->sta_data_size = sizeof(struct ath_node);
hw->vif_data_size = sizeof(struct ath_vif);
+ hw->extra_tx_headroom = 4;

hw->wiphy->available_antennas_rx = BIT(ah->caps.max_rxchains) - 1;
hw->wiphy->available_antennas_tx = BIT(ah->caps.max_txchains) - 1;
--
1.9.1

2015-11-12 23:37:24

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 099/155] iio: accel: sca3000: memory corruption in sca3000_read_first_n_hw_rb()

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

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

From: Dan Carpenter <[email protected]>

commit eda7d0f38aaf50dbb2a2de15e8db386c4f6f65fc upstream.

"num_read" is in byte units but we are write u16s so we end up write
twice as much as intended.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/staging/iio/accel/sca3000_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/accel/sca3000_ring.c b/drivers/staging/iio/accel/sca3000_ring.c
index 1578276..17306a9 100644
--- a/drivers/staging/iio/accel/sca3000_ring.c
+++ b/drivers/staging/iio/accel/sca3000_ring.c
@@ -116,7 +116,7 @@ static int sca3000_read_first_n_hw_rb(struct iio_buffer *r,
if (ret)
goto error_ret;

- for (i = 0; i < num_read; i++)
+ for (i = 0; i < num_read / sizeof(u16); i++)
*(((u16 *)rx) + i) = be16_to_cpup((__be16 *)rx + i);

if (copy_to_user(buf, rx, num_read))
--
1.9.1

2015-11-12 23:37:30

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 100/155] iwlwifi: dvm: fix D3 firmware PN programming

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

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

From: Johannes Berg <[email protected]>

commit 5bd166872d8f99f156fac191299d24f828bb2348 upstream.

The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/dvm/lib.c b/drivers/net/wireless/iwlwifi/dvm/lib.c
index 1d2223d..e7d3566 100644
--- a/drivers/net/wireless/iwlwifi/dvm/lib.c
+++ b/drivers/net/wireless/iwlwifi/dvm/lib.c
@@ -1022,7 +1022,7 @@ static void iwlagn_wowlan_program_keys(struct ieee80211_hw *hw,
u8 *pn = seq.ccmp.pn;

ieee80211_get_key_rx_seq(key, i, &seq);
- aes_sc->pn = cpu_to_le64(
+ aes_sc[i].pn = cpu_to_le64(
(u64)pn[5] |
((u64)pn[4] << 8) |
((u64)pn[3] << 16) |
--
1.9.1

2015-11-12 23:37:27

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 101/155] iwlwifi: mvm: fix D3 firmware PN programming

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

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

From: Johannes Berg <[email protected]>

commit 2cf5eb3ab7bb7f2e3a70edcef236cd62c87db030 upstream.

The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/iwlwifi/mvm/d3.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/d3.c b/drivers/net/wireless/iwlwifi/mvm/d3.c
index 185ff7b..0586266 100644
--- a/drivers/net/wireless/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/iwlwifi/mvm/d3.c
@@ -298,12 +298,12 @@ static void iwl_mvm_wowlan_program_keys(struct ieee80211_hw *hw,
u8 *pn = seq.ccmp.pn;

ieee80211_get_key_rx_seq(key, i, &seq);
- aes_sc->pn = cpu_to_le64((u64)pn[5] |
- ((u64)pn[4] << 8) |
- ((u64)pn[3] << 16) |
- ((u64)pn[2] << 24) |
- ((u64)pn[1] << 32) |
- ((u64)pn[0] << 40));
+ aes_sc[i].pn = cpu_to_le64((u64)pn[5] |
+ ((u64)pn[4] << 8) |
+ ((u64)pn[3] << 16) |
+ ((u64)pn[2] << 24) |
+ ((u64)pn[1] << 32) |
+ ((u64)pn[0] << 40));
}
data->use_rsc_tsc = true;
break;
--
1.9.1

2015-11-12 23:37:26

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 102/155] iwlwifi: mvm: clear csa countdown when AP is stopped

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

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

From: Avraham Stern <[email protected]>

commit e9cb0327b26dd7ba43a3b7a05b4b62219decf42d upstream.

The csa_countdown flag was not cleared when the AP is stopped.
As a result, if the AP was stopped after csa_countdown had started,
all the folowing channel switch commands would fail.
Fix that by clearing the csa_countdown flag when the AP is stopped.

Signed-off-by: Avraham Stern <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 7b0d757..ba2b6f5 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -1818,6 +1818,7 @@ static void iwl_mvm_stop_ap_ibss(struct ieee80211_hw *hw,
iwl_mvm_remove_time_event(mvm, mvmvif,
&mvmvif->time_event_data);
RCU_INIT_POINTER(mvm->csa_vif, NULL);
+ mvmvif->csa_countdown = false;
}

if (rcu_access_pointer(mvm->csa_tx_blocked_vif) == vif) {
--
1.9.1

2015-11-12 23:37:22

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 103/155] iwlwifi: fix firmware filename for 3160

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

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

From: Johannes Berg <[email protected]>

commit b5a48134f8af08f5243328f8a0b05fc5ae7cf343 upstream.

The MODULE_FIRMWARE() for 3160 should be using the 7260 version as
it's done in the device configuration struct instead of referencing
IWL3160_UCODE_API_OK which doesn't even exist.

Reported-by: Hauke Mehrtens <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/iwlwifi/iwl-7000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-7000.c b/drivers/net/wireless/iwlwifi/iwl-7000.c
index a5f9198..b5651a2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-7000.c
@@ -303,7 +303,7 @@ const struct iwl_cfg iwl7265d_n_cfg = {
};

MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
-MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3160_UCODE_API_OK));
+MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
MODULE_FIRMWARE(IWL3165_MODULE_FIRMWARE(IWL3160_UCODE_API_OK));
MODULE_FIRMWARE(IWL7265_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
MODULE_FIRMWARE(IWL7265D_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
--
1.9.1

2015-11-12 23:36:56

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 104/155] iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series

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

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

From: Luca Coelho <[email protected]>

commit f08f625876476b6c4a87834dc86e3b927f4697d2 upstream.

Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B
device ID.

Reported-by: Jeremy <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/iwlwifi/pcie/drv.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/iwlwifi/pcie/drv.c b/drivers/net/wireless/iwlwifi/pcie/drv.c
index d5aadb0..e663f10 100644
--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -410,6 +410,11 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x095A, 0x5590, iwl7265_2ac_cfg)},
{IWL_PCI_DEVICE(0x095B, 0x5290, iwl7265_2ac_cfg)},
{IWL_PCI_DEVICE(0x095A, 0x5490, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095A, 0x5F10, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095B, 0x5212, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095B, 0x520A, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095A, 0x9000, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095A, 0x9400, iwl7265_2ac_cfg)},

/* 8000 Series */
{IWL_PCI_DEVICE(0x24F3, 0x0010, iwl8260_2ac_cfg)},
--
1.9.1

2015-11-12 23:36:20

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 105/155] iwlwifi: mvm: init card correctly on ctkill exit check

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

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

From: Arik Nemtsov <[email protected]>

commit 1a3fe0b2b6778b7866e2b3f5c9a299d5e9bbd89c upstream.

During the CT-kill exit flow, the card is powered up and partially
initialized to check if the temperature is already low enough.
Unfortunately the init bails early because the CT-kill flag is set.
Make the code bail early only for HW RF-kill, as was intended by the
author. CT-kill is self-imposed and is not really RF-kill.

Fixes: 31b8b343e019 ("iwlwifi: fix RFkill while calibrating")
Signed-off-by: Arik Nemtsov <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/wireless/iwlwifi/mvm/fw.c | 4 ++--
drivers/net/wireless/iwlwifi/mvm/mvm.h | 5 +++++
2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/fw.c b/drivers/net/wireless/iwlwifi/mvm/fw.c
index d0fa6e9..b33d80b 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/iwlwifi/mvm/fw.c
@@ -335,7 +335,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool read_nvm)
* abort after reading the nvm in case RF Kill is on, we will complete
* the init seq later when RF kill will switch to off
*/
- if (iwl_mvm_is_radio_killed(mvm)) {
+ if (iwl_mvm_is_radio_hw_killed(mvm)) {
IWL_DEBUG_RF_KILL(mvm,
"jump over all phy activities due to RF kill\n");
iwl_remove_notification(&mvm->notif_wait, &calib_wait);
@@ -370,7 +370,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool read_nvm)
if (!ret)
mvm->init_ucode_complete = true;

- if (ret && iwl_mvm_is_radio_killed(mvm)) {
+ if (ret && iwl_mvm_is_radio_hw_killed(mvm)) {
IWL_DEBUG_RF_KILL(mvm, "RFKILL while calibrating.\n");
ret = 1;
}
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index a5db114..a17808a 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -810,6 +810,11 @@ static inline bool iwl_mvm_is_radio_killed(struct iwl_mvm *mvm)
test_bit(IWL_MVM_STATUS_HW_CTKILL, &mvm->status);
}

+static inline bool iwl_mvm_is_radio_hw_killed(struct iwl_mvm *mvm)
+{
+ return test_bit(IWL_MVM_STATUS_HW_RFKILL, &mvm->status);
+}
+
/* Must be called with rcu_read_lock() held and it can only be
* released when mvmsta is not needed anymore.
*/
--
1.9.1

2015-11-12 23:36:18

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 106/155] ARM: orion: Fix DSA platform device after mvmdio conversion

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

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

From: Florian Fainelli <[email protected]>

commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream.

DSA expects the host_dev pointer to be the device structure associated
with the MDIO bus controller driver. First commit breaking that was
c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO
driver"), and then, it got completely under the radar for a while.

Reported-by: Frans van de Wiel <[email protected]>
Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm/plat-orion/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index f5b00f4..b8b6e22 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -499,7 +499,7 @@ void __init orion_ge00_switch_init(struct dsa_platform_data *d, int irq)

d->netdev = &orion_ge00.dev;
for (i = 0; i < d->nr_chips; i++)
- d->chip[i].host_dev = &orion_ge00_shared.dev;
+ d->chip[i].host_dev = &orion_ge_mvmdio.dev;
orion_switch_device.dev.platform_data = d;

platform_device_register(&orion_switch_device);
--
1.9.1

2015-11-12 23:35:36

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 107/155] xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

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

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

From: Cathy Avery <[email protected]>

commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream.

xen-blkfront will crash if the check to talk_to_blkback()
in blkback_changed()(XenbusStateInitWait) returns an error.
The driver data is freed and info is set to NULL. Later during
the close process via talk_to_blkback's call to xenbus_dev_fatal()
the null pointer is passed to and dereference in blkfront_closing.

Signed-off-by: Cathy Avery <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/block/xen-blkfront.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 7afb9ed..6259acc 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1924,7 +1924,8 @@ static void blkback_changed(struct xenbus_device *dev,
break;
/* Missed the backend's Closing state -- fallthrough */
case XenbusStateClosing:
- blkfront_closing(info);
+ if (info)
+ blkfront_closing(info);
break;
}
}
--
1.9.1

2015-11-12 23:35:34

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 108/155] iio: mxs-lradc: Fix temperature offset

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

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

From: Alexandre Belloni <[email protected]>

commit b94e22805a2224061bb263a82b72e09544a5fbb3 upstream.

0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset.
Also improve the comment explaining the calculation.

Reported-by: Janusz Użycki <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Acked-by: Stefan Wahren <[email protected]>
Acked-by: Marek Vasut <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/staging/iio/adc/mxs-lradc.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/adc/mxs-lradc.c b/drivers/staging/iio/adc/mxs-lradc.c
index 351339c..3b9859b 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -912,11 +912,12 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
case IIO_CHAN_INFO_OFFSET:
if (chan->type == IIO_TEMP) {
/* The calculated value from the ADC is in Kelvin, we
- * want Celsius for hwmon so the offset is
- * -272.15 * scale
+ * want Celsius for hwmon so the offset is -273.15
+ * The offset is applied before scaling so it is
+ * actually -213.15 * 4 / 1.012 = -1079.644268
*/
- *val = -1075;
- *val2 = 691699;
+ *val = -1079;
+ *val2 = 644268;

return IIO_VAL_INT_PLUS_MICRO;
}
--
1.9.1

2015-11-12 23:33:07

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 109/155] ARM: dts: Fix audio card detection on Peach boards

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

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

From: Alim Akhtar <[email protected]>

commit b8bb9baad27e455c467e8fac47eebadbe765c18f upstream.

Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
sound card detection is broken on peach boards and gives below errors:

[ 3.630457] max98090 7-0010: MAX98091 REVID=0x51
[ 3.634233] max98090 7-0010: use default 2.8v micbias
[ 3.640985] snow-audio sound: HiFi <-> 3830000.i2s mapping ok
[ 3.645307] max98090 7-0010: Invalid master clock frequency
[ 3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() failed: -22
[ 3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[ 3.664366] snow-audio: probe of sound failed with error -22

This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.

Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
Signed-off-by: Alim Akhtar <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 +++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +++++
2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 9a050e1..b76c197 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -726,6 +726,11 @@
};
};

+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index e8fdda8..30159e3 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -714,6 +714,11 @@
};
};

+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
--
1.9.1

2015-11-12 23:35:05

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 110/155] ALSA: hda - Fix inverted internal mic on Lenovo G50-80

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

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

From: David Henningsson <[email protected]>

commit e8d65a8d985271a102f07c7456da5b86c19ffe16 upstream.

Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo
mic input where one channel has reverse polarity.

Alsa-info available at:
https://launchpadlibrarian.net/220846272/AlsaInfo.txt

BugLink: https://bugs.launchpad.net/bugs/1504778
Signed-off-by: David Henningsson <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
sound/pci/hda/patch_conexant.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index e27298b..7085fb9 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -803,6 +803,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410),
SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD),
+ SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC),
--
1.9.1

2015-11-12 23:33:57

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 111/155] drm/i915: Flush pipecontrol post-sync writes

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

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

From: Chris Wilson <[email protected]>

commit 40a24488f5250d63341e74b9994159afc4589606 upstream.

In order to flush the results from in-batch pipecontrol writes (used for
example in glQuery) before declaring the batch complete (and so declaring
the query results coherent), we need to set the FlushEnable bit in our
flushing pipecontrol. The FlushEnable bit "waits until all previous
writes of immediate data from post-sync circles are complete before
executing the next command".

I get GPU hangs on byt without flushing these writes (running ue4).
piglit has examples where the flush is required for correct rendering.

Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/i915/intel_lrc.c | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2c5c00c..ae4e895 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1277,6 +1277,7 @@ static int gen8_emit_flush_render(struct intel_ringbuffer *ringbuf,
if (flush_domains) {
flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_FLUSH_ENABLE;
}

if (invalidate_domains) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a335b84..2355411 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -354,6 +354,7 @@ gen7_render_ring_flush(struct intel_engine_cs *ring,
if (flush_domains) {
flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_FLUSH_ENABLE;
}
if (invalidate_domains) {
flags |= PIPE_CONTROL_TLB_INVALIDATE;
@@ -427,6 +428,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
if (flush_domains) {
flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_FLUSH_ENABLE;
}
if (invalidate_domains) {
flags |= PIPE_CONTROL_TLB_INVALIDATE;
--
1.9.1

2015-11-12 23:33:05

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 112/155] drm/i915: Restore lost DPLL register write on gen2-4

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

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

From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <[email protected]>

commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 upstream.

We accidentally lost the initial DPLL register write in
1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M

The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.

Reported-and-tested-by: Nick Bowler <[email protected]>
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: Nick Bowler <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ada0210..a67dde0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1623,6 +1623,8 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
I915_READ(DPLL(!crtc->pipe)) | DPLL_DVO_2X_MODE);
}

+ I915_WRITE(reg, dpll);
+
/* Wait for the clocks to stabilize. */
POSTING_READ(reg);
udelay(150);
--
1.9.1

2015-11-12 23:33:55

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 113/155] drm/i915: Deny wrapping an userptr into a framebuffer

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

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

From: Chris Wilson <[email protected]>

commit cc917ab43541db3ff66d0136042686d40a1b4c9a upstream.

Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.

Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Michał Winiarski <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 5 ++++-
drivers/gpu/drm/i915/intel_display.c | 5 +++++
2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 1719078..ce175d0 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -776,7 +776,10 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
* Also note, that the object created here is not currently a "first class"
* object, in that several ioctls are banned. These are the CPU access
* ioctls: mmap(), pwrite and pread. In practice, you are expected to use
- * direct access via your pointer rather than use those ioctls.
+ * direct access via your pointer rather than use those ioctls. Another
+ * restriction is that we do not allow userptr surfaces to be pinned to the
+ * hardware and so we reject any attempt to create a framebuffer out of a
+ * userptr.
*
* If you think this is a good interface to use to pass GPU memory between
* drivers, please use dma-buf instead. In fact, wherever possible use
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index a67dde0..66adee1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12595,6 +12595,11 @@ static int intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;

+ if (obj->userptr.mm) {
+ DRM_DEBUG("attempting to use a userptr for a framebuffer, denied\n");
+ return -EINVAL;
+ }
+
return drm_gem_handle_create(file, &obj->base, handle);
}

--
1.9.1

2015-11-12 23:33:04

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 114/155] iommu/vt-d: fix range computation when making room for large pages

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

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

From: Christian Zander <[email protected]>

commit ba2374fd2bf379f933773811fdb06cb6a5445f41 upstream.

In preparation for the installation of a large page, any small page
tables that may still exist in the target IOV address range are
removed. However, if a scatter/gather list entry is large enough to
fit more than one large page, the address space for any subsequent
large pages is not cleared of conflicting small page tables.

This can cause legitimate mapping requests to fail with errors of the
form below, potentially followed by a series of IOMMU faults:

ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083)

In this example, a 4MiB scatter/gather list entry resulted in the
successful installation of a large page @ vPFN 0xfdc00, followed by
a failed attempt to install another large page @ vPFN 0xfde00, due to
the presence of a pointer to a small page table @ 0x7f83a4000.

To address this problem, compute the number of large pages that fit
into a given scatter/gather list entry, and use it to derive the
last vPFN covered by the large page(s).

Signed-off-by: Christian Zander <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/iommu/intel-iommu.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0688303..3583db4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2032,15 +2032,19 @@ static int __domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
return -ENOMEM;
/* It is large page*/
if (largepage_lvl > 1) {
+ unsigned long nr_superpages, end_pfn;
+
pteval |= DMA_PTE_LARGE_PAGE;
lvl_pages = lvl_to_nr_pages(largepage_lvl);
+
+ nr_superpages = sg_res / lvl_pages;
+ end_pfn = iov_pfn + nr_superpages * lvl_pages - 1;
+
/*
* Ensure that old small page tables are
- * removed to make room for superpage,
- * if they exist.
+ * removed to make room for superpage(s).
*/
- dma_pte_free_pagetable(domain, iov_pfn,
- iov_pfn + lvl_pages - 1);
+ dma_pte_free_pagetable(domain, iov_pfn, end_pfn);
} else {
pteval &= ~(uint64_t)DMA_PTE_LARGE_PAGE;
}
--
1.9.1

2015-11-12 23:19:53

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 115/155] x86/efi: Fix multiple GOP device support

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

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

From: =?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?=

commit 8a53554e12e98d1759205afd7b8e9e2ea0936f48 upstream.

When multiple GOP devices exists, but none of them implements
ConOut, the code should just choose the first GOP (according to
the comments). But currently 'fb_base' will refer to the last GOP,
while other parameters to the first GOP, which will likely
result in a garbled display.

I can reliably reproduce this bug using my ASRock Z87M Extreme4
motherboard with CSM and integrated GPU disabled, and two PCIe
video cards (NVidia GT640 and GTX980), booting from efi-stub
(booting from grub works fine). On the primary display the
ASRock logo remains and on the secondary screen it is garbled
up completely.

Signed-off-by: Kővágó, Zoltán <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/boot/compressed/eboot.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b451033..7a4e75f 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -668,6 +668,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
bool conout_found = false;
void *dummy = NULL;
u32 h = handles[i];
+ u32 current_fb_base;

status = efi_call_early(handle_protocol, h,
proto, (void **)&gop32);
@@ -679,7 +680,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
if (status == EFI_SUCCESS)
conout_found = true;

- status = __gop_query32(gop32, &info, &size, &fb_base);
+ status = __gop_query32(gop32, &info, &size, &current_fb_base);
if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
/*
* Systems that use the UEFI Console Splitter may
@@ -693,6 +694,7 @@ setup_gop32(struct screen_info *si, efi_guid_t *proto,
pixel_format = info->pixel_format;
pixel_info = info->pixel_information;
pixels_per_scan_line = info->pixels_per_scan_line;
+ fb_base = current_fb_base;

/*
* Once we've found a GOP supporting ConOut,
@@ -771,6 +773,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
bool conout_found = false;
void *dummy = NULL;
u64 h = handles[i];
+ u32 current_fb_base;

status = efi_call_early(handle_protocol, h,
proto, (void **)&gop64);
@@ -782,7 +785,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
if (status == EFI_SUCCESS)
conout_found = true;

- status = __gop_query64(gop64, &info, &size, &fb_base);
+ status = __gop_query64(gop64, &info, &size, &current_fb_base);
if (status == EFI_SUCCESS && (!first_gop || conout_found)) {
/*
* Systems that use the UEFI Console Splitter may
@@ -796,6 +799,7 @@ setup_gop64(struct screen_info *si, efi_guid_t *proto,
pixel_format = info->pixel_format;
pixel_info = info->pixel_information;
pixels_per_scan_line = info->pixels_per_scan_line;
+ fb_base = current_fb_base;

/*
* Once we've found a GOP supporting ConOut,
--
1.9.1

2015-11-12 23:24:49

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 116/155] x86/setup: Extend low identity map to cover whole kernel range

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

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

From: Paolo Bonzini <[email protected]>

commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.

On 32-bit systems, the initial_page_table is reused by
efi_call_phys_prolog as an identity map to call
SetVirtualAddressMap. efi_call_phys_prolog takes care of
converting the current CPU's GDT to a physical address too.

For PAE kernels the identity mapping is achieved by aliasing the
first PDPE for the kernel memory mapping into the first PDPE
of initial_page_table. This makes the EFI stub's trick "just work".

However, for non-PAE kernels there is no guarantee that the identity
mapping in the initial_page_table extends as far as the GDT; in this
case, accesses to the GDT will cause a page fault (which quickly becomes
a triple fault). Fix this by copying the kernel mappings from
swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
identity mapping.

For some reason, this is only reproducible with QEMU's dynamic translation
mode, and not for example with KVM. However, even under KVM one can clearly
see that the page table is bogus:

$ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
$ gdb
(gdb) target remote localhost:1234
(gdb) hb *0x02858f6f
Hardware assisted breakpoint 1 at 0x2858f6f
(gdb) c
Continuing.

Breakpoint 1, 0x02858f6f in ?? ()
(gdb) monitor info registers
...
GDT= 0724e000 000000ff
IDT= fffbb000 000007ff
CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
...

The page directory is sane:

(gdb) x/4wx 0x32b7000
0x32b7000: 0x03398063 0x03399063 0x0339a063 0x0339b063
(gdb) x/4wx 0x3398000
0x3398000: 0x00000163 0x00001163 0x00002163 0x00003163
(gdb) x/4wx 0x3399000
0x3399000: 0x00400003 0x00401003 0x00402003 0x00403003

but our particular page directory entry is empty:

(gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
0x32b7070: 0x00000000

[ It appears that you can skate past this issue if you don't receive
any interrupts while the bogus GDT pointer is loaded, or if you avoid
reloading the segment registers in general.

Andy Lutomirski provides some additional insight:

"AFAICT it's entirely permissible for the GDTR and/or LDT
descriptor to point to unmapped memory. Any attempt to use them
(segment loads, interrupts, IRET, etc) will try to access that memory
as if the access came from CPL 0 and, if the access fails, will
generate a valid page fault with CR2 pointing into the GDT or
LDT."

Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
calls, not in the epilog/prolog calls") interrupts were disabled
around the prolog and epilog calls, and the functional GDT was
re-installed before interrupts were re-enabled.

Which explains why no one has hit this issue until now. ]

Signed-off-by: Paolo Bonzini <[email protected]>
Reported-by: Laszlo Ersek <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
[ Updated changelog. ]
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/kernel/setup.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ab4734e..5f660ca 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1188,6 +1188,14 @@ void __init setup_arch(char **cmdline_p)
clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY,
swapper_pg_dir + KERNEL_PGD_BOUNDARY,
KERNEL_PGD_PTRS);
+
+ /*
+ * sync back low identity map too. It is used for example
+ * in the 32-bit EFI stub.
+ */
+ clone_pgd_range(initial_page_table,
+ swapper_pg_dir + KERNEL_PGD_BOUNDARY,
+ KERNEL_PGD_PTRS);
#endif

tboot_probe();
--
1.9.1

2015-11-12 23:31:50

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 117/155] ASoC: Add info callback for SX_TLV controls

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

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

From: Charles Keepax <[email protected]>

commit 34198710f55b5f359f43e67d9a08fe5aadfbca1b upstream.

SX_TLV controls are intended for situations where the register behind
the control has some non-zero value indicating the minimum gain
and then gains increasing from there and eventually overflowing through
zero.

Currently every CODEC implementing these controls specifies the minimum
as the non-zero value for the minimum and the maximum as the number of
gain settings available.

This means when the info callback subtracts the minimum value from the
maximum value to calculate the number of gain levels available it is
actually under reporting the available levels. This patch fixes this
issue by adding a new snd_soc_info_volsw_sx callback that does not
subtract the minimum value.

Fixes: 1d99f2436d0d ("ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV")
Signed-off-by: Charles Keepax <[email protected]>
Acked-by: Brian Austin <[email protected]>
Tested-by: Brian Austin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
include/sound/soc.h | 6 ++++--
sound/soc/soc-ops.c | 28 ++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index ac8b333..c62fcf8 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -85,7 +85,7 @@
.access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | \
SNDRV_CTL_ELEM_ACCESS_READWRITE, \
.tlv.p = (tlv_array),\
- .info = snd_soc_info_volsw, \
+ .info = snd_soc_info_volsw_sx, \
.get = snd_soc_get_volsw_sx,\
.put = snd_soc_put_volsw_sx, \
.private_value = (unsigned long)&(struct soc_mixer_control) \
@@ -155,7 +155,7 @@
.access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | \
SNDRV_CTL_ELEM_ACCESS_READWRITE, \
.tlv.p = (tlv_array), \
- .info = snd_soc_info_volsw, \
+ .info = snd_soc_info_volsw_sx, \
.get = snd_soc_get_volsw_sx, \
.put = snd_soc_put_volsw_sx, \
.private_value = (unsigned long)&(struct soc_mixer_control) \
@@ -546,6 +546,8 @@ int snd_soc_put_enum_double(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol);
int snd_soc_info_volsw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo);
+int snd_soc_info_volsw_sx(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_info *uinfo);
#define snd_soc_info_bool_ext snd_ctl_boolean_mono_info
int snd_soc_get_volsw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol);
diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
index 100d92b..05977ae 100644
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -207,6 +207,34 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol,
EXPORT_SYMBOL_GPL(snd_soc_info_volsw);

/**
+ * snd_soc_info_volsw_sx - Mixer info callback for SX TLV controls
+ * @kcontrol: mixer control
+ * @uinfo: control element information
+ *
+ * Callback to provide information about a single mixer control, or a double
+ * mixer control that spans 2 registers of the SX TLV type. SX TLV controls
+ * have a range that represents both positive and negative values either side
+ * of zero but without a sign bit.
+ *
+ * Returns 0 for success.
+ */
+int snd_soc_info_volsw_sx(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_info *uinfo)
+{
+ struct soc_mixer_control *mc =
+ (struct soc_mixer_control *)kcontrol->private_value;
+
+ snd_soc_info_volsw(kcontrol, uinfo);
+ /* Max represents the number of levels in an SX control not the
+ * maximum value, so add the minimum value back on
+ */
+ uinfo->value.integer.max += mc->min;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_info_volsw_sx);
+
+/**
* snd_soc_get_volsw - single mixer get callback
* @kcontrol: mixer control
* @ucontrol: control element information
--
1.9.1

2015-11-12 23:32:28

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 118/155] xhci: don't finish a TD if we get a short transfer event mid TD

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

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

From: Mathias Nyman <[email protected]>

commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream.

If the difference is big enough between the bytes asked and received
in a bulk transfer we can get a short transfer event pointing to a TRB in
the middle of the TD. We don't want to handle the TD yet as we will anyway
receive a new event for the last TRB in the TD.

Hold off from finishing the TD and removing it from the list until we
receive an event for the last TRB in the TD

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/usb/host/xhci-ring.c | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 06c247e..66bc627 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2156,6 +2156,10 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_td *td,
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
/* Fast path - was this the last TRB in the TD for this URB? */
if (event_trb == td->last_trb) {
+ if (td->urb_length_set && trb_comp_code == COMP_SHORT_TX)
+ return finish_td(xhci, td, event_trb, event, ep,
+ status, false);
+
if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
td->urb->actual_length =
td->urb->transfer_buffer_length -
@@ -2207,6 +2211,12 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_td *td,
td->urb->actual_length +=
TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+
+ if (trb_comp_code == COMP_SHORT_TX) {
+ xhci_dbg(xhci, "mid bulk/intr SP, wait for last TRB event\n");
+ td->urb_length_set = true;
+ return 0;
+ }
}

return finish_td(xhci, td, event_trb, event, ep, status, false);
--
1.9.1

2015-11-12 23:31:53

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 119/155] xhci: handle no ping response error properly

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

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

From: Mathias Nyman <[email protected]>

commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream.

If a host fails to wake up a isochronous SuperSpeed device from U1/U2
in time for a isoch transfer it will generate a "No ping response error"
Host will then move to the next transfer descriptor.

Handle this case in the same way as missed service errors, tag the
current TD as skipped and handle it on the next transfer event.

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/usb/host/xhci-ring.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 66bc627..661aad5 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2249,6 +2249,7 @@ static int handle_tx_event(struct xhci_hcd *xhci,
u32 trb_comp_code;
int ret = 0;
int td_num = 0;
+ bool handling_skipped_tds = false;

slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
xdev = xhci->devs[slot_id];
@@ -2382,6 +2383,10 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ep->skip = true;
xhci_dbg(xhci, "Miss service interval error, set skip flag\n");
goto cleanup;
+ case COMP_PING_ERR:
+ ep->skip = true;
+ xhci_dbg(xhci, "No Ping response error, Skip one Isoc TD\n");
+ goto cleanup;
default:
if (xhci_is_vendor_info_code(xhci, trb_comp_code)) {
status = 0;
@@ -2518,13 +2523,18 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ep, &status);

cleanup:
+
+
+ handling_skipped_tds = ep->skip &&
+ trb_comp_code != COMP_MISSED_INT &&
+ trb_comp_code != COMP_PING_ERR;
+
/*
- * Do not update event ring dequeue pointer if ep->skip is set.
- * Will roll back to continue process missed tds.
+ * Do not update event ring dequeue pointer if we're in a loop
+ * processing missed tds.
*/
- if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
+ if (!handling_skipped_tds)
inc_deq(xhci, xhci->event_ring);
- }

if (ret) {
urb = td->urb;
@@ -2559,7 +2569,7 @@ cleanup:
* Process them as short transfer until reach the td pointed by
* the event.
*/
- } while (ep->skip && trb_comp_code != COMP_MISSED_INT);
+ } while (handling_skipped_tds);

return 0;
}
--
1.9.1

2015-11-12 23:29:26

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 120/155] xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

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

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

From: Laura Abbott <[email protected]>

commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.

We received several reports of systems rebooting and powering on
after an attempted shutdown. Testing showed that setting
XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
quirk allowed the system to shutdown as expected for LynxPoint-LP
xHCI controllers. Set the quirk back.

Note that the quirk was originally introduced for LynxPoint and
LynxPoint-LP just for this same reason. See:

commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

It was later limited to only concern HP machines as it caused
regression on some machines, see both bug and commit:

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

Later it was discovered that the powering on after shutdown
was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
machine suffered from spontaneous resume from S3 (which should
not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

Current understanding is that LynxPoint-LP (Haswell ULT) machines
need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
plain Lynxpoint (Haswell) machines may _not_ have the quirk
set otherwise they again will restart.

Signed-off-by: Laura Abbott <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Oliver Neukum <[email protected]>
[Added more history to commit message -Mathias]
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/usb/host/xhci-pci.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 2af32e2..7e5c90e 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -135,6 +135,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
+ xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
(pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
--
1.9.1

2015-11-12 23:19:59

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 121/155] ASoC: wm8904: Correct number of EQ registers

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

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

From: Charles Keepax <[email protected]>

commit 97aff2c03a1e4d343266adadb52313613efb027f upstream.

There are 24 EQ registers not 25, I suspect this bug came about because
the registers start at EQ1 not zero. The bug is relatively harmless as
the extra register written is an unused one.

Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
include/sound/wm8904.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/sound/wm8904.h b/include/sound/wm8904.h
index 898be3a..6d8f8fb 100644
--- a/include/sound/wm8904.h
+++ b/include/sound/wm8904.h
@@ -119,7 +119,7 @@
#define WM8904_MIC_REGS 2
#define WM8904_GPIO_REGS 4
#define WM8904_DRC_REGS 4
-#define WM8904_EQ_REGS 25
+#define WM8904_EQ_REGS 24

/**
* DRC configurations are specified with a label and a set of register
--
1.9.1

2015-11-12 23:19:58

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 122/155] drm: fix mutex leak in drm_dp_get_mst_branch_device

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

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

From: Adam Richter <[email protected]>

commit 30730c7f5943b3beace1e29f7f1476e05de3da14 upstream.

In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later. This patch
changes the error to "goto out" to unlock the mutex before returning.

[airlied: grabbed from drm-next as it fixes something we've seen]

Signed-off-by: Adam J. Richter <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1133179..df0fccb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1189,17 +1189,18 @@ static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct drm_dp_mst_

list_for_each_entry(port, &mstb->ports, next) {
if (port->port_num == port_num) {
- if (!port->mstb) {
+ mstb = port->mstb;
+ if (!mstb) {
DRM_ERROR("failed to lookup MSTB with lct %d, rad %02x\n", lct, rad[0]);
- return NULL;
+ goto out;
}

- mstb = port->mstb;
break;
}
}
}
kref_get(&mstb->kref);
+out:
mutex_unlock(&mgr->lock);
return mstb;
}
--
1.9.1

2015-11-12 23:19:56

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 123/155] drm/nouveau/gem: return only valid domain when there's only one

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

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

From: Ilia Mirkin <[email protected]>

commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream.

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
index bf0f9e21d..1d74ab4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -224,11 +224,12 @@ nouveau_gem_info(struct drm_file *file_priv, struct drm_gem_object *gem,
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_vma *vma;

- if (nvbo->bo.mem.mem_type == TTM_PL_TT)
+ if (is_power_of_2(nvbo->valid_domains))
+ rep->domain = nvbo->valid_domains;
+ else if (nvbo->bo.mem.mem_type == TTM_PL_TT)
rep->domain = NOUVEAU_GEM_DOMAIN_GART;
else
rep->domain = NOUVEAU_GEM_DOMAIN_VRAM;
-
rep->offset = nvbo->bo.offset;
if (cli->vm) {
vma = nouveau_bo_vma_find(nvbo, cli->vm);
--
1.9.1

2015-11-12 23:29:31

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 124/155] powerpc/rtas: Validate rtas.entry before calling enter_rtas()

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

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

From: Vasant Hegde <[email protected]>

commit 8832317f662c06f5c06e638f57bfe89a71c9b266 upstream.

Currently we do not validate rtas.entry before calling enter_rtas(). This
leads to a kernel oops when user space calls rtas system call on a powernv
platform (see below). This patch adds code to validate rtas.entry before
making enter_rtas() call.

Oops: Exception in kernel mode, sig: 4 [#1]
SMP NR_CPUS=1024 NUMA PowerNV
task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000
NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140
REGS: c0000007e1a7b920 TRAP: 0e40 Not tainted (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le)
MSR: 1000000000081000 <HV,ME> CR: 00000000 XER: 00000000
CFAR: c000000000009c0c SOFTE: 0
NIP [0000000000000000] (null)
LR [0000000000009c14] 0x9c14
Call Trace:
[c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable)
[c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0
[c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98

Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform")
Reported-by: NAGESWARA R. SASTRY <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
[mpe: Reword change log, trim oops, and add stable + fixes]
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/powerpc/kernel/rtas.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 3e54b0b..8664656 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1045,6 +1045,9 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
if (!capable(CAP_SYS_ADMIN))
return -EPERM;

+ if (!rtas.entry)
+ return -EINVAL;
+
if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
return -EFAULT;

--
1.9.1

2015-11-12 23:30:41

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 125/155] [media] si2168: Bounds check firmware

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

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

From: Laura Abbott <[email protected]>

commit 47810b4341ac9d2f558894bc5995e6fa2a1298f9 upstream.

When reading the firmware and sending commands, the length must
be bounds checked to avoid overrunning the size of the command
buffer and smashing the stack if the firmware is not in the expected
format:

si2168 11-0064: found a 'Silicon Labs Si2168-B40'
si2168 11-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
si2168 11-0064: firmware download failed -95
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa085708f

Add the proper check.

Reported-by: Stuart Auchterlonie <[email protected]>
Reviewed-by: Antti Palosaari <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/media/dvb-frontends/si2168.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c
index acf0fc3..888cf2c 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -466,6 +466,10 @@ static int si2168_init(struct dvb_frontend *fe)
/* firmware is in the new format */
for (remaining = fw->size; remaining > 0; remaining -= 17) {
len = fw->data[fw->size - remaining];
+ if (len > SI2168_ARGLEN) {
+ ret = -EINVAL;
+ break;
+ }
memcpy(cmd.args, &fw->data[(fw->size - remaining) + 1], len);
cmd.wlen = len;
cmd.rlen = 1;
--
1.9.1

2015-11-12 23:28:21

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 126/155] mm: make sendfile(2) killable

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

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

From: Jan Kara <[email protected]>

commit 296291cdd1629c308114504b850dc343eabc2782 upstream.

Currently a simple program below issues a sendfile(2) system call which
takes about 62 days to complete in my test KVM instance.

int fd;
off_t off = 0;

fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
ftruncate(fd, 2);
lseek(fd, 0, SEEK_END);
sendfile(fd, fd, &off, 0xfffffff);

Now you should not ask kernel to do a stupid stuff like copying 256MB in
2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
should have a way to stop you.

We actually do have a check for fatal_signal_pending() in
generic_perform_write() which triggers in this path however because we
always succeed in writing something before the check is done, we return
value > 0 from generic_perform_write() and thus the information about
signal gets lost.

Fix the problem by doing the signal check before writing anything. That
way generic_perform_write() returns -EINTR, the error gets propagated up
and the sendfile loop terminates early.

Signed-off-by: Jan Kara <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
mm/filemap.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 673e458..0c95599 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2489,6 +2489,11 @@ again:
break;
}

+ if (fatal_signal_pending(current)) {
+ status = -EINTR;
+ break;
+ }
+
status = a_ops->write_begin(file, mapping, pos, bytes, flags,
&page, &fsdata);
if (unlikely(status < 0))
@@ -2526,10 +2531,6 @@ again:
written += copied;

balance_dirty_pages_ratelimited(mapping);
- if (fatal_signal_pending(current)) {
- status = -EINTR;
- break;
- }
} while (iov_iter_count(i));

return written ? written : status;
--
1.9.1

2015-11-12 23:20:01

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 127/155] fault-inject: fix inverted interval/probability values in printk

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

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

From: Florian Westphal <[email protected]>

commit bb387002693ed28b2bb0408c5dec65521b71e5f1 upstream.

interval displays the probability and vice versa.

Fixes: 6adc4a22f20bb ("fault-inject: add ratelimit option")
Acked-by: Akinobu Mita <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
lib/fault-inject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index f1cdeb0..6a823a5 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -44,7 +44,7 @@ static void fail_dump(struct fault_attr *attr)
printk(KERN_NOTICE "FAULT_INJECTION: forcing a failure.\n"
"name %pd, interval %lu, probability %lu, "
"space %d, times %d\n", attr->dname,
- attr->probability, attr->interval,
+ attr->interval, attr->probability,
atomic_read(&attr->space),
atomic_read(&attr->times));
if (attr->verbose > 1)
--
1.9.1

2015-11-12 23:30:40

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 128/155] rbd: fix double free on rbd_dev->header_name

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

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

From: Ilya Dryomov <[email protected]>

commit 3ebe138ac642a195c7f2efdb918f464734421fd6 upstream.

If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name
is freed twice: once in rbd_dev_probe_parent() and then in its caller
rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to
handle parent images).

rbd_dev_probe_parent() is responsible for probing the parent, so it
shouldn't muck with clone's fields.

Signed-off-by: Ilya Dryomov <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/block/rbd.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index f33ff6c..d7143de 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -5201,7 +5201,6 @@ static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
out_err:
if (parent) {
rbd_dev_unparent(rbd_dev);
- kfree(rbd_dev->header_name);
rbd_dev_destroy(parent);
} else {
rbd_put_client(rbdc);
--
1.9.1

2015-11-12 23:29:27

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 129/155] rbd: don't leak parent_spec in rbd_dev_probe_parent()

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

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

From: Ilya Dryomov <[email protected]>

commit 1f2c6651f69c14d0d3a9cfbda44ea101b02160ba upstream.

Currently we leak parent_spec and trigger a "parent reference
underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails.
The problem is we take the !parent out_err branch and that only drops
refcounts; parent_spec that would've been freed had we called
rbd_dev_unparent() remains and triggers rbd_warn() in
rbd_dev_parent_put() - at that point we have parent_spec != NULL and
parent_ref == 0, so counter ends up being -1 after the decrement.

Redo rbd_dev_probe_parent() to fix this.

Signed-off-by: Ilya Dryomov <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
[[email protected]: backport to < 4.2: rbd_dev->opts]
Signed-off-by: Luis Henriques <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/block/rbd.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index d7143de..0593700 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -5172,41 +5172,36 @@ out_err:
static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
{
struct rbd_device *parent = NULL;
- struct rbd_spec *parent_spec;
- struct rbd_client *rbdc;
int ret;

if (!rbd_dev->parent_spec)
return 0;
- /*
- * We need to pass a reference to the client and the parent
- * spec when creating the parent rbd_dev. Images related by
- * parent/child relationships always share both.
- */
- parent_spec = rbd_spec_get(rbd_dev->parent_spec);
- rbdc = __rbd_get_client(rbd_dev->rbd_client);

- ret = -ENOMEM;
- parent = rbd_dev_create(rbdc, parent_spec);
- if (!parent)
+ parent = rbd_dev_create(rbd_dev->rbd_client, rbd_dev->parent_spec);
+ if (!parent) {
+ ret = -ENOMEM;
goto out_err;
+ }
+
+ /*
+ * Images related by parent/child relationships always share
+ * rbd_client and spec/parent_spec, so bump their refcounts.
+ */
+ __rbd_get_client(rbd_dev->rbd_client);
+ rbd_spec_get(rbd_dev->parent_spec);

ret = rbd_dev_image_probe(parent, false);
if (ret < 0)
goto out_err;
+
rbd_dev->parent = parent;
atomic_set(&rbd_dev->parent_ref, 1);
-
return 0;
+
out_err:
- if (parent) {
- rbd_dev_unparent(rbd_dev);
+ rbd_dev_unparent(rbd_dev);
+ if (parent)
rbd_dev_destroy(parent);
- } else {
- rbd_put_client(rbdc);
- rbd_spec_put(parent_spec);
- }
-
return ret;
}

--
1.9.1

2015-11-12 23:29:24

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 130/155] rbd: prevent kernel stack blow up on rbd map

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

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

From: Ilya Dryomov <[email protected]>

commit 6d69bb536bac0d403d83db1ca841444981b280cd upstream.

Mapping an image with a long parent chain (e.g. image foo, whose parent
is bar, whose parent is baz, etc) currently leads to a kernel stack
overflow, due to the following recursion in the reply path:

rbd_osd_req_callback()
rbd_obj_request_complete()
rbd_img_obj_callback()
rbd_img_parent_read_callback()
rbd_obj_request_complete()
...

Limit the parent chain to 16 images, which is ~5K worth of stack. When
the above recursion is eliminated, this limit can be lifted.

Fixes: http://tracker.ceph.com/issues/12538

Signed-off-by: Ilya Dryomov <[email protected]>
Reviewed-by: Josh Durgin <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/block/rbd.c | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 0593700..accdf1d 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -95,6 +95,8 @@ static int atomic_dec_return_safe(atomic_t *v)
#define RBD_MINORS_PER_MAJOR 256
#define RBD_SINGLE_MAJOR_PART_SHIFT 4

+#define RBD_MAX_PARENT_CHAIN_LEN 16
+
#define RBD_SNAP_DEV_NAME_PREFIX "snap_"
#define RBD_MAX_SNAP_NAME_LEN \
(NAME_MAX - (sizeof (RBD_SNAP_DEV_NAME_PREFIX) - 1))
@@ -423,7 +425,7 @@ static ssize_t rbd_add_single_major(struct bus_type *bus, const char *buf,
size_t count);
static ssize_t rbd_remove_single_major(struct bus_type *bus, const char *buf,
size_t count);
-static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping);
+static int rbd_dev_image_probe(struct rbd_device *rbd_dev, int depth);
static void rbd_spec_put(struct rbd_spec *spec);

static int rbd_dev_id_to_minor(int dev_id)
@@ -5169,7 +5171,12 @@ out_err:
return ret;
}

-static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
+/*
+ * @depth is rbd_dev_image_probe() -> rbd_dev_probe_parent() ->
+ * rbd_dev_image_probe() recursion depth, which means it's also the
+ * length of the already discovered part of the parent chain.
+ */
+static int rbd_dev_probe_parent(struct rbd_device *rbd_dev, int depth)
{
struct rbd_device *parent = NULL;
int ret;
@@ -5177,6 +5184,12 @@ static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
if (!rbd_dev->parent_spec)
return 0;

+ if (++depth > RBD_MAX_PARENT_CHAIN_LEN) {
+ pr_info("parent chain is too long (%d)\n", depth);
+ ret = -EINVAL;
+ goto out_err;
+ }
+
parent = rbd_dev_create(rbd_dev->rbd_client, rbd_dev->parent_spec);
if (!parent) {
ret = -ENOMEM;
@@ -5190,7 +5203,7 @@ static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
__rbd_get_client(rbd_dev->rbd_client);
rbd_spec_get(rbd_dev->parent_spec);

- ret = rbd_dev_image_probe(parent, false);
+ ret = rbd_dev_image_probe(parent, depth);
if (ret < 0)
goto out_err;

@@ -5319,7 +5332,7 @@ static void rbd_dev_image_release(struct rbd_device *rbd_dev)
* parent), initiate a watch on its header object before using that
* object to get detailed information about the rbd image.
*/
-static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
+static int rbd_dev_image_probe(struct rbd_device *rbd_dev, int depth)
{
int ret;

@@ -5337,7 +5350,7 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
if (ret)
goto err_out_format;

- if (mapping) {
+ if (!depth) {
ret = rbd_dev_header_watch_sync(rbd_dev);
if (ret)
goto out_header_name;
@@ -5353,7 +5366,7 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
* Otherwise this is a parent image, identified by pool, image
* and snap ids - need to fill in names for those ids.
*/
- if (mapping)
+ if (!depth)
ret = rbd_spec_fill_snap_id(rbd_dev);
else
ret = rbd_spec_fill_names(rbd_dev);
@@ -5369,12 +5382,12 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
* Need to warn users if this image is the one being
* mapped and has a parent.
*/
- if (mapping && rbd_dev->parent_spec)
+ if (!depth && rbd_dev->parent_spec)
rbd_warn(rbd_dev,
"WARNING: kernel layering is EXPERIMENTAL!");
}

- ret = rbd_dev_probe_parent(rbd_dev);
+ ret = rbd_dev_probe_parent(rbd_dev, depth);
if (ret)
goto err_out_probe;

@@ -5385,7 +5398,7 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
err_out_probe:
rbd_dev_unprobe(rbd_dev);
err_out_watch:
- if (mapping)
+ if (!depth)
rbd_dev_header_unwatch_sync(rbd_dev);
out_header_name:
kfree(rbd_dev->header_name);
@@ -5447,7 +5460,7 @@ static ssize_t do_rbd_add(struct bus_type *bus,
rbdc = NULL; /* rbd_dev now owns this */
spec = NULL; /* rbd_dev now owns this */

- rc = rbd_dev_image_probe(rbd_dev, true);
+ rc = rbd_dev_image_probe(rbd_dev, 0);
if (rc < 0)
goto err_out_rbd_dev;

--
1.9.1

2015-11-12 23:28:43

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 131/155] dm btree remove: fix a bug when rebalancing nodes after removal

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

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

From: Joe Thornber <[email protected]>

commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b upstream.

Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
a complete fix for redistribute3().

The redistribute3 function takes 3 btree nodes and shares out the entries
evenly between them. If the three nodes in total contained
(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
the center.

Fix this issue by being more careful about calculating the target number
of entries for the left and right nodes.

Unit tested in userspace using this program:
https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c

Signed-off-by: Joe Thornber <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/persistent-data/dm-btree-remove.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/md/persistent-data/dm-btree-remove.c b/drivers/md/persistent-data/dm-btree-remove.c
index 7c0d755..92cd09f 100644
--- a/drivers/md/persistent-data/dm-btree-remove.c
+++ b/drivers/md/persistent-data/dm-btree-remove.c
@@ -301,11 +301,16 @@ static void redistribute3(struct dm_btree_info *info, struct btree_node *parent,
{
int s;
uint32_t max_entries = le32_to_cpu(left->header.max_entries);
- unsigned target = (nr_left + nr_center + nr_right) / 3;
- BUG_ON(target > max_entries);
+ unsigned total = nr_left + nr_center + nr_right;
+ unsigned target_right = total / 3;
+ unsigned remainder = (target_right * 3) != total;
+ unsigned target_left = target_right + remainder;
+
+ BUG_ON(target_left > max_entries);
+ BUG_ON(target_right > max_entries);

if (nr_left < nr_right) {
- s = nr_left - target;
+ s = nr_left - target_left;

if (s < 0 && nr_center < -s) {
/* not enough in central node */
@@ -316,10 +321,10 @@ static void redistribute3(struct dm_btree_info *info, struct btree_node *parent,
} else
shift(left, center, s);

- shift(center, right, target - nr_right);
+ shift(center, right, target_right - nr_right);

} else {
- s = target - nr_right;
+ s = target_right - nr_right;
if (s > 0 && nr_center < s) {
/* not enough in central node */
shift(center, right, nr_center);
@@ -329,7 +334,7 @@ static void redistribute3(struct dm_btree_info *info, struct btree_node *parent,
} else
shift(center, right, s);

- shift(left, center, nr_left - target);
+ shift(left, center, nr_left - target_left);
}

*key_ptr(parent, c->index) = center->keys[0];
--
1.9.1

2015-11-12 23:28:42

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 132/155] dm btree: fix leak of bufio-backed block in btree_split_beneath error path

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

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

From: Mike Snitzer <[email protected]>

commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream.

btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.

Fix this by releasing the previously allocated bufio block using
unlock_block().

Reported-by: Mikulas Patocka <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Acked-by: Joe Thornber <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/persistent-data/dm-btree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/persistent-data/dm-btree.c b/drivers/md/persistent-data/dm-btree.c
index c7726ce..d6e4703 100644
--- a/drivers/md/persistent-data/dm-btree.c
+++ b/drivers/md/persistent-data/dm-btree.c
@@ -523,7 +523,7 @@ static int btree_split_beneath(struct shadow_spine *s, uint64_t key)

r = new_block(s->info, &right);
if (r < 0) {
- /* FIXME: put left */
+ unlock_block(s->info, left);
return r;
}

--
1.9.1

2015-11-12 23:27:53

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 133/155] bpf: fix panic in SO_GET_FILTER with native ebpf programs

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

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

From: Daniel Borkmann <[email protected]>

commit 93d08b6966cf730ea669d4d98f43627597077153 upstream.

When sockets have a native eBPF program attached through
setsockopt(sk, SOL_SOCKET, SO_ATTACH_BPF, ...), and then try to
dump these over getsockopt(sk, SOL_SOCKET, SO_GET_FILTER, ...),
the following panic appears:

[49904.178642] BUG: unable to handle kernel NULL pointer dereference at (null)
[49904.178762] IP: [<ffffffff81610fd9>] sk_get_filter+0x39/0x90
[49904.182000] PGD 86fc9067 PUD 531a1067 PMD 0
[49904.185196] Oops: 0000 [#1] SMP
[...]
[49904.224677] Call Trace:
[49904.226090] [<ffffffff815e3d49>] sock_getsockopt+0x319/0x740
[49904.227535] [<ffffffff812f59e3>] ? sock_has_perm+0x63/0x70
[49904.228953] [<ffffffff815e2fc8>] ? release_sock+0x108/0x150
[49904.230380] [<ffffffff812f5a43>] ? selinux_socket_getsockopt+0x23/0x30
[49904.231788] [<ffffffff815dff36>] SyS_getsockopt+0xa6/0xc0
[49904.233267] [<ffffffff8171b9ae>] entry_SYSCALL_64_fastpath+0x12/0x71

The underlying issue is the very same as in commit b382c0865600
("sock, diag: fix panic in sock_diag_put_filterinfo"), that is,
native eBPF programs don't store an original program since this
is only needed in cBPF ones.

However, sk_get_filter() wasn't updated to test for this at the
time when eBPF could be attached. Just throw an error to the user
to indicate that eBPF cannot be dumped over this interface.
That way, it can also be known that a program _is_ attached (as
opposed to just return 0), and a different (future) method needs
to be consulted for a dump.

Fixes: 89aa075832b0 ("net: sock: allow eBPF programs to be attached to sockets")
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/core/filter.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/core/filter.c b/net/core/filter.c
index ec9baea..e1d48e4 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1215,9 +1215,13 @@ int sk_get_filter(struct sock *sk, struct sock_filter __user *ubuf,
goto out;

/* We're copying the filter that has been originally attached,
- * so no conversion/decode needed anymore.
+ * so no conversion/decode needed anymore. eBPF programs that
+ * have no original program cannot be dumped through this.
*/
+ ret = -EACCES;
fprog = filter->prog->orig_prog;
+ if (!fprog)
+ goto out;

ret = fprog->len;
if (!len)
--
1.9.1

2015-11-12 23:26:31

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 134/155] ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on

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

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

From: Tomi Valkeinen <[email protected]>

commit 7e381ec6a36aa44f15fc1a76e6efb9e2cd942e61 upstream.

LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add
am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
depending on whether an SD card is inserted or not.

This patch sets LDO1 regulator to always-on.

This patch has a side effect of fixing another issue, HDMI DDC not
working when SD card is not inserted:

Why this happens is that the tpd12s015 (HDMI level shifter/ESD
protection chip) has LS_OE GPIO input, which needs to be enabled for the
HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.

So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
off.

The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
framework manage the pin specific power.

Apparently this fixes also a third issue (copy paste from Kishon's
patch):

ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.

Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
Cc: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Reported-by: Louis McCarthy <[email protected]>
Acked-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index dcd2f5d..3e305b0 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -240,11 +240,12 @@
/* SMPS9 unused */

ldo1_reg: ldo1 {
- /* VDD_SD */
+ /* VDD_SD / VDDSHV8 */
regulator-name = "ldo1";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
+ regulator-always-on;
};

ldo2_reg: ldo2 {
--
1.9.1

2015-11-12 23:27:23

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 135/155] IB/cm: Fix rb-tree duplicate free and use-after-free

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

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

From: Doron Tsur <[email protected]>

commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 upstream.

ib_send_cm_sidr_rep could sometimes erase the node from the sidr
(depending on errors in the process). Since ib_send_cm_sidr_rep is
called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
could be either erased from the rb_tree twice or not erased at all.
Fixing that by making sure it's erased only once before freeing
cm_id_priv.

Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
Signed-off-by: Doron Tsur <[email protected]>
Signed-off-by: Matan Barak <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/infiniband/core/cm.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index e28a494..c3a83f7 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -860,6 +860,11 @@ retest:
case IB_CM_SIDR_REQ_RCVD:
spin_unlock_irq(&cm_id_priv->lock);
cm_reject_sidr_req(cm_id_priv, IB_SIDR_REJECT);
+ spin_lock_irq(&cm.lock);
+ if (!RB_EMPTY_NODE(&cm_id_priv->sidr_id_node))
+ rb_erase(&cm_id_priv->sidr_id_node,
+ &cm.remote_sidr_table);
+ spin_unlock_irq(&cm.lock);
break;
case IB_CM_REQ_SENT:
ib_cancel_mad(cm_id_priv->av.port->mad_agent, cm_id_priv->msg);
@@ -3099,7 +3104,10 @@ int ib_send_cm_sidr_rep(struct ib_cm_id *cm_id,
spin_unlock_irqrestore(&cm_id_priv->lock, flags);

spin_lock_irqsave(&cm.lock, flags);
- rb_erase(&cm_id_priv->sidr_id_node, &cm.remote_sidr_table);
+ if (!RB_EMPTY_NODE(&cm_id_priv->sidr_id_node)) {
+ rb_erase(&cm_id_priv->sidr_id_node, &cm.remote_sidr_table);
+ RB_CLEAR_NODE(&cm_id_priv->sidr_id_node);
+ }
spin_unlock_irqrestore(&cm.lock, flags);
return 0;

--
1.9.1

2015-11-12 23:25:31

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 136/155] module: Fix locking in symbol_put_addr()

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

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

From: Peter Zijlstra <[email protected]>

commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream.

Poma (on the way to another bug) reported an assertion triggering:

[<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
[<ffffffff81150822>] __module_address+0x32/0x150
[<ffffffff81150956>] __module_text_address+0x16/0x70
[<ffffffff81150f19>] symbol_put_addr+0x29/0x40
[<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]

Laura Abbott <[email protected]> produced a patch which lead us to
inspect symbol_put_addr(). This function has a comment claiming it
doesn't need to disable preemption around the module lookup
because it holds a reference to the module it wants to find, which
therefore cannot go away.

This is wrong (and a false optimization too, preempt_disable() is really
rather cheap, and I doubt any of this is on uber critical paths,
otherwise it would've retained a pointer to the actual module anyway and
avoided the second lookup).

While its true that the module cannot go away while we hold a reference
on it, the data structure we do the lookup in very much _CAN_ change
while we do the lookup. Therefore fix the comment and add the
required preempt_disable().

Reported-by: poma <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Fixes: a6e6abd575fc ("module: remove module_text_address()")
Signed-off-by: Kamal Mostafa <[email protected]>
---
kernel/module.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index bc8d162..8942456 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -906,11 +906,15 @@ void symbol_put_addr(void *addr)
if (core_kernel_text(a))
return;

- /* module_text_address is safe here: we're supposed to have reference
- * to module from symbol_get, so it can't go away. */
+ /*
+ * Even though we hold a reference on the module; we still need to
+ * disable preemption in order to safely traverse the data structure.
+ */
+ preempt_disable();
modaddr = __module_text_address(a);
BUG_ON(!modaddr);
module_put(modaddr);
+ preempt_enable();
}
EXPORT_SYMBOL_GPL(symbol_put_addr);

--
1.9.1

2015-11-12 23:27:22

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 137/155] PCI: Prevent out of bounds access in numa_node override

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

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

From: Sasha Levin <[email protected]>

commit 1266963170f576d4d08e6310b6963e26d3ff9d1e upstream.

63692df103e9 ("PCI: Allow numa_node override via sysfs") didn't check that
the numa node provided by userspace is valid. Passing a node number too
high would attempt to access invalid memory and trigger a kernel panic.

Fixes: 63692df103e9 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/pci/pci-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 312f23a..9261868 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -216,7 +216,7 @@ static ssize_t numa_node_store(struct device *dev,
if (ret)
return ret;

- if (!node_online(node))
+ if (node >= MAX_NUMNODES || !node_online(node))
return -EINVAL;

add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
--
1.9.1

2015-11-12 23:26:29

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 138/155] ovl: use O_LARGEFILE in ovl_copy_up()

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

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

From: David Howells <[email protected]>

commit 0480334fa60488d12ae101a02d7d9e1a3d03d7dd upstream.

Open the lower file with O_LARGEFILE in ovl_copy_up().

Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for
catching 32-bit userspace dealing with a file large enough that it'll be
mishandled if the application isn't aware that there might be an integer
overflow. Inside the kernel, there shouldn't be any problems.

Reported-by: Ulrich Obergfell <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
fs/overlayfs/copy_up.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index ea10a87..94edf78 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -81,11 +81,11 @@ static int ovl_copy_up_data(struct path *old, struct path *new, loff_t len)
if (len == 0)
return 0;

- old_file = ovl_path_open(old, O_RDONLY);
+ old_file = ovl_path_open(old, O_LARGEFILE | O_RDONLY);
if (IS_ERR(old_file))
return PTR_ERR(old_file);

- new_file = ovl_path_open(new, O_WRONLY);
+ new_file = ovl_path_open(new, O_LARGEFILE | O_WRONLY);
if (IS_ERR(new_file)) {
error = PTR_ERR(new_file);
goto out_fput;
--
1.9.1

2015-11-12 23:26:27

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 139/155] ovl: fix dentry reference leak

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

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

From: David Howells <[email protected]>

commit ab79efab0a0ba01a74df782eb7fa44b044dae8b5 upstream.

In ovl_copy_up_locked(), newdentry is leaked if the function exits through
out_cleanup as this just to out after calling ovl_cleanup() - which doesn't
actually release the ref on newdentry.

The out_cleanup segment should instead exit through out2 as certainly
newdentry leaks - and possibly upper does also, though this isn't caught
given the catch of newdentry.

Without this fix, something like the following is seen:

BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs]
BUG: Dentry ffff880023ece640{i=0,n=bigfile} still in use (1) [unmount of tmpfs tmpfs]

when unmounting the upper layer after an error occurred in copyup.

An error can be induced by creating a big file in a lower layer with
something like:

dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000))

to create a large file (4.1G). Overlay an upper layer that is too small
(on tmpfs might do) and then induce a copy up by opening it writably.

Reported-by: Ulrich Obergfell <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
fs/overlayfs/copy_up.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 94edf78..319c487 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -268,7 +268,7 @@ out:

out_cleanup:
ovl_cleanup(wdir, newdentry);
- goto out;
+ goto out2;
}

/*
--
1.9.1

2015-11-12 23:25:52

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 140/155] crypto: api - Only abort operations on fatal signal

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

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

From: Herbert Xu <[email protected]>

commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 upstream.

Currently a number of Crypto API operations may fail when a signal
occurs. This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.

In fact there is currently no need for those operations to be
interrupted by user signals at all. All we need is for them to
be killable.

This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.

Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
crypto/ablkcipher.c | 2 +-
crypto/algapi.c | 2 +-
crypto/api.c | 6 +++---
crypto/crypto_user.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index 40886c4..520729d 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -695,7 +695,7 @@ struct crypto_ablkcipher *crypto_alloc_ablkcipher(const char *alg_name,
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 71a8143..314cc74 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -337,7 +337,7 @@ static void crypto_wait_for_test(struct crypto_larval *larval)
crypto_alg_tested(larval->alg.cra_driver_name, 0);
}

- err = wait_for_completion_interruptible(&larval->completion);
+ err = wait_for_completion_killable(&larval->completion);
WARN_ON(err);

out:
diff --git a/crypto/api.c b/crypto/api.c
index 2a81e98..7db2e89 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -172,7 +172,7 @@ static struct crypto_alg *crypto_larval_wait(struct crypto_alg *alg)
struct crypto_larval *larval = (void *)alg;
long timeout;

- timeout = wait_for_completion_interruptible_timeout(
+ timeout = wait_for_completion_killable_timeout(
&larval->completion, 60 * HZ);

alg = larval->adult;
@@ -435,7 +435,7 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name, u32 type, u32 mask)
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
@@ -552,7 +552,7 @@ void *crypto_alloc_tfm(const char *alg_name,
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index c5148a3..47628bb 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -364,7 +364,7 @@ static struct crypto_alg *crypto_user_aead_alg(const char *name, u32 type,
err = PTR_ERR(alg);
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
--
1.9.1

2015-11-12 23:23:42

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 141/155] md/raid1: submit_bio_wait() returns 0 on success

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

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

From: Jes Sorensen <[email protected]>

commit 203d27b0226a05202438ddb39ef0ef1acb14a759 upstream.

This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
which changed the return value of submit_bio_wait() to return != 0 on
error, but didn't update the caller accordingly.

Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
Reported-by: Bill Kuzeja <[email protected]>
Signed-off-by: Jes Sorensen <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/raid1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index d24245c..3c8ada4 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2245,7 +2245,7 @@ static int narrow_write_error(struct r1bio *r1_bio, int i)
bio_trim(wbio, sector - r1_bio->sector, sectors);
wbio->bi_iter.bi_sector += rdev->data_offset;
wbio->bi_bdev = rdev->bdev;
- if (submit_bio_wait(WRITE, wbio) == 0)
+ if (submit_bio_wait(WRITE, wbio) < 0)
/* failure! */
ok = rdev_set_badblocks(rdev, sector,
sectors, 0)
--
1.9.1

2015-11-12 23:23:40

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 142/155] md/raid10: submit_bio_wait() returns 0 on success

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

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

From: Jes Sorensen <[email protected]>

commit 681ab4696062f5aa939c9e04d058732306a97176 upstream.

This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
which changed the return value of submit_bio_wait() to return != 0 on
error, but didn't update the caller accordingly.

Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
Reported-by: Bill Kuzeja <[email protected]>
Signed-off-by: Jes Sorensen <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/raid10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 17eb767..644f9e5 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2599,7 +2599,7 @@ static int narrow_write_error(struct r10bio *r10_bio, int i)
choose_data_offset(r10_bio, rdev) +
(sector - r10_bio->sector));
wbio->bi_bdev = rdev->bdev;
- if (submit_bio_wait(WRITE, wbio) == 0)
+ if (submit_bio_wait(WRITE, wbio) < 0)
/* Failure! */
ok = rdev_set_badblocks(rdev, sector,
sectors, 0)
--
1.9.1

2015-11-12 23:24:51

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 143/155] iommu/amd: Don't clear DTE flags when modifying it

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

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

From: Joerg Roedel <[email protected]>

commit cbf3ccd09d683abf1cacd36e3640872ee912d99b upstream.

During device assignment/deassignment the flags in the DTE
get lost, which might cause spurious faults, for example
when the device tries to access the system management range.
Fix this by not clearing the flags with the rest of the DTE.

Reported-by: G. Richard Bellamy <[email protected]>
Tested-by: G. Richard Bellamy <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/iommu/amd_iommu.c | 4 ++--
drivers/iommu/amd_iommu_types.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 0ecfa72..a0fac0a9 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2100,8 +2100,8 @@ static void set_dte_entry(u16 devid, struct protection_domain *domain, bool ats)
static void clear_dte_entry(u16 devid)
{
/* remove entry from the device table seen by the hardware */
- amd_iommu_dev_table[devid].data[0] = IOMMU_PTE_P | IOMMU_PTE_TV;
- amd_iommu_dev_table[devid].data[1] = 0;
+ amd_iommu_dev_table[devid].data[0] = IOMMU_PTE_P | IOMMU_PTE_TV;
+ amd_iommu_dev_table[devid].data[1] &= DTE_FLAG_MASK;

amd_iommu_apply_erratum_63(devid);
}
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index cec51a8..791442a 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -289,6 +289,7 @@
#define IOMMU_PTE_IR (1ULL << 61)
#define IOMMU_PTE_IW (1ULL << 62)

+#define DTE_FLAG_MASK (0x3ffULL << 32)
#define DTE_FLAG_IOTLB (0x01UL << 32)
#define DTE_FLAG_GV (0x01ULL << 55)
#define DTE_GLX_SHIFT (56)
--
1.9.1

2015-11-12 23:24:17

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 144/155] i2c: mv64xxx: really allow I2C offloading

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

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

From: Hezi Shahmoon <[email protected]>

commit 0729a04977d497cf66234fd7f900ddcec3ef1c52 upstream.

Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
several problems") completely reworked the offload support, but left a
debugging-related "return false" at the beginning of the
mv64xxx_i2c_can_offload() function. This has the unfortunate consequence
that offloading is in fact never used, which wasn't really the
intention.

This commit fixes that problem by removing the bogus "return false".

Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems")
Signed-off-by: Hezi Shahmoon <[email protected]>
[Thomas: reworked commit log and title.]
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/i2c/busses/i2c-mv64xxx.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 30059c1..5801227 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -669,8 +669,6 @@ mv64xxx_i2c_can_offload(struct mv64xxx_i2c_data *drv_data)
struct i2c_msg *msgs = drv_data->msgs;
int num = drv_data->num_msgs;

- return false;
-
if (!drv_data->offload_enabled)
return false;

--
1.9.1

2015-11-12 23:20:04

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 145/155] drm/radeon: don't try to recreate sysfs entries on resume

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

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

From: Alex Deucher <[email protected]>

commit 49abb26651167c892393cd9f2ad23df429645ed9 upstream.

Fixes a harmless error message caused by:
51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 35 +++++++++++++++++++++--------------
2 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 6cb4dc1..6985954 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1654,6 +1654,7 @@ struct radeon_pm {
u8 fan_max_rpm;
/* dpm */
bool dpm_enabled;
+ bool sysfs_initialized;
struct radeon_dpm dpm;
};

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
index d22cf0d..fa537c0 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1390,19 +1390,23 @@ int radeon_pm_late_init(struct radeon_device *rdev)

if (rdev->pm.pm_method == PM_METHOD_DPM) {
if (rdev->pm.dpm_enabled) {
- ret = device_create_file(rdev->dev, &dev_attr_power_dpm_state);
- if (ret)
- DRM_ERROR("failed to create device file for dpm state\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_dpm_force_performance_level);
- if (ret)
- DRM_ERROR("failed to create device file for dpm state\n");
- /* XXX: these are noops for dpm but are here for backwards compat */
- ret = device_create_file(rdev->dev, &dev_attr_power_profile);
- if (ret)
- DRM_ERROR("failed to create device file for power profile\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_method);
- if (ret)
- DRM_ERROR("failed to create device file for power method\n");
+ if (!rdev->pm.sysfs_initialized) {
+ ret = device_create_file(rdev->dev, &dev_attr_power_dpm_state);
+ if (ret)
+ DRM_ERROR("failed to create device file for dpm state\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_dpm_force_performance_level);
+ if (ret)
+ DRM_ERROR("failed to create device file for dpm state\n");
+ /* XXX: these are noops for dpm but are here for backwards compat */
+ ret = device_create_file(rdev->dev, &dev_attr_power_profile);
+ if (ret)
+ DRM_ERROR("failed to create device file for power profile\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_method);
+ if (ret)
+ DRM_ERROR("failed to create device file for power method\n");
+ if (!ret)
+ rdev->pm.sysfs_initialized = true;
+ }

mutex_lock(&rdev->pm.mutex);
ret = radeon_dpm_late_enable(rdev);
@@ -1418,7 +1422,8 @@ int radeon_pm_late_init(struct radeon_device *rdev)
}
}
} else {
- if (rdev->pm.num_power_states > 1) {
+ if ((rdev->pm.num_power_states > 1) &&
+ (!rdev->pm.sysfs_initialized)) {
/* where's the best place to put these? */
ret = device_create_file(rdev->dev, &dev_attr_power_profile);
if (ret)
@@ -1426,6 +1431,8 @@ int radeon_pm_late_init(struct radeon_device *rdev)
ret = device_create_file(rdev->dev, &dev_attr_power_method);
if (ret)
DRM_ERROR("failed to create device file for power method\n");
+ if (!ret)
+ rdev->pm.sysfs_initialized = true;
}
}
return ret;
--
1.9.1

2015-11-12 23:23:05

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 146/155] mvsas: Fix NULL pointer dereference in mvs_slot_task_free

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

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

From: =?UTF-8?q?D=C4=81vis=20Mos=C4=81ns?= <[email protected]>

commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
NULL but it's later used in mvs_abort_task as slot which is passed
to mvs_slot_task_free causing NULL pointer dereference.

Just return from mvs_slot_task_free when passed with NULL slot.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891
Signed-off-by: Dāvis Mosāns <[email protected]>
Reviewed-by: Tomas Henzl <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/scsi/mvsas/mv_sas.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index 454536c..9c78074 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -887,6 +887,8 @@ static void mvs_slot_free(struct mvs_info *mvi, u32 rx_desc)
static void mvs_slot_task_free(struct mvs_info *mvi, struct sas_task *task,
struct mvs_slot_info *slot, u32 slot_idx)
{
+ if (!slot)
+ return;
if (!slot->task)
return;
if (!sas_protocol_ata(task->task_proto))
--
1.9.1

2015-11-12 23:23:04

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 147/155] arm64: compat: fix stxr failure case in SWP emulation

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

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

From: Will Deacon <[email protected]>

commit 589cb22bbedacf325951014c07a35a2b01ca57f6 upstream.

If the STXR instruction fails in the SWP emulation code, we leave *data
overwritten with the loaded value, therefore corrupting the data written
by a subsequent, successful attempt.

This patch re-jigs the code so that we only write back to *data once we
know that the update has happened.

Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: Shengjiu Wang <[email protected]>
Reported-by: Vladimir Murzin <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm64/kernel/armv8_deprecated.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index c363671..519df37 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -228,21 +228,23 @@ static void register_insn_emulation_sysctl(struct ctl_table *table)
*/
#define __user_swpX_asm(data, addr, res, temp, B) \
__asm__ __volatile__( \
- " mov %w2, %w1\n" \
- "0: ldxr"B" %w1, [%3]\n" \
- "1: stxr"B" %w0, %w2, [%3]\n" \
+ "0: ldxr"B" %w2, [%3]\n" \
+ "1: stxr"B" %w0, %w1, [%3]\n" \
" cbz %w0, 2f\n" \
" mov %w0, %w4\n" \
+ " b 3f\n" \
"2:\n" \
+ " mov %w1, %w2\n" \
+ "3:\n" \
" .pushsection .fixup,\"ax\"\n" \
" .align 2\n" \
- "3: mov %w0, %w5\n" \
- " b 2b\n" \
+ "4: mov %w0, %w5\n" \
+ " b 3b\n" \
" .popsection" \
" .pushsection __ex_table,\"a\"\n" \
" .align 3\n" \
- " .quad 0b, 3b\n" \
- " .quad 1b, 3b\n" \
+ " .quad 0b, 4b\n" \
+ " .quad 1b, 4b\n" \
" .popsection" \
: "=&r" (res), "+r" (data), "=&r" (temp) \
: "r" (addr), "i" (-EAGAIN), "i" (-EFAULT) \
--
1.9.1

2015-11-12 23:22:29

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 148/155] Revert "ARM64: unwind: Fix PC calculation"

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

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

From: Will Deacon <[email protected]>

commit 9702970c7bd3e2d6fecb642a190269131d4ac16c upstream.

This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/arm64/kernel/stacktrace.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 407991b..ccb6078 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -48,11 +48,7 @@ int notrace unwind_frame(struct stackframe *frame)

frame->sp = fp + 0x10;
frame->fp = *(unsigned long *)(fp);
- /*
- * -4 here because we care about the PC at time of bl,
- * not where the return will go.
- */
- frame->pc = *(unsigned long *)(fp + 8) - 4;
+ frame->pc = *(unsigned long *)(fp + 8);

return 0;
}
--
1.9.1

2015-11-12 23:22:28

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 149/155] rbd: require stable pages if message data CRCs are enabled

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

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

From: Ronny Hegewald <[email protected]>

commit bae818ee1577c27356093901a0ea48f672eda514 upstream.

rbd requires stable pages, as it performs a crc of the page data before
they are send to the OSDs.

But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0
"mm: only enforce stable page writes if the backing device requires
it") it is not assumed anymore that block devices require stable pages.

This patch sets the necessary flag to get stable pages back for rbd.

In a ceph installation that provides multiple ext4 formatted rbd
devices "bad crc" messages appeared regularly (ca 1 message every 1-2
minutes on every OSD that provided the data for the rbd) in the
OSD-logs before this patch. After this patch this messages are pretty
much gone (only ca 1-2 / month / OSD).

Signed-off-by: Ronny Hegewald <[email protected]>
[[email protected]: require stable pages only in crc case, changelog]
Signed-off-by: Ilya Dryomov <[email protected]>
[[email protected]: backport to 3.9-3.17: context]
Signed-off-by: Luis Henriques <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/block/rbd.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index accdf1d..d72954b 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3785,6 +3785,9 @@ static int rbd_init_disk(struct rbd_device *rbd_dev)
q->limits.discard_zeroes_data = 1;

blk_queue_merge_bvec(q, rbd_merge_bvec);
+ if (!ceph_test_opt(rbd_dev->rbd_client->client, NOCRC))
+ q->backing_dev_info.capabilities |= BDI_CAP_STABLE_WRITES;
+
disk->queue = q;

q->queuedata = rbd_dev;
--
1.9.1

2015-11-12 23:20:09

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 150/155] md/raid5: fix locking in handle_stripe_clean_event()

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

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

From: Roman Gushchin <[email protected]>

commit b8a9d66d043ffac116100775a469f05f5158c16f upstream.

After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
__find_stripe() is called under conf->hash_locks + hash.
But handle_stripe_clean_event() calls remove_hash() under
conf->device_lock.

Under some cirscumstances the hash chain can be circuited,
and we get an infinite loop with disabled interrupts and locked hash
lock in __find_stripe(). This leads to hard lockup on multiple CPUs
and following system crash.

I was able to reproduce this behavior on raid6 over 6 ssd disks.
The devices_handle_discard_safely option should be set to enable trim
support. The following script was used:

for i in `seq 1 32`; do
dd if=/dev/zero of=large$i bs=10M count=100 &
done

Signed-off-by: Roman Gushchin <[email protected]>
Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
Signed-off-by: NeilBrown <[email protected]>
Cc: Shaohua Li <[email protected]>
[ luis: backported to 3.16: used Roman's backport to 3.14 ]
Signed-off-by: Luis Henriques <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/raid5.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index e421016..5fa7549 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3060,6 +3060,8 @@ static void handle_stripe_clean_event(struct r5conf *conf,
}
if (!discard_pending &&
test_bit(R5_Discard, &sh->dev[sh->pd_idx].flags)) {
+ int hash = sh->hash_lock_index;
+
clear_bit(R5_Discard, &sh->dev[sh->pd_idx].flags);
clear_bit(R5_UPTODATE, &sh->dev[sh->pd_idx].flags);
if (sh->qd_idx >= 0) {
@@ -3073,9 +3075,9 @@ static void handle_stripe_clean_event(struct r5conf *conf,
* no updated data, so remove it from hash list and the stripe
* will be reinitialized
*/
- spin_lock_irq(&conf->device_lock);
+ spin_lock_irq(conf->hash_locks + hash);
remove_hash(sh);
- spin_unlock_irq(&conf->device_lock);
+ spin_unlock_irq(conf->hash_locks + hash);
if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
set_bit(STRIPE_HANDLE, &sh->state);

--
1.9.1

2015-11-12 23:22:00

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 151/155] Revert "md: allow a partially recovered device to be hot-added to an array."

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

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

From: NeilBrown <[email protected]>

commit d01552a76d71f9879af448e9142389ee9be6e95b upstream.

This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57.

This commit is poorly justified, I can find not discusison in email,
and it clearly causes a problem.

If a device which is being recovered fails and is subsequently
re-added to an array, there could easily have been changes to the
array *before* the point where the recovery was up to. So the
recovery must start again from the beginning.

If a spare is being recovered and fails, then when it is re-added we
really should do a bitmap-based recovery up to the recovery-offset,
and then a full recovery from there. Before this reversion, we only
did the "full recovery from there" which is not corect. After this
reversion with will do a full recovery from the start, which is safer
but not ideal.

It will be left to a future patch to arrange the two different styles
of recovery.

Reported-and-tested-by: Nate Dailey <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.")
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/md/md.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c
index d7f0a56..6b82962 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7575,8 +7575,7 @@ static int remove_and_add_spares(struct mddev *mddev,
!test_bit(Bitmap_sync, &rdev->flags)))
continue;

- if (rdev->saved_raid_disk < 0)
- rdev->recovery_offset = 0;
+ rdev->recovery_offset = 0;
if (mddev->pers->
hot_add_disk(mddev, rdev) == 0) {
if (sysfs_link_rdev(mddev, rdev))
--
1.9.1

2015-11-12 23:20:16

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 152/155] net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

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

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

From: Carol L Soto <[email protected]>

commit c02b05011fadf8e409e41910217ca689f2fc9d91 upstream.

When doing memcpy/memset of EQEs, we should use sizeof struct
mlx4_eqe as the base size and not caps.eqe_size which could be bigger.

If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt
data in the master context.

When using a 64 byte stride, the memcpy copied over 63 bytes to the
slave_eq structure. This resulted in copying over the entire eqe of
interest, including its ownership bit -- and also 31 bytes of garbage
into the next WQE in the slave EQ -- which did NOT include the ownership
bit (and therefore had no impact).

However, once the stride is increased to 128, we are overwriting the
ownership bits of *three* eqes in the slave_eq struct. This results
in an incorrect ownership bit for those eqes, which causes the eq to
seem to be full. The issue therefore surfaced only once 128-byte EQEs
started being used in SRIOV and (overarchitectures that have 128/256
byte cache-lines such as PPC) - e.g after commit 77507aa249ae
"net/mlx4_core: Enable CQE/EQE stride support".

Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support')
Signed-off-by: Carol L Soto <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index 782bd10..9629383 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2058,7 +2058,7 @@ int mlx4_multi_func_init(struct mlx4_dev *dev)
spin_lock_init(&s_state->lock);
}

- memset(&priv->mfunc.master.cmd_eqe, 0, dev->caps.eqe_size);
+ memset(&priv->mfunc.master.cmd_eqe, 0, sizeof(struct mlx4_eqe));
priv->mfunc.master.cmd_eqe.type = MLX4_EVENT_TYPE_CMD;
INIT_WORK(&priv->mfunc.master.comm_work,
mlx4_master_comm_channel);
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 5d2f56a..c7c67a1 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -185,7 +185,7 @@ static void slave_event(struct mlx4_dev *dev, u8 slave, struct mlx4_eqe *eqe)
return;
}

- memcpy(s_eqe, eqe, dev->caps.eqe_size - 1);
+ memcpy(s_eqe, eqe, sizeof(struct mlx4_eqe) - 1);
s_eqe->slave_id = slave;
/* ensure all information is written before setting the ownersip bit */
wmb();
--
1.9.1

2015-11-12 23:20:14

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 153/155] ipv6: Fix IPsec pre-encap fragmentation check

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

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

From: Herbert Xu <[email protected]>

commit 93efac3f2e03321129de67a3c0ba53048bb53e31 upstream.

The IPv6 IPsec pre-encap path performs fragmentation for tunnel-mode
packets. That is, we perform fragmentation pre-encap rather than
post-encap.

A check was added later to ensure that proper MTU information is
passed back for locally generated traffic. Unfortunately this
check was performed on all IPsec packets, including transport-mode
packets.

What's more, the check failed to take GSO into account.

The end result is that transport-mode GSO packets get dropped at
the check.

This patch fixes it by moving the tunnel mode check forward as well
as adding the GSO check.

Fixes: dd767856a36e ("xfrm6: Don't call icmpv6_send on local error")
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/ipv6/xfrm6_output.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index ca3f29b..e588ee0 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -136,6 +136,7 @@ static int __xfrm6_output(struct sk_buff *skb)
struct dst_entry *dst = skb_dst(skb);
struct xfrm_state *x = dst->xfrm;
int mtu;
+ bool toobig;

#ifdef CONFIG_NETFILTER
if (!x) {
@@ -144,24 +145,28 @@ static int __xfrm6_output(struct sk_buff *skb)
}
#endif

+ if (x->props.mode != XFRM_MODE_TUNNEL)
+ goto skip_frag;
+
if (skb->protocol == htons(ETH_P_IPV6))
mtu = ip6_skb_dst_mtu(skb);
else
mtu = dst_mtu(skb_dst(skb));

- if (skb->len > mtu && xfrm6_local_dontfrag(skb)) {
+ toobig = skb->len > mtu && !skb_is_gso(skb);
+
+ if (toobig && xfrm6_local_dontfrag(skb)) {
xfrm6_local_rxpmtu(skb, mtu);
return -EMSGSIZE;
- } else if (!skb->ignore_df && skb->len > mtu && skb->sk) {
+ } else if (!skb->ignore_df && toobig && skb->sk) {
xfrm_local_error(skb, mtu);
return -EMSGSIZE;
}

- if (x->props.mode == XFRM_MODE_TUNNEL &&
- ((skb->len > mtu && !skb_is_gso(skb)) ||
- dst_allfrag(skb_dst(skb)))) {
+ if (toobig || dst_allfrag(skb_dst(skb)))
return ip6_fragment(skb, x->outer_mode->afinfo->output_finish);
- }
+
+skip_frag:
return x->outer_mode->afinfo->output_finish(skb);
}

--
1.9.1

2015-11-12 23:20:17

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 154/155] ipv6: gre: support SIT encapsulation

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

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

From: Eric Dumazet <[email protected]>

commit 7e3b6e7423d5f994257c1de88e06b509673fdbcf upstream.

gre_gso_segment() chokes if SIT frames were aggregated by GRO engine.

Fixes: 61c1db7fae21e ("ipv6: sit: add GSO/TSO support")
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
net/ipv4/gre_offload.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index 51973dd..abc50b4 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -36,7 +36,8 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
SKB_GSO_TCP_ECN |
SKB_GSO_GRE |
SKB_GSO_GRE_CSUM |
- SKB_GSO_IPIP)))
+ SKB_GSO_IPIP |
+ SKB_GSO_SIT)))
goto out;

if (!skb->encapsulation)
--
1.9.1

2015-11-12 23:20:12

by Kamal Mostafa

[permalink] [raw]
Subject: [PATCH 3.19.y-ckt 155/155] ppp: fix pppoe_dev deletion condition in pppoe_release()

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

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

From: Guillaume Nault <[email protected]>

commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 upstream.

We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev.
PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is
NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies
(po->pppoe_dev != NULL).
Since we're releasing a PPPoE socket, we want to release the pppoe_dev
if it exists and reset sk_state to PPPOX_DEAD, no matter the previous
value of sk_state. So we can just check for po->pppoe_dev and avoid any
assumption on sk->sk_state.

Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Signed-off-by: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/net/ppp/pppoe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index 84f5584..2745949 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -569,7 +569,7 @@ static int pppoe_release(struct socket *sock)

po = pppox_sk(sk);

- if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {
+ if (po->pppoe_dev) {
dev_put(po->pppoe_dev);
po->pppoe_dev = NULL;
}
--
1.9.1

2015-11-13 09:07:14

by Matt Fleming

[permalink] [raw]
Subject: Re: [PATCH 3.19.y-ckt 116/155] x86/setup: Extend low identity map to cover whole kernel range

On Thu, 12 Nov, at 03:17:50PM, Kamal Mostafa wrote:
> 3.19.8-ckt10 -stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Paolo Bonzini <[email protected]>
>
> commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.

Be sure to also apply upstream commit 68accac392d8 ("x86/setup: Fix
low identity map for >= 2GB kernel range") which fixes a bug in this
commit.

2015-11-13 09:14:01

by gianluca

[permalink] [raw]
Subject: Re: [PATCH 3.19.y-ckt 046/155] ASoC: sgtl5000: fix wrong register MIC_BIAS_VOLTAGE setup on probe

On 11/13/2015 12:16 AM, Kamal Mostafa wrote:
> 3.19.8-ckt10 -stable review patch. If anyone has any objections, please let me know.
>

yes, it should works. Please add the correct message in the device-tree
probe for the micbias voltage too. Just to have the same behaviour.


> ------------------
>
> From: Gianluca Renzi <[email protected]>
>
> commit e256da84a04ea31c3c215997c847609af224e8f4 upstream.
>
> Signed-off-by: Gianluca Renzi <[email protected]>
> Signed-off-by: Mark Brown <[email protected]>
> Signed-off-by: Kamal Mostafa <[email protected]>
> ---
> sound/soc/codecs/sgtl5000.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
> index 10d2415..d91790e 100644
> --- a/sound/soc/codecs/sgtl5000.c
> +++ b/sound/soc/codecs/sgtl5000.c
> @@ -1337,8 +1337,8 @@ static int sgtl5000_probe(struct snd_soc_codec *codec)
> sgtl5000->micbias_resistor << SGTL5000_BIAS_R_SHIFT);
>
> snd_soc_update_bits(codec, SGTL5000_CHIP_MIC_CTRL,
> - SGTL5000_BIAS_R_MASK,
> - sgtl5000->micbias_voltage << SGTL5000_BIAS_R_SHIFT);
> + SGTL5000_BIAS_VOLT_MASK,
> + sgtl5000->micbias_voltage << SGTL5000_BIAS_VOLT_SHIFT);
> /*
> * disable DAP
> * TODO:
>


--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

2015-11-13 10:27:22

by David Vrabel

[permalink] [raw]
Subject: Re: [PATCH 3.19.y-ckt 042/155] x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

On 12/11/15 23:16, Kamal Mostafa wrote:
> 3.19.8-ckt10 -stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Vitaly Kuznetsov <[email protected]>
>
> commit 0b34a166f291d255755be46e43ed5497cdd194f2 upstream.
>
> Currently there is a number of issues preventing PVHVM Xen guests from
> doing successful kexec/kdump:
>
> - Bound event channels.
> - Registered vcpu_info.
> - PIRQ/emuirq mappings.
> - shared_info frame after XENMAPSPACE_shared_info operation.
> - Active grant mappings.
>
> Basically, newly booted kernel stumbles upon already set up Xen
> interfaces and there is no way to reestablish them. In Xen-4.7 a new
> feature called 'soft reset' is coming. A guest performing kexec/kdump
> operation is supposed to call SCHEDOP_shutdown hypercall with
> SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
> (with some help from toolstack) will do full domain cleanup (but
> keeping its memory and vCPU contexts intact) returning the guest to
> the state it had when it was first booted and thus allowing it to
> start over.
>
> Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
> probably OK as by default all unknown shutdown reasons cause domain
> destroy with a message in toolstack log: 'Unknown shutdown reason code
> 5. Destroying domain.' which gives a clue to what the problem is and
> eliminates false expectations.
>
> Signed-off-by: Vitaly Kuznetsov <[email protected]>
> Signed-off-by: David Vrabel <[email protected]>
> Signed-off-by: Kamal Mostafa <[email protected]>
> ---
> arch/x86/xen/enlighten.c | 23 +++++++++++++++++++++++
> include/xen/interface/sched.h | 8 ++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index f94ad30..2339a33 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -33,6 +33,10 @@
> #include <linux/memblock.h>
> #include <linux/edd.h>
>
> +#ifdef CONFIG_KEXEC_CORE

You need to change all uses of CONFIG_KEXEC_CORE to CONFIG_KEXEC.

David

2015-11-13 16:41:08

by Kamal Mostafa

[permalink] [raw]
Subject: Re: [PATCH 3.19.y-ckt 116/155] x86/setup: Extend low identity map to cover whole kernel range

> On Thu, 12 Nov, at 03:17:50PM, Kamal Mostafa wrote:
> > 3.19.8-ckt10 -stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Paolo Bonzini <[email protected]>
> >
> > commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.


On Fri, 2015-11-13 at 08:42 +0100, Borislav Petkov wrote:
>You stable people need better communication: I already replied to Greg's
>submission that this patch is b0rked, now you're picking it up too. And
>@stable was on CC...

This way, we stable people get to enjoy thanking you for your help twice.


On Fri, 2015-11-13 at 09:06 +0000, Matt Fleming wrote:
> Be sure to also apply upstream commit 68accac392d8 ("x86/setup: Fix
> low identity map for >= 2GB kernel range") which fixes a bug in this
> commit.

I don't see that "Fix low identity map" in mainline yet so I'll drop
"Extend low identity map" from 3.19-stable until it appears.

Thanks, Matt and Boris.

-Kamal

2015-11-13 16:57:50

by Kamal Mostafa

[permalink] [raw]
Subject: Re: [PATCH 3.19.y-ckt 042/155] x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

> On 12/11/15 23:16, Kamal Mostafa wrote:
> > 3.19.8-ckt10 -stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Vitaly Kuznetsov <[email protected]>
> >
> > commit 0b34a166f291d255755be46e43ed5497cdd194f2 upstream.

On Fri, 2015-11-13 at 10:27 +0000, David Vrabel wrote:
> > +#ifdef CONFIG_KEXEC_CORE
>
> You need to change all uses of CONFIG_KEXEC_CORE to CONFIG_KEXEC.
>
> David


Yup, got it. Fixed the queued patch in 3.19-stable.

Thanks very much, David.

-Kamal

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

>From 668aff26f122882ff421b120562a214031416dd2 Mon Sep 17 00:00:00 2001
From: Vitaly Kuznetsov <[email protected]>
Date: Fri, 25 Sep 2015 11:59:52 +0200
Subject: x86/xen: Support kexec/kdump in HVM guests by doing a soft reset

commit 0b34a166f291d255755be46e43ed5497cdd194f2 upstream.

Currently there is a number of issues preventing PVHVM Xen guests from
doing successful kexec/kdump:

- Bound event channels.
- Registered vcpu_info.
- PIRQ/emuirq mappings.
- shared_info frame after XENMAPSPACE_shared_info operation.
- Active grant mappings.

Basically, newly booted kernel stumbles upon already set up Xen
interfaces and there is no way to reestablish them. In Xen-4.7 a new
feature called 'soft reset' is coming. A guest performing kexec/kdump
operation is supposed to call SCHEDOP_shutdown hypercall with
SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
(with some help from toolstack) will do full domain cleanup (but
keeping its memory and vCPU contexts intact) returning the guest to
the state it had when it was first booted and thus allowing it to
start over.

Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
probably OK as by default all unknown shutdown reasons cause domain
destroy with a message in toolstack log: 'Unknown shutdown reason code
5. Destroying domain.' which gives a clue to what the problem is and
eliminates false expectations.

Signed-off-by: Vitaly Kuznetsov <[email protected]>
Signed-off-by: David Vrabel <[email protected]>
[ kamal: backport to 3.19: s/CONFIG_KEXEC_CORE/CONFIG_KEXEC/ per David Vrabel ]
Signed-off-by: Kamal Mostafa <[email protected]>
---
arch/x86/xen/enlighten.c | 23 +++++++++++++++++++++++
include/xen/interface/sched.h | 8 ++++++++
2 files changed, 31 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index f94ad30..c1266a1 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,10 @@
#include <linux/memblock.h>
#include <linux/edd.h>

+#ifdef CONFIG_KEXEC
+#include <linux/kexec.h>
+#endif
+
#include <xen/xen.h>
#include <xen/events.h>
#include <xen/interface/xen.h>
@@ -1867,6 +1871,21 @@ static struct notifier_block xen_hvm_cpu_notifier = {
.notifier_call = xen_hvm_cpu_notify,
};

+#ifdef CONFIG_KEXEC
+static void xen_hvm_shutdown(void)
+{
+ native_machine_shutdown();
+ if (kexec_in_progress)
+ xen_reboot(SHUTDOWN_soft_reset);
+}
+
+static void xen_hvm_crash_shutdown(struct pt_regs *regs)
+{
+ native_machine_crash_shutdown(regs);
+ xen_reboot(SHUTDOWN_soft_reset);
+}
+#endif
+
static void __init xen_hvm_guest_init(void)
{
init_hvm_pv_info();
@@ -1883,6 +1902,10 @@ static void __init xen_hvm_guest_init(void)
x86_init.irqs.intr_init = xen_init_IRQ;
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
+#ifdef CONFIG_KEXEC
+ machine_ops.shutdown = xen_hvm_shutdown;
+ machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
+#endif
}

static bool xen_nopv = false;
diff --git a/include/xen/interface/sched.h b/include/xen/interface/sched.h
index 9ce0839..f184909 100644
--- a/include/xen/interface/sched.h
+++ b/include/xen/interface/sched.h
@@ -107,5 +107,13 @@ struct sched_watchdog {
#define SHUTDOWN_suspend 2 /* Clean up, save suspend info, kill. */
#define SHUTDOWN_crash 3 /* Tell controller we've crashed. */
#define SHUTDOWN_watchdog 4 /* Restart because watchdog time expired. */
+/*
+ * Domain asked to perform 'soft reset' for it. The expected behavior is to
+ * reset internal Xen state for the domain returning it to the point where it
+ * was created but leaving the domain's memory contents and vCPU contexts
+ * intact. This will allow the domain to start over and set up all Xen specific
+ * interfaces again.
+ */
+#define SHUTDOWN_soft_reset 5

#endif /* __XEN_PUBLIC_SCHED_H__ */
--
1.9.1