[PATCH 4.9 000/116] 4.9.2-stable review

[PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.9.2 release.
There are 116 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.2-rc1.gz
or in the git tree and branch at:
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.9.2-rc1

Mika Kuoppala <mika.kuoppala@linux.intel.com>
    drm/i915: Fix setting of boost freq tunable

Paulo Zanoni <paulo.r.zanoni@intel.com>
    drm/i915: skip the first 4k of stolen memory on everything >= gen8

Ville Syrjälä <ville.syrjala@linux.intel.com>
    drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

Ville Syrjälä <ville.syrjala@linux.intel.com>
    drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

Hans de Goede <hdegoede@redhat.com>
    drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

Hans de Goede <hdegoede@redhat.com>
    drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    net: mvpp2: fix dma unmapping of TX buffers for fragments

Al Viro <viro@zeniv.linux.org.uk>
    sg_write()/bsg_write() is not fit to be called under KERNEL_DS

Ben Hutchings <ben.hutchings@codethink.co.uk>
    kconfig/nconf: Fix hang when editing symbol with a long prompt

Andy Grover <agrover@redhat.com>
    target/user: Fix use-after-free of tcmu_cmds if they are expired

Dan Williams <dan.j.williams@intel.com>
    libnvdimm, pfn: fix align attribute

David Daney <david.daney@cavium.com>
    of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.

Nicholas Piggin <npiggin@gmail.com>
    powerpc/boot: Request no dynamic linker for boot wrapper

Geoff Levand <geoff@infradead.org>
    powerpc/ps3: Fix system hang with GCC 5 builds

Nicholas Piggin <npiggin@gmail.com>
    powerpc/64e: Convert cmpi to cmpwi in head_64.S

NeilBrown <neilb@suse.com>
    SUNRPC: fix refcounting problems with auth_gss messages.

Trond Myklebust <trond.myklebust@primarydata.com>
    pNFS: Fix a deadlock between read resends and layoutreturn

Trond Myklebust <trond.myklebust@primarydata.com>
    pNFS: Clear NFS_LAYOUT_RETURN_REQUESTED when invalidating the layout stateid

Trond Myklebust <trond.myklebust@primarydata.com>
    pNFS: Don't clear the layout stateid if a layout return is outstanding

Trond Myklebust <trond.myklebust@primarydata.com>
    pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed

Al Viro <viro@zeniv.linux.org.uk>
    nfs_write_end(): fix handling of short copies

Ilya Dryomov <idryomov@gmail.com>
    libceph: verify authorize reply on connect

Alan Stern <stern@rowland.harvard.edu>
    PCI: Check for PME in targeted sleep state

Shiraz Saleem <shiraz.saleem@intel.com>
    i40iw: Use correct src address in memcpy to rdma stats counters

Miklos Szeredi <mszeredi@redhat.com>
    bad_inode: add missing i_op initializers

Jingkui Wang <jkwang@google.com>
    Input: drv260x - fix input device's parent assignment

Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    v4l: tvp5150: Add missing break in set control handler

Andrey Utkin <andrey.utkin@corp.bluecherry.net>
    media: solo6x10: fix lockup by avoiding delayed register write

Marek Szyprowski <m.szyprowski@samsung.com>
    s5p-mfc: fix failure path of s5p_mfc_alloc_memdev()

Antti Palosaari <crope@iki.fi>
    mn88473: fix chip id check on probe

Antti Palosaari <crope@iki.fi>
    mn88472: fix chip id check on probe

Bart Van Assche <bart.vanassche@sandisk.com>
    IB/cma: Fix a race condition in iboe_addr_get_sgid()

Bart Van Assche <bart.vanassche@sandisk.com>
    IB/rxe: Fix a memory leak in rxe_qp_cleanup()

Bart Van Assche <bart.vanassche@sandisk.com>
    IB/multicast: Check ib_find_pkey() return value

Bart Van Assche <bart.vanassche@sandisk.com>
    IPoIB: Avoid reading an uninitialized member variable

Bart Van Assche <bart.vanassche@sandisk.com>
    IB/mad: Fix an array index check

Steven Rostedt (Red Hat) <rostedt@goodmis.org>
    fgraph: Handle a case where a tracer ignores set_graph_notrace

Thomas Gleixner <tglx@linutronix.de>
    x86/smpboot: Make logical package management more robust

Marcos Paulo de Souza <marcos.souza.org@gmail.com>
    platform/x86: asus-nb-wmi.c: Add X45U quirk

Steven Rostedt (Red Hat) <rostedt@goodmis.org>
    ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it

Michael S. Tsirkin <mst@redhat.com>
    vsock/virtio: fix src/dst cid format

Jan Kara <jack@suse.cz>
    fsnotify: Fix possible use-after-free in inode iteration on umount

Jim Mattson <jmattson@google.com>
    kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

Paul Mackerras <paulus@ozlabs.org>
    KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT

Paul Mackerras <paulus@ozlabs.org>
    KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

Kevin Barnett <kevin.barnett@microsemi.com>
    scsi: aacraid: remove wildcard for series 9 controllers

Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    md/raid5: limit request size according to implementation limits

Josh Cartwright <joshc@ni.com>
    sc16is7xx: Drop bogus use of IRQF_ONESHOT

Kees Cook <keescook@chromium.org>
    latent_entropy: fix ARM build error on earlier gcc

Marc Zyngier <marc.zyngier@arm.com>
    arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest

Heiko Carstens <heiko.carstens@de.ibm.com>
    s390/kexec: use node 0 when re-adding crash kernel memory

Gerald Schaefer <gerald.schaefer@de.ibm.com>
    s390/vmlogrdr: fix IUCV buffer allocation

Yves-Alexis Perez <corsac@corsac.net>
    firmware: fix usermode helper fallback loading

Vineet Gupta <vgupta@synopsys.com>
    ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache

Wei Fang <fangwei1@huawei.com>
    scsi: avoid a permanent stop of the scsi device's request queue

Steffen Maier <maier@linux.vnet.ibm.com>
    scsi: zfcp: fix rport unblock race with LUN recovery

Steffen Maier <maier@linux.vnet.ibm.com>
    scsi: zfcp: do not trace pure benign residual HBA responses at default level

Benjamin Block <bblock@linux.vnet.ibm.com>
    scsi: zfcp: fix use-after-"free" in FC ingress path after TMF

Varun Prakash <varun@chelsio.com>
    iscsi-target: Return error if unable to add network portal

Kashyap Desai <kashyap.desai@broadcom.com>
    scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

Kashyap Desai <kashyap.desai@broadcom.com>
    scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

Johan Hovold <johan@kernel.org>
    stm class: Fix device leak in open error path

Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    vt: fix Scroll Lock LED trigger name

Rabin Vincent <rabinv@axis.com>
    block: protect iterate_bdevs() against concurrent close

Tomas Winkler <tomas.winkler@intel.com>
    mei: me: add lewisburg device ids

Alexander Usyskin <alexander.usyskin@intel.com>
    mei: request async autosuspend at the end of enumeration

Russell Currey <ruscur@russell.cc>
    drivers/gpu/drm/ast: Fix infinite loop if read fails

Rex Zhu <Rex.Zhu@amd.com>
    drm/amdgpu: fix init save/restore list in gfx_v8.0

Rex Zhu <Rex.Zhu@amd.com>
    drm/amdgpu: fix enable_cp_power_gating in gfx_v8.0.

Hawking Zhang <Hawking.Zhang@amd.com>
    drm/amd/powerplay: bypass fan table setup if no fan connected

Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    drm/gma500: Add compat ioctl

Alex Deucher <alexander.deucher@amd.com>
    drm/radeon/si: load the proper firmware on 0x87 oland boards

Alex Deucher <alexander.deucher@amd.com>
    drm/radeon: add additional pci revision to dpm workaround

Michel Dänzer <michel.daenzer@amd.com>
    drm/radeon: Hide the HW cursor while it's out of bounds

Michel Dänzer <michel.daenzer@amd.com>
    drm/radeon: Also call cursor_move_locked when the cursor size changes

Ben Skeggs <bskeggs@redhat.com>
    drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex

Ben Skeggs <bskeggs@redhat.com>
    drm/nouveau/i2c/gk110b,gm10x: use the correct implementation

Ben Skeggs <bskeggs@redhat.com>
    drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas

Ben Skeggs <bskeggs@redhat.com>
    drm/nouveau/ltc: protect clearing of comptags with mutex

Ben Skeggs <bskeggs@redhat.com>
    drm/nouveau/bios: require checksum to match for fast acpi shadow method

Ben Skeggs <bskeggs@redhat.com>
    drm/nouveau/kms: lvds panel strap moved again on maxwell

Alexandre Courbot <acourbot@nvidia.com>
    drm/nouveau/gr: fallback to legacy paths during firmware lookup

Arindam Nath <arindam.nath@amd.com>
    drm/amd/amdgpu: enable GUI idle INT after enabling CGCG

Michel Dänzer <michel.daenzer@amd.com>
    drm/amdgpu: Also call cursor_move_locked when the cursor size changes

Michel Dänzer <michel.daenzer@amd.com>
    drm/amdgpu: Store CRTC relative amdgpu_crtc->cursor_x/y values

Alex Deucher <alexander.deucher@amd.com>
    drm/amdgpu: add additional pci revision to dpm workaround

Alex Deucher <alexander.deucher@amd.com>
    drm/amdgpu/si: load the proper firmware on 0x87 oland boards

Hans de Goede <hdegoede@redhat.com>
    ACPI / video: Add force_native quirk for HP Pavilion dv6

Hans de Goede <hdegoede@redhat.com>
    ACPI / video: Add force_native quirk for Dell XPS 17 L702X

Ian Abbott <abbotti@mev.co.uk>
    staging: comedi: ni_mio_common: fix E series ni_ai_insn_read() data

Ian Abbott <abbotti@mev.co.uk>
    staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask

Arnd Bergmann <arnd@arndb.de>
    staging: lustre: ldlm: pl_recalc time handling is wrong

Oleg Drokin <green@linuxhacker.ru>
    staging/lustre/osc: Revert erroneous list_for_each_entry_safe use

Vitaly Kuznetsov <vkuznets@redhat.com>
    hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels()

Dmitry Shachnev <mitya57@debian.org>
    docs: sphinx-extensions: make rstFlatTable work with docutils 0.13

Krzysztof Kozlowski <krzk@kernel.org>
    thermal: hwmon: Properly report critical temperature in sysfs

Boris Brezillon <boris.brezillon@free-electrons.com>
    clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk

Alexandre Courbot <acourbot@nvidia.com>
    arm64: tegra: Add VDD_GPU regulator to Jetson TX1

Lars-Peter Clausen <lars@metafoo.de>
    gpio: chardev: Return error for seek operations

Linus Walleij <linus.walleij@linaro.org>
    gpio: stmpe: fix interrupt handling bug

Thomas Gleixner <tglx@linutronix.de>
    timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion

Paul Burton <paul.burton@imgtec.com>
    mmc: sd: Meet alignment requirements for raw_ssr DMA

Linus Walleij <linus.walleij@linaro.org>
    regulator: stw481x-vmmc: fix ages old enable error

Adrian Hunter <adrian.hunter@intel.com>
    mmc: sdhci: Fix recovery from tuning timeout

Adrian Hunter <adrian.hunter@intel.com>
    Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"

Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
    ath9k: do not return early to fix rcu unlocking

Vittorio Gambaletta (VittGam) <linux-wireless@vittgam.net>
    ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.

Matthias Schiffer <mschiffer@universe-factory.net>
    ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success

Johannes Berg <johannes.berg@intel.com>
    cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts

Jes Sorensen <Jes.Sorensen@redhat.com>
    rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting

Thomas Gleixner <tglx@linutronix.de>
    perf/x86/intel/cstate: Prevent hotplug callback leak

Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
    perf annotate: Don't throw error for zero length symbols

Andi Kleen <ak@linux.intel.com>
    perf/x86: Fix exclusion of BTS and LBR for Goldmont

Larry Finger <Larry.Finger@lwfinger.net>
    rtlwifi: Fix enter/exit power_save

Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
    ath10k: fix soft lockup during firmware crash/hw-restart

Larry Finger <Larry.Finger@lwfinger.net>
    ssb: Fix error routine when fallback SPROM fails


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

Diffstat:

 Documentation/sphinx/rstFlatTable.py               |  5 ++
 Documentation/virtual/kvm/api.txt                  |  1 +
 Makefile                                           |  4 +-
 arch/arc/include/asm/cacheflush.h                  |  6 +-
 arch/arc/mm/cache.c                                | 13 ++--
 arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi     | 18 ++++++
 arch/arm64/kvm/hyp/switch.c                        |  8 ++-
 arch/powerpc/boot/ps3-head.S                       |  5 --
 arch/powerpc/boot/ps3.c                            |  8 +--
 arch/powerpc/boot/wrapper                          | 24 +++++++-
 arch/powerpc/include/asm/kvm_host.h                |  1 +
 arch/powerpc/include/uapi/asm/kvm.h                |  1 +
 arch/powerpc/kernel/asm-offsets.c                  |  1 +
 arch/powerpc/kernel/head_64.S                      |  8 +--
 arch/powerpc/kvm/book3s_hv.c                       |  6 ++
 arch/powerpc/kvm/book3s_hv_rm_mmu.c                |  2 +
 arch/powerpc/kvm/book3s_hv_rmhandlers.S            |  4 ++
 arch/s390/kernel/setup.c                           |  2 +-
 arch/x86/entry/entry_32.S                          |  4 +-
 arch/x86/events/core.c                             |  8 ++-
 arch/x86/events/intel/cstate.c                     | 14 ++---
 arch/x86/events/perf_event.h                       |  2 +-
 arch/x86/kernel/apic/apic.c                        | 15 -----
 arch/x86/kernel/cpu/common.c                       | 24 +++-----
 arch/x86/kernel/smpboot.c                          | 51 ++++++----------
 arch/x86/kvm/vmx.c                                 | 11 ++--
 arch/x86/xen/smp.c                                 |  6 --
 block/bsg.c                                        |  3 +
 drivers/acpi/video_detect.c                        | 20 +++++++
 drivers/base/firmware_class.c                      |  7 ++-
 drivers/clk/bcm/clk-bcm2835.c                      |  4 +-
 drivers/gpio/gpio-stmpe.c                          |  2 +-
 drivers/gpio/gpiolib.c                             |  5 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c             | 15 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c             | 15 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c              | 14 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c              | 15 ++---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c              | 28 +++++----
 drivers/gpu/drm/amd/amdgpu/si_dpm.c                |  2 +
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c    |  6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c |  6 ++
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  6 ++
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  6 ++
 drivers/gpu/drm/ast/ast_main.c                     |  7 ++-
 drivers/gpu/drm/gma500/psb_drv.c                   |  3 +
 drivers/gpu/drm/i915/i915_gem_stolen.c             |  5 +-
 drivers/gpu/drm/i915/i915_sysfs.c                  |  2 +-
 drivers/gpu/drm/i915/intel_display.c               |  9 ++-
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c         |  3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c            | 13 +++-
 drivers/gpu/drm/nouveau/nouveau_bios.c             |  3 +
 drivers/gpu/drm/nouveau/nouveau_bo.c               |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  6 +-
 .../gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c |  9 ++-
 .../gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c |  8 ++-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c     | 50 ++++++++++++++--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h    |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c  |  7 ++-
 .../gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c  |  1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/base.c     |  2 +
 drivers/gpu/drm/radeon/radeon_cursor.c             | 69 +++++++++++++++-------
 drivers/gpu/drm/radeon/radeon_mode.h               |  1 +
 drivers/gpu/drm/radeon/si.c                        |  1 +
 drivers/gpu/drm/radeon/si_dpm.c                    |  1 +
 drivers/hv/channel_mgmt.c                          |  2 +
 drivers/hwtracing/stm/core.c                       |  8 ++-
 drivers/infiniband/core/mad.c                      |  2 +-
 drivers/infiniband/core/multicast.c                |  7 ++-
 drivers/infiniband/hw/i40iw/i40iw_verbs.c          |  2 +-
 drivers/infiniband/sw/rxe/rxe_qp.c                 |  1 +
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c     |  7 ++-
 drivers/input/misc/drv260x.c                       |  1 -
 drivers/md/raid5.c                                 |  9 +++
 drivers/media/dvb-frontends/mn88472.c              | 24 ++++----
 drivers/media/dvb-frontends/mn88473.c              | 24 ++++----
 drivers/media/i2c/tvp5150.c                        |  1 +
 drivers/media/pci/solo6x10/solo6x10.h              |  3 +
 drivers/media/platform/s5p-mfc/s5p_mfc.c           |  1 +
 drivers/misc/mei/client.c                          |  2 +-
 drivers/misc/mei/hw-me-regs.h                      |  2 +
 drivers/misc/mei/pci-me.c                          |  1 +
 drivers/mmc/core/sd.c                              | 12 +++-
 drivers/mmc/host/sdhci.c                           | 24 ++++++--
 drivers/net/ethernet/marvell/mvpp2.c               | 59 +++++++++---------
 drivers/net/wireless/ath/ath10k/core.c             |  2 +-
 drivers/net/wireless/ath/ath10k/mac.c              |  1 -
 drivers/net/wireless/ath/ath9k/hw.c                |  2 +-
 drivers/net/wireless/ath/ath9k/pci.c               |  7 ++-
 drivers/net/wireless/ath/ath9k/xmit.c              |  2 +-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  |  8 +++
 drivers/net/wireless/realtek/rtlwifi/base.c        |  8 +--
 drivers/net/wireless/realtek/rtlwifi/core.c        |  9 +--
 drivers/net/wireless/realtek/rtlwifi/pci.c         | 14 ++---
 drivers/net/wireless/realtek/rtlwifi/ps.c          | 36 ++++++++---
 drivers/nvdimm/pfn_devs.c                          |  2 +-
 drivers/of/of_numa.c                               |  7 ++-
 drivers/pci/pci.c                                  |  4 ++
 drivers/platform/x86/asus-nb-wmi.c                 |  9 +++
 drivers/regulator/stw481x-vmmc.c                   |  3 +-
 drivers/s390/char/vmlogrdr.c                       |  2 +-
 drivers/s390/scsi/zfcp_dbf.c                       | 17 +++++-
 drivers/s390/scsi/zfcp_dbf.h                       | 41 ++++++++++++-
 drivers/s390/scsi/zfcp_erp.c                       | 61 ++++++++++++++++++-
 drivers/s390/scsi/zfcp_ext.h                       |  4 +-
 drivers/s390/scsi/zfcp_fsf.h                       |  3 +-
 drivers/s390/scsi/zfcp_reqlist.h                   | 30 +++++++++-
 drivers/s390/scsi/zfcp_scsi.c                      | 61 +++++++++++++++++--
 drivers/scsi/aacraid/linit.c                       |  2 -
 drivers/scsi/megaraid/megaraid_sas_fusion.c        |  9 +--
 drivers/scsi/scsi_sysfs.c                          |  4 --
 drivers/scsi/sg.c                                  |  3 +
 drivers/ssb/pci.c                                  |  1 +
 drivers/staging/comedi/drivers/ni_mio_common.c     |  7 +--
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c     |  8 +--
 drivers/staging/lustre/lustre/osc/osc_page.c       |  5 +-
 drivers/target/iscsi/iscsi_target_configfs.c       |  4 +-
 drivers/target/target_core_user.c                  |  2 -
 drivers/thermal/thermal_hwmon.c                    |  2 +-
 drivers/tty/serial/sc16is7xx.c                     |  2 +-
 drivers/tty/vt/keyboard.c                          |  2 +-
 fs/bad_inode.c                                     | 55 +++++++++++++++--
 fs/block_dev.c                                     |  7 ++-
 fs/nfs/file.c                                      |  2 +-
 fs/nfs/flexfilelayout/flexfilelayout.c             |  4 ++
 fs/nfs/pnfs.c                                      | 31 ++++++----
 fs/nfs/pnfs.h                                      |  1 +
 fs/notify/inode_mark.c                             | 45 +++-----------
 include/net/cfg80211.h                             | 11 ++++
 include/rdma/ib_addr.h                             |  6 +-
 kernel/time/timekeeping.c                          |  4 +-
 kernel/trace/trace_functions_graph.c               | 17 +++++-
 net/ceph/messenger.c                               | 13 ++++
 net/mac80211/mlme.c                                | 21 ++++---
 net/sunrpc/auth_gss/auth_gss.c                     |  7 ++-
 net/vmw_vsock/virtio_transport_common.c            | 14 ++---
 net/wireless/core.h                                |  1 +
 net/wireless/mlme.c                                | 12 ++++
 net/wireless/sme.c                                 | 14 +++++
 scripts/gcc-plugins/latent_entropy_plugin.c        |  4 +-
 scripts/kconfig/nconf.gui.c                        | 15 +++--
 tools/perf/util/annotate.c                         |  3 +-
 141 files changed, 1032 insertions(+), 439 deletions(-)

[PATCH 4.9 001/116] ssb: Fix error routine when fallback SPROM fails

[Greg Kroah-Hartman]

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

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

From: Larry Finger <Larry.Finger@lwfinger.net>

commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream.

When there is a CRC error in the SPROM read from the device, the code
attempts to handle a fallback SPROM. When this also fails, the driver
returns zero rather than an error code.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/ssb/pci.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -909,6 +909,7 @@ static int ssb_pci_sprom_get(struct ssb_
 			if (err) {
 				ssb_warn("WARNING: Using fallback SPROM failed (err %d)\n",
 					 err);
+				goto out_free;
 			} else {
 				ssb_dbg("Using SPROM revision %d provided by platform\n",
 					sprom->revision);

[PATCH 4.9 002/116] ath10k: fix soft lockup during firmware crash/hw-restart

[Greg Kroah-Hartman]

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

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

From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>

commit c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 upstream.

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/ath/ath10k/core.c |    2 +-
 drivers/net/wireless/ath/ath10k/mac.c  |    1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1534,7 +1534,7 @@ static void ath10k_core_restart(struct w
 	switch (ar->state) {
 	case ATH10K_STATE_ON:
 		ar->state = ATH10K_STATE_RESTARTING;
-		ath10k_hif_stop(ar);
+		ath10k_halt(ar);
 		ath10k_scan_finish(ar);
 		ieee80211_restart_hw(ar->hw);
 		break;
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211
 		ar->state = ATH10K_STATE_ON;
 		break;
 	case ATH10K_STATE_RESTARTING:
-		ath10k_halt(ar);
 		ar->state = ATH10K_STATE_RESTARTED;
 		break;
 	case ATH10K_STATE_ON:

[PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Greg Kroah-Hartman]

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

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

From: Larry Finger <Larry.Finger@lwfinger.net>

commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.

In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
to use work queue"), an error was introduced in the power-save routines
due to the fact that leaving PS was delayed by the use of a work queue.

This problem is fixed by detecting if the enter or leave routines are
in interrupt mode. If so, the workqueue is used to place the request.
If in normal mode, the enter or leave routines are called directly.

Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
Reported-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/realtek/rtlwifi/base.c |    8 +++---
 drivers/net/wireless/realtek/rtlwifi/core.c |    9 ++-----
 drivers/net/wireless/realtek/rtlwifi/pci.c  |   14 +++-------
 drivers/net/wireless/realtek/rtlwifi/ps.c   |   36 +++++++++++++++++++++-------
 4 files changed, 40 insertions(+), 27 deletions(-)

--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1303,12 +1303,13 @@ EXPORT_SYMBOL_GPL(rtl_action_proc);
 
 static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc)
 {
+	struct ieee80211_hw *hw = rtlpriv->hw;
+
 	rtlpriv->ra.is_special_data = true;
 	if (rtlpriv->cfg->ops->get_btc_status())
 		rtlpriv->btcoexist.btc_ops->btc_special_packet_notify(
 					rtlpriv, 1);
-	rtlpriv->enter_ps = false;
-	schedule_work(&rtlpriv->works.lps_change_work);
+	rtl_lps_leave(hw);
 	ppsc->last_delaylps_stamp_jiffies = jiffies;
 }
 
@@ -1381,8 +1382,7 @@ u8 rtl_is_special_data(struct ieee80211_
 
 		if (is_tx) {
 			rtlpriv->ra.is_special_data = true;
-			rtlpriv->enter_ps = false;
-			schedule_work(&rtlpriv->works.lps_change_work);
+			rtl_lps_leave(hw);
 			ppsc->last_delaylps_stamp_jiffies = jiffies;
 		}
 
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1150,10 +1150,8 @@ static void rtl_op_bss_info_changed(stru
 		} else {
 			mstatus = RT_MEDIA_DISCONNECT;
 
-			if (mac->link_state == MAC80211_LINKED) {
-				rtlpriv->enter_ps = false;
-				schedule_work(&rtlpriv->works.lps_change_work);
-			}
+			if (mac->link_state == MAC80211_LINKED)
+				rtl_lps_leave(hw);
 			if (ppsc->p2p_ps_info.p2p_ps_mode > P2P_PS_NONE)
 				rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE);
 			mac->link_state = MAC80211_NOLINK;
@@ -1431,8 +1429,7 @@ static void rtl_op_sw_scan_start(struct
 	}
 
 	if (mac->link_state == MAC80211_LINKED) {
-		rtlpriv->enter_ps = false;
-		schedule_work(&rtlpriv->works.lps_change_work);
+		rtl_lps_leave(hw);
 		mac->link_state = MAC80211_LINKED_SCANNING;
 	} else {
 		rtl_ips_nic_on(hw);
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -663,11 +663,9 @@ tx_status_ok:
 	}
 
 	if (((rtlpriv->link_info.num_rx_inperiod +
-		rtlpriv->link_info.num_tx_inperiod) > 8) ||
-		(rtlpriv->link_info.num_rx_inperiod > 2)) {
-		rtlpriv->enter_ps = false;
-		schedule_work(&rtlpriv->works.lps_change_work);
-	}
+	      rtlpriv->link_info.num_tx_inperiod) > 8) ||
+	      (rtlpriv->link_info.num_rx_inperiod > 2))
+		rtl_lps_leave(hw);
 }
 
 static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw,
@@ -918,10 +916,8 @@ new_trx_end:
 		}
 		if (((rtlpriv->link_info.num_rx_inperiod +
 		      rtlpriv->link_info.num_tx_inperiod) > 8) ||
-		      (rtlpriv->link_info.num_rx_inperiod > 2)) {
-			rtlpriv->enter_ps = false;
-			schedule_work(&rtlpriv->works.lps_change_work);
-		}
+		      (rtlpriv->link_info.num_rx_inperiod > 2))
+			rtl_lps_leave(hw);
 		skb = new_skb;
 no_new:
 		if (rtlpriv->use_new_trx_flow) {
--- a/drivers/net/wireless/realtek/rtlwifi/ps.c
+++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
@@ -407,8 +407,8 @@ void rtl_lps_set_psmode(struct ieee80211
 	}
 }
 
-/*Enter the leisure power save mode.*/
-void rtl_lps_enter(struct ieee80211_hw *hw)
+/* Interrupt safe routine to enter the leisure power save mode.*/
+static void rtl_lps_enter_core(struct ieee80211_hw *hw)
 {
 	struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
 	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
@@ -444,10 +444,9 @@ void rtl_lps_enter(struct ieee80211_hw *
 
 	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
 }
-EXPORT_SYMBOL(rtl_lps_enter);
 
-/*Leave the leisure power save mode.*/
-void rtl_lps_leave(struct ieee80211_hw *hw)
+/* Interrupt safe routine to leave the leisure power save mode.*/
+static void rtl_lps_leave_core(struct ieee80211_hw *hw)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
 	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
@@ -477,7 +476,6 @@ void rtl_lps_leave(struct ieee80211_hw *
 	}
 	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
 }
-EXPORT_SYMBOL(rtl_lps_leave);
 
 /* For sw LPS*/
 void rtl_swlps_beacon(struct ieee80211_hw *hw, void *data, unsigned int len)
@@ -670,12 +668,34 @@ void rtl_lps_change_work_callback(struct
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
 
 	if (rtlpriv->enter_ps)
-		rtl_lps_enter(hw);
+		rtl_lps_enter_core(hw);
 	else
-		rtl_lps_leave(hw);
+		rtl_lps_leave_core(hw);
 }
 EXPORT_SYMBOL_GPL(rtl_lps_change_work_callback);
 
+void rtl_lps_enter(struct ieee80211_hw *hw)
+{
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+	if (!in_interrupt())
+		return rtl_lps_enter_core(hw);
+	rtlpriv->enter_ps = true;
+	schedule_work(&rtlpriv->works.lps_change_work);
+}
+EXPORT_SYMBOL_GPL(rtl_lps_enter);
+
+void rtl_lps_leave(struct ieee80211_hw *hw)
+{
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+	if (!in_interrupt())
+		return rtl_lps_leave_core(hw);
+	rtlpriv->enter_ps = false;
+	schedule_work(&rtlpriv->works.lps_change_work);
+}
+EXPORT_SYMBOL_GPL(rtl_lps_leave);
+
 void rtl_swlps_wq_callback(void *data)
 {
 	struct rtl_works *rtlworks = container_of_dwork_rtl(data,

[PATCH 4.9 004/116] perf/x86: Fix exclusion of BTS and LBR for Goldmont

[Greg Kroah-Hartman]

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

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

From: Andi Kleen <ak@linux.intel.com>

commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream.

An earlier patch allowed enabling PT and LBR at the same
time on Goldmont. However it also allowed enabling BTS and LBR
at the same time, which is still not supported. Fix this by
bypassing the check only for PT.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: alexander.shishkin@intel.com
Cc: kan.liang@intel.com
Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
Link: http://lkml.kernel.org/r/20161209001417.4713-1-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/events/core.c       |    8 ++++++--
 arch/x86/events/perf_event.h |    2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -365,7 +365,11 @@ int x86_add_exclusive(unsigned int what)
 {
 	int i;
 
-	if (x86_pmu.lbr_pt_coexist)
+	/*
+	 * When lbr_pt_coexist we allow PT to coexist with either LBR or BTS.
+	 * LBR and BTS are still mutually exclusive.
+	 */
+	if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
 		return 0;
 
 	if (!atomic_inc_not_zero(&x86_pmu.lbr_exclusive[what])) {
@@ -388,7 +392,7 @@ fail_unlock:
 
 void x86_del_exclusive(unsigned int what)
 {
-	if (x86_pmu.lbr_pt_coexist)
+	if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt)
 		return;
 
 	atomic_dec(&x86_pmu.lbr_exclusive[what]);
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -604,7 +604,7 @@ struct x86_pmu {
 	u64		lbr_sel_mask;		   /* LBR_SELECT valid bits */
 	const int	*lbr_sel_map;		   /* lbr_select mappings */
 	bool		lbr_double_abort;	   /* duplicated lbr aborts */
-	bool		lbr_pt_coexist;		   /* LBR may coexist with PT */
+	bool		lbr_pt_coexist;		   /* (LBR|BTS) may coexist with PT */
 
 	/*
 	 * Intel PT/LBR/BTS are exclusive

[PATCH 4.9 005/116] perf annotate: Dont throw error for zero length symbols

[Greg Kroah-Hartman]

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

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

From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>

commit edee44be59190bf22d5c6e521f3852b7ff16862f upstream.

'perf report --tui' exits with error when it finds a sample of zero
length symbol (i.e. addr == sym->start == sym->end). Actually these are
valid samples. Don't exit TUI and show report with such symbols.

Reported-and-Tested-by: Anton Blanchard <anton@samba.org>
Link: https://lkml.org/lkml/2016/10/8/189
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Riyder <chris.ryder@arm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1479804050-5028-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/perf/util/annotate.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -593,7 +593,8 @@ static int __symbol__inc_addr_samples(st
 
 	pr_debug3("%s: addr=%#" PRIx64 "\n", __func__, map->unmap_ip(map, addr));
 
-	if (addr < sym->start || addr >= sym->end) {
+	if ((addr < sym->start || addr >= sym->end) &&
+	    (addr != sym->end || sym->start != sym->end)) {
 		pr_debug("%s(%d): ERANGE! sym->name=%s, start=%#" PRIx64 ", addr=%#" PRIx64 ", end=%#" PRIx64 "\n",
 		       __func__, __LINE__, sym->name, sym->start, addr, sym->end);
 		return -ERANGE;

[PATCH 4.9 006/116] perf/x86/intel/cstate: Prevent hotplug callback leak

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream.

If the pmu registration fails the registered hotplug callbacks are not
removed. Wrong in any case, but fatal in case of a modular driver.

Replace the nonsensical state names with proper ones while at it.

Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug state machine")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/events/intel/cstate.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -594,6 +594,9 @@ static int __init cstate_probe(const str
 
 static inline void cstate_cleanup(void)
 {
+	cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE);
+	cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING);
+
 	if (has_cstate_core)
 		perf_pmu_unregister(&cstate_core_pmu);
 
@@ -606,16 +609,16 @@ static int __init cstate_init(void)
 	int err;
 
 	cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_STARTING,
-			  "AP_PERF_X86_CSTATE_STARTING", cstate_cpu_init,
-			  NULL);
+			  "perf/x86/cstate:starting", cstate_cpu_init, NULL);
 	cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_ONLINE,
-			  "AP_PERF_X86_CSTATE_ONLINE", NULL, cstate_cpu_exit);
+			  "perf/x86/cstate:online", NULL, cstate_cpu_exit);
 
 	if (has_cstate_core) {
 		err = perf_pmu_register(&cstate_core_pmu, cstate_core_pmu.name, -1);
 		if (err) {
 			has_cstate_core = false;
 			pr_info("Failed to register cstate core pmu\n");
+			cstate_cleanup();
 			return err;
 		}
 	}
@@ -629,8 +632,7 @@ static int __init cstate_init(void)
 			return err;
 		}
 	}
-
-	return err;
+	return 0;
 }
 
 static int __init cstate_pmu_init(void)
@@ -655,8 +657,6 @@ module_init(cstate_pmu_init);
 
 static void __exit cstate_pmu_exit(void)
 {
-	cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE);
-	cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING);
 	cstate_cleanup();
 }
 module_exit(cstate_pmu_exit);

[PATCH 4.9 007/116] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting

[Greg Kroah-Hartman]

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

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

From: Jes Sorensen <Jes.Sorensen@redhat.com>

commit c59f13bbead475096bdfebc7ef59c12e180858de upstream.

The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
8723bu devices not being able to reconnect.

Reported-by: Barry Day <briselec@gmail.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4372,6 +4372,13 @@ void rtl8xxxu_gen1_report_connect(struct
 void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
 				  u8 macid, bool connect)
 {
+#ifdef RTL8XXXU_GEN2_REPORT_CONNECT
+	/*
+	 * Barry Day reports this causes issues with 8192eu and 8723bu
+	 * devices reconnecting. The reason for this is unclear, but
+	 * until it is better understood, leave the code in place but
+	 * disabled, so it is not lost.
+	 */
 	struct h2c_cmd h2c;
 
 	memset(&h2c, 0, sizeof(struct h2c_cmd));
@@ -4383,6 +4390,7 @@ void rtl8xxxu_gen2_report_connect(struct
 		h2c.media_status_rpt.parm &= ~BIT(0);
 
 	rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt));
+#endif
 }
 
 void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)

[PATCH 4.9 008/116] cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts

[Greg Kroah-Hartman]

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

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

From: Johannes Berg <johannes.berg@intel.com>

commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream.

When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.

Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.

This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/net/cfg80211.h |   11 +++++++++++
 net/mac80211/mlme.c    |   21 ++++++++++++---------
 net/wireless/core.h    |    1 +
 net/wireless/mlme.c    |   12 ++++++++++++
 net/wireless/sme.c     |   14 ++++++++++++++
 5 files changed, 50 insertions(+), 9 deletions(-)

--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4584,6 +4584,17 @@ void cfg80211_rx_assoc_resp(struct net_d
 void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss);
 
 /**
+ * cfg80211_abandon_assoc - notify cfg80211 of abandoned association attempt
+ * @dev: network device
+ * @bss: The BSS entry with which association was abandoned.
+ *
+ * Call this whenever - for reasons reported through other API, like deauth RX,
+ * an association attempt was abandoned.
+ * This function may sleep. The caller must hold the corresponding wdev's mutex.
+ */
+void cfg80211_abandon_assoc(struct net_device *dev, struct cfg80211_bss *bss);
+
+/**
  * cfg80211_tx_mlme_mgmt - notification of transmitted deauth/disassoc frame
  * @dev: network device
  * @buf: 802.11 frame (header + body)
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2510,7 +2510,7 @@ static void ieee80211_destroy_auth_data(
 }
 
 static void ieee80211_destroy_assoc_data(struct ieee80211_sub_if_data *sdata,
-					 bool assoc)
+					 bool assoc, bool abandon)
 {
 	struct ieee80211_mgd_assoc_data *assoc_data = sdata->u.mgd.assoc_data;
 
@@ -2533,6 +2533,9 @@ static void ieee80211_destroy_assoc_data
 		mutex_lock(&sdata->local->mtx);
 		ieee80211_vif_release_channel(sdata);
 		mutex_unlock(&sdata->local->mtx);
+
+		if (abandon)
+			cfg80211_abandon_assoc(sdata->dev, assoc_data->bss);
 	}
 
 	kfree(assoc_data);
@@ -2762,7 +2765,7 @@ static void ieee80211_rx_mgmt_deauth(str
 			   bssid, reason_code,
 			   ieee80211_get_reason_code_string(reason_code));
 
-		ieee80211_destroy_assoc_data(sdata, false);
+		ieee80211_destroy_assoc_data(sdata, false, true);
 
 		cfg80211_rx_mlme_mgmt(sdata->dev, (u8 *)mgmt, len);
 		return;
@@ -3167,14 +3170,14 @@ static void ieee80211_rx_mgmt_assoc_resp
 	if (status_code != WLAN_STATUS_SUCCESS) {
 		sdata_info(sdata, "%pM denied association (code=%d)\n",
 			   mgmt->sa, status_code);
-		ieee80211_destroy_assoc_data(sdata, false);
+		ieee80211_destroy_assoc_data(sdata, false, false);
 		event.u.mlme.status = MLME_DENIED;
 		event.u.mlme.reason = status_code;
 		drv_event_callback(sdata->local, sdata, &event);
 	} else {
 		if (!ieee80211_assoc_success(sdata, bss, mgmt, len)) {
 			/* oops -- internal error -- send timeout for now */
-			ieee80211_destroy_assoc_data(sdata, false);
+			ieee80211_destroy_assoc_data(sdata, false, false);
 			cfg80211_assoc_timeout(sdata->dev, bss);
 			return;
 		}
@@ -3187,7 +3190,7 @@ static void ieee80211_rx_mgmt_assoc_resp
 		 * recalc after assoc_data is NULL but before associated
 		 * is set can cause the interface to go idle
 		 */
-		ieee80211_destroy_assoc_data(sdata, true);
+		ieee80211_destroy_assoc_data(sdata, true, false);
 
 		/* get uapsd queues configuration */
 		uapsd_queues = 0;
@@ -3886,7 +3889,7 @@ void ieee80211_sta_work(struct ieee80211
 				.u.mlme.status = MLME_TIMEOUT,
 			};
 
-			ieee80211_destroy_assoc_data(sdata, false);
+			ieee80211_destroy_assoc_data(sdata, false, false);
 			cfg80211_assoc_timeout(sdata->dev, bss);
 			drv_event_callback(sdata->local, sdata, &event);
 		}
@@ -4025,7 +4028,7 @@ void ieee80211_mgd_quiesce(struct ieee80
 					       WLAN_REASON_DEAUTH_LEAVING,
 					       false, frame_buf);
 		if (ifmgd->assoc_data)
-			ieee80211_destroy_assoc_data(sdata, false);
+			ieee80211_destroy_assoc_data(sdata, false, true);
 		if (ifmgd->auth_data)
 			ieee80211_destroy_auth_data(sdata, false);
 		cfg80211_tx_mlme_mgmt(sdata->dev, frame_buf,
@@ -4907,7 +4910,7 @@ int ieee80211_mgd_deauth(struct ieee8021
 					       IEEE80211_STYPE_DEAUTH,
 					       req->reason_code, tx,
 					       frame_buf);
-		ieee80211_destroy_assoc_data(sdata, false);
+		ieee80211_destroy_assoc_data(sdata, false, true);
 		ieee80211_report_disconnect(sdata, frame_buf,
 					    sizeof(frame_buf), true,
 					    req->reason_code);
@@ -4982,7 +4985,7 @@ void ieee80211_mgd_stop(struct ieee80211
 	sdata_lock(sdata);
 	if (ifmgd->assoc_data) {
 		struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
-		ieee80211_destroy_assoc_data(sdata, false);
+		ieee80211_destroy_assoc_data(sdata, false, false);
 		cfg80211_assoc_timeout(sdata->dev, bss);
 	}
 	if (ifmgd->auth_data)
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -410,6 +410,7 @@ void cfg80211_sme_disassoc(struct wirele
 void cfg80211_sme_deauth(struct wireless_dev *wdev);
 void cfg80211_sme_auth_timeout(struct wireless_dev *wdev);
 void cfg80211_sme_assoc_timeout(struct wireless_dev *wdev);
+void cfg80211_sme_abandon_assoc(struct wireless_dev *wdev);
 
 /* internal helpers */
 bool cfg80211_supported_cipher_suite(struct wiphy *wiphy, u32 cipher);
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -149,6 +149,18 @@ void cfg80211_assoc_timeout(struct net_d
 }
 EXPORT_SYMBOL(cfg80211_assoc_timeout);
 
+void cfg80211_abandon_assoc(struct net_device *dev, struct cfg80211_bss *bss)
+{
+	struct wireless_dev *wdev = dev->ieee80211_ptr;
+	struct wiphy *wiphy = wdev->wiphy;
+
+	cfg80211_sme_abandon_assoc(wdev);
+
+	cfg80211_unhold_bss(bss_from_pub(bss));
+	cfg80211_put_bss(wiphy, bss);
+}
+EXPORT_SYMBOL(cfg80211_abandon_assoc);
+
 void cfg80211_tx_mlme_mgmt(struct net_device *dev, const u8 *buf, size_t len)
 {
 	struct wireless_dev *wdev = dev->ieee80211_ptr;
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -39,6 +39,7 @@ struct cfg80211_conn {
 		CFG80211_CONN_ASSOCIATING,
 		CFG80211_CONN_ASSOC_FAILED,
 		CFG80211_CONN_DEAUTH,
+		CFG80211_CONN_ABANDON,
 		CFG80211_CONN_CONNECTED,
 	} state;
 	u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
@@ -206,6 +207,8 @@ static int cfg80211_conn_do_work(struct
 		cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
 				     NULL, 0,
 				     WLAN_REASON_DEAUTH_LEAVING, false);
+		/* fall through */
+	case CFG80211_CONN_ABANDON:
 		/* free directly, disconnected event already sent */
 		cfg80211_sme_free(wdev);
 		return 0;
@@ -423,6 +426,17 @@ void cfg80211_sme_assoc_timeout(struct w
 	schedule_work(&rdev->conn_work);
 }
 
+void cfg80211_sme_abandon_assoc(struct wireless_dev *wdev)
+{
+	struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
+
+	if (!wdev->conn)
+		return;
+
+	wdev->conn->state = CFG80211_CONN_ABANDON;
+	schedule_work(&rdev->conn_work);
+}
+
 static int cfg80211_sme_get_conn_ies(struct wireless_dev *wdev,
 				     const u8 *ies, size_t ies_len,
 				     const u8 **out_ies, size_t *out_ies_len)

[PATCH 4.9 009/116] ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success

[Greg Kroah-Hartman]

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

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

From: Matthias Schiffer <mschiffer@universe-factory.net>

commit 91851cc7a939039bd401adb6ca3da4402bec1d0c upstream.

Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the
moment, but should be fixed anyway.

Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.

Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
[kvalo@qca.qualcomm.com: mention that doesn't fix any known bug]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/ath/ath9k/hw.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2792,7 +2792,7 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah,
 		WARN_ON(1);
 	}
 
-	return val;
+	return !!val;
 }
 EXPORT_SYMBOL(ath9k_hw_gpio_get);
 

[PATCH 4.9 010/116] ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.

[Greg Kroah-Hartman]

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

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

From: Vittorio Gambaletta (VittGam) <linux-wireless@vittgam.net>

commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream.

The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.

I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.

This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
match first and will be used.

With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.

While I'm at it, let's fix 0x002A too by also moving its generic definition
below its specific ones.

Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.")
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
[kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/ath/ath9k/pci.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -26,7 +26,6 @@ static const struct pci_device_id ath_pc
 	{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI   */
 	{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
 	{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI   */
-	{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
 
 #ifdef CONFIG_ATH9K_PCOEM
 	/* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
@@ -37,7 +36,7 @@ static const struct pci_device_id ath_pc
 	  .driver_data = ATH9K_PCI_LED_ACT_HI },
 #endif
 
-	{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+	{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI   */
 
 #ifdef CONFIG_ATH9K_PCOEM
 	{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
@@ -85,7 +84,11 @@ static const struct pci_device_id ath_pc
 			 0x10CF, /* Fujitsu */
 			 0x1536),
 	  .driver_data = ATH9K_PCI_D3_L1_WAR },
+#endif
 
+	{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
+
+#ifdef CONFIG_ATH9K_PCOEM
 	/* AR9285 card for Asus */
 	{ PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
 			 0x002B,

[PATCH 4.9 011/116] ath9k: do not return early to fix rcu unlocking

[Greg Kroah-Hartman]

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

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

From: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>

commit d1f1c0e289e1bc46cd6873ba6dd6c627f459e7fa upstream.

Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:

 ===============================
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 -------------------------------
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){......}
 , at:
 [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
  ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
  ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
 Call Trace:
  <IRQ>
  [<ffffffff8132b1e5>] dump_stack+0x68/0x93
  [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110
  [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0
  [<ffffffff81058631>] irq_exit+0x61/0xd0
  [<ffffffff81018d25>] do_IRQ+0x65/0x110
  [<ffffffff81672189>] common_interrupt+0x89/0x89
  <EOI>
  [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200
  [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20
  [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40
  [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220
  [<ffffffff810336f8>] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
Acked-by: Felix Fietkau <nbd@nbd.name>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/ath/ath9k/xmit.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,7 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_soft
 		fifo_list = &txq->txq_fifo[txq->txq_tailidx];
 		if (list_empty(fifo_list)) {
 			ath_txq_unlock(sc, txq);
-			return;
+			break;
 		}
 
 		bf = list_first_entry(fifo_list, struct ath_buf, list);

[PATCH 4.9 012/116] Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"

[Greg Kroah-Hartman]

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

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

From: Adrian Hunter <adrian.hunter@intel.com>

commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream.

This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").

A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/sdhci.c |    4 ----
 1 file changed, 4 deletions(-)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2086,10 +2086,6 @@ static int sdhci_execute_tuning(struct m
 
 		if (!host->tuning_done) {
 			pr_info(DRIVER_NAME ": Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock\n");
-
-			sdhci_do_reset(host, SDHCI_RESET_CMD);
-			sdhci_do_reset(host, SDHCI_RESET_DATA);
-
 			ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
 			ctrl &= ~SDHCI_CTRL_TUNED_CLK;
 			ctrl &= ~SDHCI_CTRL_EXEC_TUNING;

[PATCH 4.9 013/116] mmc: sdhci: Fix recovery from tuning timeout

[Greg Kroah-Hartman]

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

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

From: Adrian Hunter <adrian.hunter@intel.com>

commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream.

Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.

Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.

Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Dan O'Donovan <dan@emutex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mmc/host/sdhci.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2091,7 +2091,27 @@ static int sdhci_execute_tuning(struct m
 			ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
 			sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
+			sdhci_do_reset(host, SDHCI_RESET_CMD);
+			sdhci_do_reset(host, SDHCI_RESET_DATA);
+
 			err = -EIO;
+
+			if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
+				goto out;
+
+			sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+			sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+			spin_unlock_irqrestore(&host->lock, flags);
+
+			memset(&cmd, 0, sizeof(cmd));
+			cmd.opcode = MMC_STOP_TRANSMISSION;
+			cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
+			cmd.busy_timeout = 50;
+			mmc_wait_for_cmd(mmc, &cmd, 0);
+
+			spin_lock_irqsave(&host->lock, flags);
+
 			goto out;
 		}
 

[PATCH 4.9 014/116] regulator: stw481x-vmmc: fix ages old enable error

[Greg Kroah-Hartman]

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

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

From: Linus Walleij <linus.walleij@linaro.org>

commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream.

The regulator has never been properly enabled, it has been
dormant all the time. It's strange that MMC was working
at all, but it likely worked by the signals going through
the levelshifter and reaching the card anyways.

Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/regulator/stw481x-vmmc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/regulator/stw481x-vmmc.c
+++ b/drivers/regulator/stw481x-vmmc.c
@@ -47,7 +47,8 @@ static struct regulator_desc vmmc_regula
 	.volt_table = stw481x_vmmc_voltages,
 	.enable_time = 200, /* FIXME: look this up */
 	.enable_reg = STW_CONF1,
-	.enable_mask = STW_CONF1_PDN_VMMC,
+	.enable_mask = STW_CONF1_PDN_VMMC | STW_CONF1_MMC_LS_STATUS,
+	.enable_val = STW_CONF1_PDN_VMMC,
 	.vsel_reg = STW_CONF1,
 	.vsel_mask = STW_CONF1_VMMC_MASK,
 };

[PATCH 4.9 016/116] timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit 9c1645727b8fa90d07256fdfcc45bf831242a3ab upstream.

The clocksource delta to nanoseconds conversion is using signed math, but
the delta is unsigned. This makes the conversion space smaller than
necessary and in case of a multiplication overflow the conversion can
become negative. The conversion is done with scaled math:

    s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift;

Shifting a signed integer right obvioulsy preserves the sign, which has
interesting consequences:

 - Time jumps backwards

 - __iter_div_u64_rem() which is used in one of the calling code pathes
   will take forever to piecewise calculate the seconds/nanoseconds part.

This has been reported by several people with different scenarios:

David observed that when stopping a VM with a debugger:

 "It was essentially the stopped by debugger case.  I forget exactly why,
  but the guest was being explicitly stopped from outside, it wasn't just
  scheduling lag.  I think it was something in the vicinity of 10 minutes
  stopped."

 When lifting the stop the machine went dead.

The stopped by debugger case is not really interesting, but nevertheless it
would be a good thing not to die completely.

But this was also observed on a live system by Liav:

 "When the OS is too overloaded, delta will get a high enough value for the
  msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so
  after the shift the nsec variable will gain a value similar to
  0xffffffffff000000."

Unfortunately this has been reintroduced recently with commit 6bd58f09e1d8
("time: Add cycles to nanoseconds translation"). It had been fixed a year
ago already in commit 35a4933a8959 ("time: Avoid signed overflow in
timekeeping_get_ns()").

Though it's not surprising that the issue has been reintroduced because the
function itself and the whole call chain uses s64 for the result and the
propagation of it. The change in this recent commit is subtle:

   s64 nsec;

-  nsec = (d * m + n) >> s:
+  nsec = d * m + n;
+  nsec >>= s;

d being type of cycle_t adds another level of obfuscation.

This wouldn't have happened if the previous change to unsigned computation
would have made the 'nsec' variable u64 right away and a follow up patch
had cleaned up the whole call chain.

There have been patches submitted which basically did a revert of the above
patch leaving everything else unchanged as signed. Back to square one. This
spawned a admittedly pointless discussion about potential users which rely
on the unsigned behaviour until someone pointed out that it had been fixed
before. The changelogs of said patches added further confusion as they made
finally false claims about the consequences for eventual users which expect
signed results.

Despite delta being cycle_t, aka. u64, it's very well possible to hand in
a signed negative value and the signed computation will happily return the
correct result. But nobody actually sat down and analyzed the code which
was added as user after the propably unintended signed conversion.

Though in sensitive code like this it's better to analyze it proper and
make sure that nothing relies on this than hunting the subtle wreckage half
a year later. After analyzing all call chains it stands that no caller can
hand in a negative value (which actually would work due to the s64 cast)
and rely on the signed math to do the right thing.

Change the conversion function to unsigned math. The conversion of all call
chains is done in a follow up patch.

This solves the starvation issue, which was caused by the negative result,
but it does not solve the underlying problem. It merily procrastinates
it. When the timekeeper update is deferred long enough that the unsigned
multiplication overflows, then time going backwards is observable again.

It does neither solve the issue of clocksources with a small counter width
which will wrap around possibly several times and cause random time stamps
to be generated. But those are usually not found on systems used for
virtualization, so this is likely a non issue.

I took the liberty to claim authorship for this simply because
analyzing all callsites and writing the changelog took substantially
more time than just making the simple s/s64/u64/ change and ignore the
rest.

Fixes: 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation")
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Reported-by: Liav Rehana <liavr@mellanox.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Parit Bhargava <prarit@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>
Cc: "Christopher S. Hall" <christopher.s.hall@intel.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/r/20161208204228.688545601@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/time/timekeeping.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -299,10 +299,10 @@ u32 (*arch_gettimeoffset)(void) = defaul
 static inline u32 arch_gettimeoffset(void) { return 0; }
 #endif
 
-static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
+static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
 					  cycle_t delta)
 {
-	s64 nsec;
+	u64 nsec;
 
 	nsec = delta * tkr->mult + tkr->xtime_nsec;
 	nsec >>= tkr->shift;

[PATCH 4.9 017/116] gpio: stmpe: fix interrupt handling bug

[Greg Kroah-Hartman]

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

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

From: Linus Walleij <linus.walleij@linaro.org>

commit 1516c6350aa2770b8a5e36d40c3ec5078f92ba70 upstream.

commit 43db289d00c6 ("gpio: stmpe: Rework registers access")
reworked the STMPE register access so as to use
[STMPE_IDX_*_LSB + i] to access the 8bit register for a
certain bank, assuming the CSB and MSB will follow after
the enumerator. For this to work the index needs to go from
(size-1) to 0 not 0 to (size-1).

However for the GPIO IRQ handler, the status registers we read
register MSB + 3 bytes ahead for the 24 bit GPIOs and index
registers from MSB upwards and run an index i over the
registers UNLESS we are STMPE1600.

This is not working when we get to clearing the interrupt
EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed
like all other registers [STMPE_IDX_*_LSB + i] but in this
loop we index from 0 to get the right bank index for the
calculations, and we need to just add i to the MSB.

Before this, interrupts on the STMPE2401 were broken, this
patch fixes it so it works again.

Cc: Patrice Chotard <patrice.chotard@st.com>
Fixes: 43db289d00c6 ("gpio: stmpe: Rework registers access")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpio/gpio-stmpe.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpio/gpio-stmpe.c
+++ b/drivers/gpio/gpio-stmpe.c
@@ -413,7 +413,7 @@ static irqreturn_t stmpe_gpio_irq(int ir
 		    stmpe->partnum != STMPE1801) {
 			stmpe_reg_write(stmpe, statmsbreg + i, status[i]);
 			stmpe_reg_write(stmpe,
-					stmpe->regs[STMPE_IDX_GPEDR_LSB + i],
+					stmpe->regs[STMPE_IDX_GPEDR_MSB] + i,
 					status[i]);
 		}
 	}

[PATCH 4.9 018/116] gpio: chardev: Return error for seek operations

[Greg Kroah-Hartman]

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

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

From: Lars-Peter Clausen <lars@metafoo.de>

commit f4e81c529767b9a33d1b27695c54dc84a14af30d upstream.

The GPIO chardev is used for management tasks (allocating line and event
handles) and does neither support read() nor write() operations. Hence it
does not make much sense to allow seek operations.

Currently the chardev uses noop_llseek() for its seek implementation. This
function does not move the pointer and simply returns the current position
(always 0 for the GPIO chardev). noop_llseek() is primarily meant for
devices that can not support seek, but where there might be a user that
depends on the seek() operation succeeding. For newly added devices that
can not support seek operations it is recommended to use no_llseek(), which
will return an error. For more information see commit 6038f373a3dc
("llseek: automatically add .llseek fop").

Unfortunately this was overlooked when the GPIO chardev ABI was introduced.
But it is highly unlikely that since then userspace applications have
appeared that rely on being able to perform non-failing seek operations on
a GPIO chardev file descriptor. So it should be safe to change from
noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev
open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags
from the file. Neither of these should be set on a file that does not
support seek operations.

Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpio/gpiolib.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -986,7 +986,8 @@ static int gpio_chrdev_open(struct inode
 		return -ENODEV;
 	get_device(&gdev->dev);
 	filp->private_data = gdev;
-	return 0;
+
+	return nonseekable_open(inode, filp);
 }
 
 /**
@@ -1011,7 +1012,7 @@ static const struct file_operations gpio
 	.release = gpio_chrdev_release,
 	.open = gpio_chrdev_open,
 	.owner = THIS_MODULE,
-	.llseek = noop_llseek,
+	.llseek = no_llseek,
 	.unlocked_ioctl = gpio_ioctl,
 #ifdef CONFIG_COMPAT
 	.compat_ioctl = gpio_ioctl_compat,

[PATCH 4.9 019/116] arm64: tegra: Add VDD_GPU regulator to Jetson TX1

[Greg Kroah-Hartman]

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

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

From: Alexandre Courbot <acourbot@nvidia.com>

commit 5e6b9a89afceadb1ee45472098f7d20af260335c upstream.

Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson
TX1 board. This addition allows the GPU to be used provided the
bootloader properly enabled the GPU node.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
[as pointed out by Thierry on IRC, nobody has reported a bug
 in the field, but using a new bootloader with a .dtb that
 has the incorrect data, it will crash on boot]
Fixes: 336f79c7b6d7 ("arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

--- a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi
@@ -21,6 +21,10 @@
 		reg = <0x0 0x80000000 0x1 0x0>;
 	};
 
+	gpu@57000000 {
+		vdd-supply = <&vdd_gpu>;
+	};
+
 	/* debug port */
 	serial@70006000 {
 		status = "okay";
@@ -291,4 +295,18 @@
 			clock-frequency = <32768>;
 		};
 	};
+
+	regulators {
+		vdd_gpu: regulator@100 {
+			compatible = "pwm-regulator";
+			reg = <100>;
+			pwms = <&pwm 1 4880>;
+			regulator-name = "VDD_GPU";
+			regulator-min-microvolt = <710000>;
+			regulator-max-microvolt = <1320000>;
+			enable-gpios = <&pmic 6 GPIO_ACTIVE_HIGH>;
+			regulator-ramp-delay = <80>;
+			regulator-enable-ramp-delay = <1000>;
+		};
+	};
 };

[PATCH 4.9 020/116] clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk

[Greg Kroah-Hartman]

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

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

From: Boris Brezillon <boris.brezillon@free-electrons.com>

commit 68af4fa8f39b542a6cde7ac19518d88e9b3099dc upstream.

bcm2835_pll_divider_off() is resetting the divider field in the A2W reg
to zero when disabling the clock.

Make sure we preserve this value by reading the previous a2w_reg value
first and ORing the result with A2W_PLL_CHANNEL_DISABLE.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/clk/bcm/clk-bcm2835.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -751,7 +751,9 @@ static void bcm2835_pll_divider_off(stru
 	cprman_write(cprman, data->cm_reg,
 		     (cprman_read(cprman, data->cm_reg) &
 		      ~data->load_mask) | data->hold_mask);
-	cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
+	cprman_write(cprman, data->a2w_reg,
+		     cprman_read(cprman, data->a2w_reg) |
+		     A2W_PLL_CHANNEL_DISABLE);
 	spin_unlock(&cprman->regs_lock);
 }
 

[PATCH 4.9 021/116] thermal: hwmon: Properly report critical temperature in sysfs

[Greg Kroah-Hartman]

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

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

From: Krzysztof Kozlowski <krzk@kernel.org>

commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream.

In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space.  It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.

For example:
	/sys/class/hwmon/hwmon0/temp1_crit:50000
	/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
	/sys/class/thermal/thermal_zone0/trip_point_0_type:active
	/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
	/sys/class/thermal/thermal_zone0/trip_point_3_type:critical

Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided.  However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().

Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/thermal/thermal_hwmon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -98,7 +98,7 @@ temp_crit_show(struct device *dev, struc
 	int temperature;
 	int ret;
 
-	ret = tz->ops->get_trip_temp(tz, 0, &temperature);
+	ret = tz->ops->get_crit_temp(tz, &temperature);
 	if (ret)
 		return ret;
 

[PATCH 4.9 022/116] docs: sphinx-extensions: make rstFlatTable work with docutils 0.13

[Greg Kroah-Hartman]

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

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

From: Dmitry Shachnev <mitya57@debian.org>

commit 217e2bfab22e740227df09f22165e834cddd8a3b upstream.

In docutils 0.13, the return type of get_column_widths method of the
Table directive has changed [1], which breaks our flat-table directive
and leads to a TypeError when trying to build the docs [2].

This patch adds support for the new return type, while keeping support
for older docutils versions too.

[1] https://sourceforge.net/p/docutils/patches/120/
[2] https://sourceforge.net/p/docutils/bugs/303/

Signed-off-by: Dmitry Shachnev <mitya57@debian.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 Documentation/sphinx/rstFlatTable.py |    5 +++++
 1 file changed, 5 insertions(+)

--- a/Documentation/sphinx/rstFlatTable.py
+++ b/Documentation/sphinx/rstFlatTable.py
@@ -157,6 +157,11 @@ class ListTableBuilder(object):
     def buildTableNode(self):
 
         colwidths    = self.directive.get_column_widths(self.max_cols)
+        if isinstance(colwidths, tuple):
+            # Since docutils 0.13, get_column_widths returns a (widths,
+            # colwidths) tuple, where widths is a string (i.e. 'auto').
+            # See https://sourceforge.net/p/docutils/patches/120/.
+            colwidths = colwidths[1]
         stub_columns = self.directive.options.get('stub-columns', 0)
         header_rows  = self.directive.options.get('header-rows', 0)
 

[PATCH 4.9 023/116] hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels()

[Greg Kroah-Hartman]

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

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

From: Vitaly Kuznetsov <vkuznets@redhat.com>

commit abd1026da4a7700a8db370947f75cd17b6ae6f76 upstream.

"kernel BUG at drivers/hv/channel_mgmt.c:350!" is observed when hv_vmbus
module is unloaded. BUG_ON() was introduced in commit 85d9aa705184
("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()") as
vmbus_free_channels() codepath was apparently forgotten.

Fixes: 85d9aa705184 ("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()")

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/hv/channel_mgmt.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -389,6 +389,7 @@ void vmbus_free_channels(void)
 {
 	struct vmbus_channel *channel, *tmp;
 
+	mutex_lock(&vmbus_connection.channel_mutex);
 	list_for_each_entry_safe(channel, tmp, &vmbus_connection.chn_list,
 		listentry) {
 		/* hv_process_channel_removal() needs this */
@@ -396,6 +397,7 @@ void vmbus_free_channels(void)
 
 		vmbus_device_unregister(channel->device_obj);
 	}
+	mutex_unlock(&vmbus_connection.channel_mutex);
 }
 
 /*

[PATCH 4.9 024/116] staging/lustre/osc: Revert erroneous list_for_each_entry_safe use

[Greg Kroah-Hartman]

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

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

From: Oleg Drokin <green@linuxhacker.ru>

commit cd15dd6ef4ea11df87f717b8b1b83aaa738ec8af upstream.

I have been having a lot of unexplainable crashes in osc_lru_shrink
lately that I could not see a good explanation for and then I found
this patch that slip under the radar somehow that incorrectly
converted while loop for lru list iteration into
list_for_each_entry_safe totally ignoring that in the body of
the loop we drop spinlocks guarding this list and move list entries
around.
Not sure why it was not showing up right away, perhaps some of the
more recent LRU changes committed caused some extra pressure on this
code that finally highlighted the breakage.

Reverts: 8adddc36b1fc ("staging: lustre: osc: Use list_for_each_entry_safe")
CC: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/lustre/lustre/osc/osc_page.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/staging/lustre/lustre/osc/osc_page.c
+++ b/drivers/staging/lustre/lustre/osc/osc_page.c
@@ -542,7 +542,6 @@ long osc_lru_shrink(const struct lu_env
 	struct cl_object *clobj = NULL;
 	struct cl_page **pvec;
 	struct osc_page *opg;
-	struct osc_page *temp;
 	int maxscan = 0;
 	long count = 0;
 	int index = 0;
@@ -569,13 +568,15 @@ long osc_lru_shrink(const struct lu_env
 
 	spin_lock(&cli->cl_lru_list_lock);
 	maxscan = min(target << 1, atomic_long_read(&cli->cl_lru_in_list));
-	list_for_each_entry_safe(opg, temp, &cli->cl_lru_list, ops_lru) {
+	while (!list_empty(&cli->cl_lru_list)) {
 		struct cl_page *page;
 		bool will_free = false;
 
 		if (--maxscan < 0)
 			break;
 
+		opg = list_entry(cli->cl_lru_list.next, struct osc_page,
+				 ops_lru);
 		page = opg->ops_cl.cpl_page;
 		if (lru_page_busy(cli, page)) {
 			list_move_tail(&opg->ops_lru, &cli->cl_lru_list);

[PATCH 4.9 025/116] staging: lustre: ldlm: pl_recalc time handling is wrong

[Greg Kroah-Hartman]

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

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

From: Arnd Bergmann <arnd@arndb.de>

commit b8cb86fd95bb461c3496e1f4b4083b198c963a9c upstream.

James Simmons reports:
> The ldlm_pool field pl_recalc_time is set to the current
> monotonic clock value but the interval period is calculated
> with the wall clock. This means the interval period will
> always be far larger than the pl_recalc_period, which is
> just a small interval time period. The correct thing to
> do is to use monotomic clock current value instead of the
> wall clocks value when calculating recalc_interval_sec.

This broke when I converted the 32-bit get_seconds() into
ktime_get_{real_,}seconds() inconsistently. Either
one of those two would have worked, but mixing them
does not.

Staying with the original intention of the patch, this
changes the ktime_get_seconds() calls into ktime_get_real_seconds(),
using real time instead of mononic time.

Fixes: 8f83409cf238 ("staging/lustre: use 64-bit time for pl_recalc")
Reported-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/lustre/lustre/ldlm/ldlm_pool.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
@@ -356,10 +356,10 @@ static int ldlm_pool_recalc(struct ldlm_
 	u32 recalc_interval_sec;
 	int count;
 
-	recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time;
+	recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time;
 	if (recalc_interval_sec > 0) {
 		spin_lock(&pl->pl_lock);
-		recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time;
+		recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time;
 
 		if (recalc_interval_sec > 0) {
 			/*
@@ -382,7 +382,7 @@ static int ldlm_pool_recalc(struct ldlm_
 				    count);
 	}
 
-	recalc_interval_sec = pl->pl_recalc_time - ktime_get_seconds() +
+	recalc_interval_sec = pl->pl_recalc_time - ktime_get_real_seconds() +
 			      pl->pl_recalc_period;
 	if (recalc_interval_sec <= 0) {
 		/* DEBUG: should be re-removed after LU-4536 is fixed */
@@ -657,7 +657,7 @@ int ldlm_pool_init(struct ldlm_pool *pl,
 
 	spin_lock_init(&pl->pl_lock);
 	atomic_set(&pl->pl_granted, 0);
-	pl->pl_recalc_time = ktime_get_seconds();
+	pl->pl_recalc_time = ktime_get_real_seconds();
 	atomic_set(&pl->pl_lock_volume_factor, 1);
 
 	atomic_set(&pl->pl_grant_rate, 0);

[PATCH 4.9 026/116] staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask

[Greg Kroah-Hartman]

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

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

From: Ian Abbott <abbotti@mev.co.uk>

commit 655c4d442d1213b617926cc6d54e2a9a793fb46b upstream.

For NI M Series cards, the Comedi `insn_read` handler for the AI
subdevice is broken due to ANDing the value read from the AI FIFO data
register with an incorrect mask.  The incorrect mask clears all but the
most significant bit of the sample data.  It should preserve all the
sample data bits.  Correct it.

Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/comedi/drivers/ni_mio_common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1832,7 +1832,7 @@ static int ni_ai_insn_read(struct comedi
 			   unsigned int *data)
 {
 	struct ni_private *devpriv = dev->private;
-	unsigned int mask = (s->maxdata + 1) >> 1;
+	unsigned int mask = s->maxdata;
 	int i, n;
 	unsigned int signbits;
 	unsigned int d;

[PATCH 4.9 027/116] staging: comedi: ni_mio_common: fix E series ni_ai_insn_read() data

[Greg Kroah-Hartman]

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

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

From: Ian Abbott <abbotti@mev.co.uk>

commit 857a661020a2de3a0304edf33ad656abee100891 upstream.

Commit 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for
32-bit read") changed the type of local variable `d` from `unsigned
short` to `unsigned int` to fix a bug introduced in
commit 9c340ac934db ("staging: comedi: ni_stc.h: add read/write
callbacks to struct ni_private") when reading AI data for NI PCI-6110
and PCI-6111 cards.  Unfortunately, other parts of the function rely on
the variable being `unsigned short` when an offset value in local
variable `signbits` is added to `d` before writing the value to the
`data` array:

			d += signbits;
		  	data[n] = d;

The `signbits` variable will be non-zero in bipolar mode, and is used to
convert the hardware's 2's complement, 16-bit numbers to Comedi's
straight binary sample format (with 0 representing the most negative
voltage).  This breaks because `d` is now 32 bits wide instead of 16
bits wide, so after the addition of `signbits`, `data[n]` ends up being
set to values above 65536 for negative voltages.  This affects all
supported "E series" cards except PCI-6143 (and PXI-6143). Fix it by
ANDing the value written to the `data[n]` with the mask 0xffff.

Fixes: 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for 32-bit read")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/comedi/drivers/ni_mio_common.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1875,7 +1875,7 @@ static int ni_ai_insn_read(struct comedi
 				return -ETIME;
 			}
 			d += signbits;
-			data[n] = d;
+			data[n] = d & 0xffff;
 		}
 	} else if (devpriv->is_6143) {
 		for (n = 0; n < insn->n; n++) {
@@ -1924,9 +1924,8 @@ static int ni_ai_insn_read(struct comedi
 				data[n] = dl;
 			} else {
 				d = ni_readw(dev, NI_E_AI_FIFO_DATA_REG);
-				/* subtle: needs to be short addition */
 				d += signbits;
-				data[n] = d;
+				data[n] = d & 0xffff;
 			}
 		}
 	}

[PATCH 4.9 028/116] ACPI / video: Add force_native quirk for Dell XPS 17 L702X

[Greg Kroah-Hartman]

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

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

From: Hans de Goede <hdegoede@redhat.com>

commit 350fa038c31b056fc509624efb66348ac2c1e3d0 upstream.

The Dell XPS 17 L702X has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.

Note that there also is an issue with the brightnesskeys on this laptop,
they do not generate key-press events in anyway. That is not solved by
this patch.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123661
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/acpi/video_detect.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -296,6 +296,15 @@ static const struct dmi_system_id video_
 		DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"),
 		},
 	},
+	{
+	 /* https://bugzilla.redhat.com/show_bug.cgi?id=1123661 */
+	 .callback = video_detect_force_native,
+	 .ident = "Dell XPS 17 L702X",
+	 .matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L702X"),
+		},
+	},
 	{ },
 };
 

[PATCH 4.9 029/116] ACPI / video: Add force_native quirk for HP Pavilion dv6

[Greg Kroah-Hartman]

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

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

From: Hans de Goede <hdegoede@redhat.com>

commit 6276e53fa8c06a3a5cf7b95b77b079966de9ad66 upstream.

The HP Pavilion dv6 has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.

Note that there are quite a few HP Pavilion dv6 variants, some
woth ATI and some with NVIDIA hybrid gfx, both seem to need this
quirk to have working backlight control. There are also some versions
with only Intel integrated gfx, these may not need this quirk, but it
should not hurt there.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1204476
Link: https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1416940
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/acpi/video_detect.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -305,6 +305,17 @@ static const struct dmi_system_id video_
 		DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L702X"),
 		},
 	},
+	{
+	/* https://bugzilla.redhat.com/show_bug.cgi?id=1204476 */
+	/* https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1416940 */
+	.callback = video_detect_force_native,
+	.ident = "HP Pavilion dv6",
+	.matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv6 Notebook PC"),
+		},
+	},
+
 	{ },
 };
 

[PATCH 4.9 030/116] drm/amdgpu/si: load the proper firmware on 0x87 oland boards

[Greg Kroah-Hartman]

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

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

From: Alex Deucher <alexander.deucher@amd.com>

commit 5a23f2720589ec4757bc62183902d2518f02026e upstream.

New variant.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/amd/amdgpu/si_dpm.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -7713,6 +7713,7 @@ static int si_dpm_init_microcode(struct
 		    (adev->pdev->revision == 0x80) ||
 		    (adev->pdev->revision == 0x81) ||
 		    (adev->pdev->revision == 0x83) ||
+		    (adev->pdev->revision == 0x87) ||
 		    (adev->pdev->device == 0x6604) ||
 		    (adev->pdev->device == 0x6605))
 			chip_name = "oland_k";

[PATCH 4.9 031/116] drm/amdgpu: add additional pci revision to dpm workaround

[Greg Kroah-Hartman]

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

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

From: Alex Deucher <alexander.deucher@amd.com>

commit ce66cb1e9cbf91fcb216de64a0fe65aa17f97bc1 upstream.

New variant.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/amd/amdgpu/si_dpm.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3504,6 +3504,7 @@ static void si_apply_state_adjust_rules(
 		    (adev->pdev->revision == 0x80) ||
 		    (adev->pdev->revision == 0x81) ||
 		    (adev->pdev->revision == 0x83) ||
+		    (adev->pdev->revision == 0x87) ||
 		    (adev->pdev->device == 0x6604) ||
 		    (adev->pdev->device == 0x6605)) {
 			max_sclk = 75000;

[PATCH 4.9 034/116] drm/amd/amdgpu: enable GUI idle INT after enabling CGCG

[Greg Kroah-Hartman]

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

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

From: Arindam Nath <arindam.nath@amd.com>

commit dd31ae9ac933636c3712b7dd0f6152c1d71f81fe upstream.

GUI idle interrupts should be enabled only after we
have enabled coarse grain clock gating (CGCG). This
prevents GFX engine generating idle interrupt even
though CGCG is not completely enabled.

Most of the time this goes un-noticed, but on some
Stoney ASICs this results in GFX engine hang after
system resumes from suspend. The issue is not
particular to Stoney though and could have occured
on any ASIC. The patch fixes this issue.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Sunil Uttarwar <Sunil.Uttarwar1@amd.com>
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -5891,29 +5891,24 @@ static void gfx_v8_0_update_coarse_grain
 	adev->gfx.rlc.funcs->enter_safe_mode(adev);
 
 	if (enable && (adev->cg_flags & AMD_CG_SUPPORT_GFX_CGCG)) {
-		/* 1 enable cntx_empty_int_enable/cntx_busy_int_enable/
-		 * Cmp_busy/GFX_Idle interrupts
-		 */
-		gfx_v8_0_enable_gui_idle_interrupt(adev, true);
-
 		temp1 = data1 =	RREG32(mmRLC_CGTT_MGCG_OVERRIDE);
 		data1 &= ~RLC_CGTT_MGCG_OVERRIDE__CGCG_MASK;
 		if (temp1 != data1)
 			WREG32(mmRLC_CGTT_MGCG_OVERRIDE, data1);
 
-		/* 2 wait for RLC_SERDES_CU_MASTER & RLC_SERDES_NONCU_MASTER idle */
+		/* : wait for RLC_SERDES_CU_MASTER & RLC_SERDES_NONCU_MASTER idle */
 		gfx_v8_0_wait_for_rlc_serdes(adev);
 
-		/* 3 - clear cgcg override */
+		/* 2 - clear cgcg override */
 		gfx_v8_0_send_serdes_cmd(adev, BPM_REG_CGCG_OVERRIDE, CLE_BPM_SERDES_CMD);
 
 		/* wait for RLC_SERDES_CU_MASTER & RLC_SERDES_NONCU_MASTER idle */
 		gfx_v8_0_wait_for_rlc_serdes(adev);
 
-		/* 4 - write cmd to set CGLS */
+		/* 3 - write cmd to set CGLS */
 		gfx_v8_0_send_serdes_cmd(adev, BPM_REG_CGLS_EN, SET_BPM_SERDES_CMD);
 
-		/* 5 - enable cgcg */
+		/* 4 - enable cgcg */
 		data |= RLC_CGCG_CGLS_CTRL__CGCG_EN_MASK;
 
 		if (adev->cg_flags & AMD_CG_SUPPORT_GFX_CGLS) {
@@ -5931,6 +5926,11 @@ static void gfx_v8_0_update_coarse_grain
 
 		if (temp != data)
 			WREG32(mmRLC_CGCG_CGLS_CTRL, data);
+
+		/* 5 enable cntx_empty_int_enable/cntx_busy_int_enable/
+		 * Cmp_busy/GFX_Idle interrupts
+		 */
+		gfx_v8_0_enable_gui_idle_interrupt(adev, true);
 	} else {
 		/* disable cntx_empty_int_enable & GFX Idle interrupt */
 		gfx_v8_0_enable_gui_idle_interrupt(adev, false);

[PATCH 4.9 035/116] drm/nouveau/gr: fallback to legacy paths during firmware lookup

[Greg Kroah-Hartman]

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

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

From: Alexandre Courbot <acourbot@nvidia.com>

commit e137040e0d0376b404fc5155eba44ea07126e3bd upstream.

Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path
if they cannot be found in the new, "official" path. User setups were
broken by the switch, which is bad.

There are only 4 firmware files we may want to look up that way, so
hardcode them into the lookup function. All new firmware files should
use the standard "nvidia/<chip>/gr/" path.

Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external firmwares")
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c |   50 +++++++++++++++++++++++--
 1 file changed, 46 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1756,6 +1756,50 @@ gf100_gr_ = {
 };
 
 int
+gf100_gr_ctor_fw_legacy(struct gf100_gr *gr, const char *fwname,
+			struct gf100_gr_fuc *fuc, int ret)
+{
+	struct nvkm_subdev *subdev = &gr->base.engine.subdev;
+	struct nvkm_device *device = subdev->device;
+	const struct firmware *fw;
+	char f[32];
+
+	/* see if this firmware has a legacy path */
+	if (!strcmp(fwname, "fecs_inst"))
+		fwname = "fuc409c";
+	else if (!strcmp(fwname, "fecs_data"))
+		fwname = "fuc409d";
+	else if (!strcmp(fwname, "gpccs_inst"))
+		fwname = "fuc41ac";
+	else if (!strcmp(fwname, "gpccs_data"))
+		fwname = "fuc41ad";
+	else {
+		/* nope, let's just return the error we got */
+		nvkm_error(subdev, "failed to load %s\n", fwname);
+		return ret;
+	}
+
+	/* yes, try to load from the legacy path */
+	nvkm_debug(subdev, "%s: falling back to legacy path\n", fwname);
+
+	snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname);
+	ret = request_firmware(&fw, f, device->dev);
+	if (ret) {
+		snprintf(f, sizeof(f), "nouveau/%s", fwname);
+		ret = request_firmware(&fw, f, device->dev);
+		if (ret) {
+			nvkm_error(subdev, "failed to load %s\n", fwname);
+			return ret;
+		}
+	}
+
+	fuc->size = fw->size;
+	fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
+	release_firmware(fw);
+	return (fuc->data != NULL) ? 0 : -ENOMEM;
+}
+
+int
 gf100_gr_ctor_fw(struct gf100_gr *gr, const char *fwname,
 		 struct gf100_gr_fuc *fuc)
 {
@@ -1765,10 +1809,8 @@ gf100_gr_ctor_fw(struct gf100_gr *gr, co
 	int ret;
 
 	ret = nvkm_firmware_get(device, fwname, &fw);
-	if (ret) {
-		nvkm_error(subdev, "failed to load %s\n", fwname);
-		return ret;
-	}
+	if (ret)
+		return gf100_gr_ctor_fw_legacy(gr, fwname, fuc, ret);
 
 	fuc->size = fw->size;
 	fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);

[PATCH 4.9 036/116] drm/nouveau/kms: lvds panel strap moved again on maxwell

[Greg Kroah-Hartman]

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

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

From: Ben Skeggs <bskeggs@redhat.com>

commit 768e847759d551c96e129e194588dbfb11a1d576 upstream.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nouveau_bios.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -333,6 +333,9 @@ get_fp_strap(struct drm_device *dev, str
 	if (bios->major_version < 5 && bios->data[0x48] & 0x4)
 		return NVReadVgaCrtc5758(dev, 0, 0xf) & 0xf;
 
+	if (drm->device.info.family >= NV_DEVICE_INFO_V0_MAXWELL)
+		return nvif_rd32(device, 0x001800) & 0x0000000f;
+	else
 	if (drm->device.info.family >= NV_DEVICE_INFO_V0_TESLA)
 		return (nvif_rd32(device, NV_PEXTDEV_BOOT_0) >> 24) & 0xf;
 	else

[PATCH 4.9 037/116] drm/nouveau/bios: require checksum to match for fast acpi shadow method

[Greg Kroah-Hartman]

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

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

From: Ben Skeggs <bskeggs@redhat.com>

commit 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda upstream.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h       |    1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c     |    7 +++++--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c |    1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
@@ -12,6 +12,7 @@ struct nvbios_source {
 	bool rw;
 	bool ignore_checksum;
 	bool no_pcir;
+	bool require_checksum;
 };
 
 int nvbios_extend(struct nvkm_bios *, u32 length);
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -86,9 +86,12 @@ shadow_image(struct nvkm_bios *bios, int
 		    nvbios_checksum(&bios->data[image.base], image.size)) {
 			nvkm_debug(subdev, "%08x: checksum failed\n",
 				   image.base);
-			if (mthd->func->rw)
+			if (!mthd->func->require_checksum) {
+				if (mthd->func->rw)
+					score += 1;
 				score += 1;
-			score += 1;
+			} else
+				return 0;
 		} else {
 			score += 3;
 		}
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowacpi.c
@@ -99,6 +99,7 @@ nvbios_acpi_fast = {
 	.init = acpi_init,
 	.read = acpi_read_fast,
 	.rw = false,
+	.require_checksum = true,
 };
 
 const struct nvbios_source

[PATCH 4.9 038/116] drm/nouveau/ltc: protect clearing of comptags with mutex

[Greg Kroah-Hartman]

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

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

From: Ben Skeggs <bskeggs@redhat.com>

commit f4e65efc88b64c1dbca275d42a188edccedb56c6 upstream.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/base.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/base.c
@@ -47,8 +47,10 @@ nvkm_ltc_tags_clear(struct nvkm_ltc *ltc
 
 	BUG_ON((first > limit) || (limit >= ltc->num_tags));
 
+	mutex_lock(&ltc->subdev.mutex);
 	ltc->func->cbc_clear(ltc, first, limit);
 	ltc->func->cbc_wait(ltc);
+	mutex_unlock(&ltc->subdev.mutex);
 }
 
 int

[PATCH 4.9 039/116] drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas

[Greg Kroah-Hartman]

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

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

From: Ben Skeggs <bskeggs@redhat.com>

commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream.

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nouveau_bo.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1209,6 +1209,7 @@ nouveau_bo_move_ntfy(struct ttm_buffer_o
 			       nvbo->page_shift != vma->vm->mmu->lpg_shift)) {
 			nvkm_vm_map(vma, new_mem->mm_node);
 		} else {
+			WARN_ON(ttm_bo_wait(bo, false, false));
 			nvkm_vm_unmap(vma);
 		}
 	}

[PATCH 4.9 040/116] drm/nouveau/i2c/gk110b,gm10x: use the correct implementation

[Greg Kroah-Hartman]

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

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

From: Ben Skeggs <bskeggs@redhat.com>

commit 5b3800a6b763874e4a23702fb9628d3bd3315ce9 upstream.

DPAUX registers moved on Kepler, these chipsets were still using the
Fermi implementation for some reason.

This fixes detection of hotplug/sink IRQs on DP connectors.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1851,7 +1851,7 @@ nvf1_chipset = {
 	.fb = gk104_fb_new,
 	.fuse = gf100_fuse_new,
 	.gpio = gk104_gpio_new,
-	.i2c = gf119_i2c_new,
+	.i2c = gk104_i2c_new,
 	.ibus = gk104_ibus_new,
 	.iccsense = gf100_iccsense_new,
 	.imem = nv50_instmem_new,
@@ -1965,7 +1965,7 @@ nv117_chipset = {
 	.fb = gm107_fb_new,
 	.fuse = gm107_fuse_new,
 	.gpio = gk104_gpio_new,
-	.i2c = gf119_i2c_new,
+	.i2c = gk104_i2c_new,
 	.ibus = gk104_ibus_new,
 	.iccsense = gf100_iccsense_new,
 	.imem = nv50_instmem_new,
@@ -1999,7 +1999,7 @@ nv118_chipset = {
 	.fb = gm107_fb_new,
 	.fuse = gm107_fuse_new,
 	.gpio = gk104_gpio_new,
-	.i2c = gf119_i2c_new,
+	.i2c = gk104_i2c_new,
 	.ibus = gk104_ibus_new,
 	.iccsense = gf100_iccsense_new,
 	.imem = nv50_instmem_new,

[PATCH 4.9 041/116] drm/nouveau/fifo/gf100-: protect channel preempt with subdev mutex

[Greg Kroah-Hartman]

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

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

From: Ben Skeggs <bskeggs@redhat.com>

commit b27add13f500469127afdf011dbcc9c649e16e54 upstream.

This avoids an issue that occurs when we're attempting to preempt multiple
channels simultaneously.  HW seems to ignore preempt requests while it's
still processing a previous one, which, well, makes sense.

Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel
piglit runs on (at least) GM107.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c |    9 ++++++---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c |    8 +++++---
 2 files changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c
@@ -60,6 +60,7 @@ gf100_fifo_gpfifo_engine_fini(struct nvk
 	struct nvkm_gpuobj *inst = chan->base.inst;
 	int ret = 0;
 
+	mutex_lock(&subdev->mutex);
 	nvkm_wr32(device, 0x002634, chan->base.chid);
 	if (nvkm_msec(device, 2000,
 		if (nvkm_rd32(device, 0x002634) == chan->base.chid)
@@ -67,10 +68,12 @@ gf100_fifo_gpfifo_engine_fini(struct nvk
 	) < 0) {
 		nvkm_error(subdev, "channel %d [%s] kick timeout\n",
 			   chan->base.chid, chan->base.object.client->name);
-		ret = -EBUSY;
-		if (suspend)
-			return ret;
+		ret = -ETIMEDOUT;
 	}
+	mutex_unlock(&subdev->mutex);
+
+	if (ret && suspend)
+		return ret;
 
 	if (offset) {
 		nvkm_kmap(inst);
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
@@ -40,7 +40,9 @@ gk104_fifo_gpfifo_kick(struct gk104_fifo
 	struct nvkm_subdev *subdev = &fifo->base.engine.subdev;
 	struct nvkm_device *device = subdev->device;
 	struct nvkm_client *client = chan->base.object.client;
+	int ret = 0;
 
+	mutex_lock(&subdev->mutex);
 	nvkm_wr32(device, 0x002634, chan->base.chid);
 	if (nvkm_msec(device, 2000,
 		if (!(nvkm_rd32(device, 0x002634) & 0x00100000))
@@ -48,10 +50,10 @@ gk104_fifo_gpfifo_kick(struct gk104_fifo
 	) < 0) {
 		nvkm_error(subdev, "channel %d [%s] kick timeout\n",
 			   chan->base.chid, client->name);
-		return -EBUSY;
+		ret = -ETIMEDOUT;
 	}
-
-	return 0;
+	mutex_unlock(&subdev->mutex);
+	return ret;
 }
 
 static u32

[PATCH 4.9 044/116] drm/radeon: add additional pci revision to dpm workaround

[Greg Kroah-Hartman]

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

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

From: Alex Deucher <alexander.deucher@amd.com>

commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream.

New variant.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/radeon/si_dpm.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3026,6 +3026,7 @@ static void si_apply_state_adjust_rules(
 		    (rdev->pdev->revision == 0x80) ||
 		    (rdev->pdev->revision == 0x81) ||
 		    (rdev->pdev->revision == 0x83) ||
+		    (rdev->pdev->revision == 0x87) ||
 		    (rdev->pdev->device == 0x6604) ||
 		    (rdev->pdev->device == 0x6605)) {
 			max_sclk = 75000;

[PATCH 4.9 045/116] drm/radeon/si: load the proper firmware on 0x87 oland boards

[Greg Kroah-Hartman]

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

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

From: Alex Deucher <alexander.deucher@amd.com>

commit abb2e3c1ce64c8bba678973800c34ea1dc97c42c upstream.

New variant.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/radeon/si.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -1714,6 +1714,7 @@ static int si_init_microcode(struct rade
 		    (rdev->pdev->revision == 0x80) ||
 		    (rdev->pdev->revision == 0x81) ||
 		    (rdev->pdev->revision == 0x83) ||
+		    (rdev->pdev->revision == 0x87) ||
 		    (rdev->pdev->device == 0x6604) ||
 		    (rdev->pdev->device == 0x6605))
 			new_smc = true;

[PATCH 4.9 046/116] drm/gma500: Add compat ioctl

[Greg Kroah-Hartman]

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

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

From: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>

commit 0a97c81a9717431e6c57ea845b59c3c345edce67 upstream.

Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
It turns out that N2600 and N2800 comes with 64-bit enabled. We
previously assumed there where no such systems out there.

Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/gma500/psb_drv.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -473,6 +473,9 @@ static const struct file_operations psb_
 	.open = drm_open,
 	.release = drm_release,
 	.unlocked_ioctl = psb_unlocked_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl = drm_compat_ioctl,
+#endif
 	.mmap = drm_gem_mmap,
 	.poll = drm_poll,
 	.read = drm_read,

[PATCH 4.9 047/116] drm/amd/powerplay: bypass fan table setup if no fan connected

[Greg Kroah-Hartman]

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

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

From: Hawking Zhang <Hawking.Zhang@amd.com>

commit 10e2ca346bf74561ff1b7fff6287716ab976cd8c upstream.

If vBIOS noFan bit is set, the fan table parameters in thermal controller
will not get initialized. The driver should avoid to use these uninitialized
parameter to do calculation. Otherwise, it may trigger divide 0 error.

Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c      |    6 ++++++
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   |    6 ++++++
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |    6 ++++++
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c     |    6 ++++++
 4 files changed, 24 insertions(+)

--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -1958,6 +1958,12 @@ int fiji_thermal_setup_fan_table(struct
 	int res;
 	uint64_t tmp64;
 
+	if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+			PHM_PlatformCaps_MicrocodeFanControl);
+		return 0;
+	}
+
 	if (smu_data->smu7_data.fan_table_start == 0) {
 		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
 				PHM_PlatformCaps_MicrocodeFanControl);
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -2006,6 +2006,12 @@ int iceland_thermal_setup_fan_table(stru
 	if (!phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, PHM_PlatformCaps_MicrocodeFanControl))
 		return 0;
 
+	if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+			PHM_PlatformCaps_MicrocodeFanControl);
+		return 0;
+	}
+
 	if (0 == smu7_data->fan_table_start) {
 		phm_cap_unset(hwmgr->platform_descriptor.platformCaps, PHM_PlatformCaps_MicrocodeFanControl);
 		return 0;
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
@@ -1885,6 +1885,12 @@ int polaris10_thermal_setup_fan_table(st
 	int res;
 	uint64_t tmp64;
 
+	if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+			PHM_PlatformCaps_MicrocodeFanControl);
+		return 0;
+	}
+
 	if (smu_data->smu7_data.fan_table_start == 0) {
 		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
 				PHM_PlatformCaps_MicrocodeFanControl);
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
@@ -2496,6 +2496,12 @@ int tonga_thermal_setup_fan_table(struct
 					PHM_PlatformCaps_MicrocodeFanControl))
 		return 0;
 
+	if (hwmgr->thermal_controller.fanInfo.bNoFan) {
+		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
+			PHM_PlatformCaps_MicrocodeFanControl);
+		return 0;
+	}
+
 	if (0 == smu_data->smu7_data.fan_table_start) {
 		phm_cap_unset(hwmgr->platform_descriptor.platformCaps,
 					PHM_PlatformCaps_MicrocodeFanControl);

[PATCH 4.9 048/116] drm/amdgpu: fix enable_cp_power_gating in gfx_v8.0.

[Greg Kroah-Hartman]

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

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

From: Rex Zhu <Rex.Zhu@amd.com>

commit eb584241226958d45aa1f07f4f6a6ea9da98b29e upstream.

the CP_PG_DISABLE bit was reversed.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3994,7 +3994,7 @@ static void cz_enable_sck_slow_down_on_p
 
 static void cz_enable_cp_power_gating(struct amdgpu_device *adev, bool enable)
 {
-	WREG32_FIELD(RLC_PG_CNTL, CP_PG_DISABLE, enable ? 1 : 0);
+	WREG32_FIELD(RLC_PG_CNTL, CP_PG_DISABLE, enable ? 0 : 1);
 }
 
 static void gfx_v8_0_init_pg(struct amdgpu_device *adev)

[PATCH 4.9 049/116] drm/amdgpu: fix init save/restore list in gfx_v8.0

[Greg Kroah-Hartman]

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

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

From: Rex Zhu <Rex.Zhu@amd.com>

commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream.

set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -3947,8 +3947,12 @@ static int gfx_v8_0_init_save_restore_li
 	temp = mmRLC_SRM_INDEX_CNTL_ADDR_0;
 	data = mmRLC_SRM_INDEX_CNTL_DATA_0;
 	for (i = 0; i < sizeof(unique_indices) / sizeof(int); i++) {
-		amdgpu_mm_wreg(adev, temp + i, unique_indices[i] & 0x3FFFF, false);
-		amdgpu_mm_wreg(adev, data + i, unique_indices[i] >> 20, false);
+		if (unique_indices[i] != 0) {
+			amdgpu_mm_wreg(adev, temp + i,
+					unique_indices[i] & 0x3FFFF, false);
+			amdgpu_mm_wreg(adev, data + i,
+					unique_indices[i] >> 20, false);
+		}
 	}
 	kfree(register_list_format);
 

[PATCH 4.9 050/116] drivers/gpu/drm/ast: Fix infinite loop if read fails

[Greg Kroah-Hartman]

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

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

From: Russell Currey <ruscur@russell.cc>

commit 298360af3dab45659810fdc51aba0c9f4097e4f6 upstream.

ast_get_dram_info() configures a window in order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.

Fix this by erroring out if an error is detected.  On powerpc systems with
EEH, this leads to the device being fenced and the system continuing to
operate.

Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.cc
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/ast/ast_main.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -223,7 +223,8 @@ static int ast_get_dram_info(struct drm_
 	ast_write32(ast, 0x10000, 0xfc600309);
 
 	do {
-		;
+		if (pci_channel_offline(dev->pdev))
+			return -EIO;
 	} while (ast_read32(ast, 0x10000) != 0x01);
 	data = ast_read32(ast, 0x10004);
 
@@ -428,7 +429,9 @@ int ast_driver_load(struct drm_device *d
 	ast_detect_chip(dev, &need_post);
 
 	if (ast->chip != AST1180) {
-		ast_get_dram_info(dev);
+		ret = ast_get_dram_info(dev);
+		if (ret)
+			goto out_free;
 		ast->vram_size = ast_get_vram_info(dev);
 		DRM_INFO("dram %d %d %d %08x\n", ast->mclk, ast->dram_type, ast->dram_bus_width, ast->vram_size);
 	}

[PATCH 4.9 051/116] mei: request async autosuspend at the end of enumeration

[Greg Kroah-Hartman]

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

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

From: Alexander Usyskin <alexander.usyskin@intel.com>

commit d5f8e166c25750adc147b0adf64a62a91653438a upstream.

pm_runtime_autosuspend can take synchronous or asynchronous
paths, Because we are calling pm_runtime_mark_last_busy just before
this most of the cases it takes the asynchronous way. However,
when the FW or driver resets during already running runtime suspend,
the call will result in calling to the driver's rpm callback and results
in a deadlock on device_lock.
The simplest fix is to replace pm_runtime_autosuspend with
asynchronous pm_request_autosuspend.

Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/mei/client.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -686,7 +686,7 @@ void mei_host_client_init(struct mei_dev
 
 	pm_runtime_mark_last_busy(dev->dev);
 	dev_dbg(dev->dev, "rpm: autosuspend\n");
-	pm_runtime_autosuspend(dev->dev);
+	pm_request_autosuspend(dev->dev);
 }
 
 /**

[PATCH 4.9 052/116] mei: me: add lewisburg device ids

[Greg Kroah-Hartman]

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

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

From: Tomas Winkler <tomas.winkler@intel.com>

commit 9ff2007bea1f1bfc53ac0bc7ccf8200bb275fd52 upstream.

Add MEI Lewisburg PCH IDs for Purley based workstations.

Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/mei/hw-me-regs.h |    2 ++
 drivers/misc/mei/pci-me.c     |    1 +
 2 files changed, 3 insertions(+)

--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -122,6 +122,8 @@
 #define MEI_DEV_ID_SPT_H      0xA13A  /* Sunrise Point H */
 #define MEI_DEV_ID_SPT_H_2    0xA13B  /* Sunrise Point H 2 */
 
+#define MEI_DEV_ID_LBG        0xA1BA  /* Lewisburg (SPT) */
+
 #define MEI_DEV_ID_BXT_M      0x1A9A  /* Broxton M */
 #define MEI_DEV_ID_APL_I      0x5A9A  /* Apollo Lake I */
 
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -87,6 +87,7 @@ static const struct pci_device_id mei_me
 	{MEI_PCI_DEVICE(MEI_DEV_ID_SPT_2, mei_me_pch8_cfg)},
 	{MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H, mei_me_pch8_sps_cfg)},
 	{MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H_2, mei_me_pch8_sps_cfg)},
+	{MEI_PCI_DEVICE(MEI_DEV_ID_LBG, mei_me_pch8_cfg)},
 
 	{MEI_PCI_DEVICE(MEI_DEV_ID_BXT_M, mei_me_pch8_cfg)},
 	{MEI_PCI_DEVICE(MEI_DEV_ID_APL_I, mei_me_pch8_cfg)},

[PATCH 4.9 053/116] block: protect iterate_bdevs() against concurrent close

[Greg Kroah-Hartman]

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

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

From: Rabin Vincent <rabinv@axis.com>

commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream.

If a block device is closed while iterate_bdevs() is handling it, the
following NULL pointer dereference occurs because bdev->b_disk is NULL
in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
turn called by the mapping_cap_writeback_dirty() call in
__filemap_fdatawrite_range()):

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
 IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
 PGD 9e62067 PUD 9ee8067 PMD 0
 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
 Modules linked in:
 CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
 task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
 RIP: 0010:[<ffffffff81314790>]  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
 RSP: 0018:ffff880009f5fe68  EFLAGS: 00010246
 RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
 RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
 RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
 R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
 FS:  00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
 Stack:
  ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
  0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
  ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
 Call Trace:
  [<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
  [<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
  [<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
  [<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
  [<ffffffff811b2763>] sys_sync+0x63/0x90
  [<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
 Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
 RIP  [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
  RSP <ffff880009f5fe68>
 CR2: 0000000000000508
 ---[ end trace 2487336ceb3de62d ]---

The crash is easily reproducible by running the following command, if an
msleep(100) is inserted before the call to func() in iterate_devs():

 while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done

Fix it by holding the bd_mutex across the func() call and only calling
func() if the bdev is opened.

Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
Reported-and-tested-by: Wei Fang <fangwei1@huawei.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/block_dev.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1950,6 +1950,7 @@ void iterate_bdevs(void (*func)(struct b
 	spin_lock(&blockdev_superblock->s_inode_list_lock);
 	list_for_each_entry(inode, &blockdev_superblock->s_inodes, i_sb_list) {
 		struct address_space *mapping = inode->i_mapping;
+		struct block_device *bdev;
 
 		spin_lock(&inode->i_lock);
 		if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW) ||
@@ -1970,8 +1971,12 @@ void iterate_bdevs(void (*func)(struct b
 		 */
 		iput(old_inode);
 		old_inode = inode;
+		bdev = I_BDEV(inode);
 
-		func(I_BDEV(inode), arg);
+		mutex_lock(&bdev->bd_mutex);
+		if (bdev->bd_openers)
+			func(bdev, arg);
+		mutex_unlock(&bdev->bd_mutex);
 
 		spin_lock(&blockdev_superblock->s_inode_list_lock);
 	}

[PATCH 4.9 054/116] vt: fix Scroll Lock LED trigger name

[Greg Kroah-Hartman]

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

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

From: Maciej S. Szmigiero <mail@maciej.szmigiero.name>

commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream.

There is a disagreement between drivers/tty/vt/keyboard.c and
drivers/input/input-leds.c with regard to what is a Scroll Lock LED
trigger name: input calls it "kbd-scrolllock", but vt calls it
"kbd-scrollock" (two l's).
This prevents Scroll Lock LED trigger from binding to this LED by default.

Since it is a scroLL Lock LED, this interface was introduced only about a
year ago and in an Internet search people seem to reference this trigger
only to set it to this LED let's simply rename it to "kbd-scrolllock".

Also, it looks like this was supposed to be changed before this code was
merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
the input side.

Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/vt/keyboard.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -982,7 +982,7 @@ static void kbd_led_trigger_activate(str
 	KBD_LED_TRIGGER((_led_bit) + 8, _name)
 
 static struct kbd_led_trigger kbd_led_triggers[] = {
-	KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
+	KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"),
 	KBD_LED_TRIGGER(VC_NUMLOCK,   "kbd-numlock"),
 	KBD_LED_TRIGGER(VC_CAPSLOCK,  "kbd-capslock"),
 	KBD_LED_TRIGGER(VC_KANALOCK,  "kbd-kanalock"),

[PATCH 4.9 055/116] stm class: Fix device leak in open error path

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <johan@kernel.org>

commit a0ebf519b8a2666438d999c62995618c710573e5 upstream.

Make sure to drop the reference taken by class_find_device() also on
allocation errors in open().

Signed-off-by: Johan Hovold <johan@kernel.org>
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for...")
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/hwtracing/stm/core.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -361,7 +361,7 @@ static int stm_char_open(struct inode *i
 	struct stm_file *stmf;
 	struct device *dev;
 	unsigned int major = imajor(inode);
-	int err = -ENODEV;
+	int err = -ENOMEM;
 
 	dev = class_find_device(&stm_class, NULL, &major, major_match);
 	if (!dev)
@@ -369,8 +369,9 @@ static int stm_char_open(struct inode *i
 
 	stmf = kzalloc(sizeof(*stmf), GFP_KERNEL);
 	if (!stmf)
-		return -ENOMEM;
+		goto err_put_device;
 
+	err = -ENODEV;
 	stm_output_init(&stmf->output);
 	stmf->stm = to_stm_device(dev);
 
@@ -382,9 +383,10 @@ static int stm_char_open(struct inode *i
 	return nonseekable_open(inode, file);
 
 err_free:
+	kfree(stmf);
+err_put_device:
 	/* matches class_find_device() above */
 	put_device(dev);
-	kfree(stmf);
 
 	return err;
 }

[PATCH 4.9 056/116] scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

[Greg Kroah-Hartman]

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

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

From: Kashyap Desai <kashyap.desai@broadcom.com>

commit 18e1c7f68a5814442abad849abe6eacbf02ffd7c upstream.

For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds.  As driver does
not set convert flag to 1 and still making the OCR to run, VF(Virtual
function) driver is directly writing on to the register instead of
waiting for 30 seconds. Setting convert flag to 1 will cause VF driver
will wait for 30 secs before going for reset.

Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2823,6 +2823,7 @@ int megasas_wait_for_outstanding_fusion(
 		dev_err(&instance->pdev->dev, "pending commands remain after waiting, "
 		       "will reset adapter scsi%d.\n",
 		       instance->host->host_no);
+		*convert = 1;
 		retval = 1;
 	}
 out:

[PATCH 4.9 057/116] scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

[Greg Kroah-Hartman]

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

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

From: Kashyap Desai <kashyap.desai@broadcom.com>

commit d5573584429254a14708cf8375c47092b5edaf2c upstream.

Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2000,6 +2000,8 @@ megasas_build_syspd_fusion(struct megasa
 		io_request->DevHandle = pd_sync->seq[pd_index].devHandle;
 		pRAID_Context->regLockFlags |=
 			(MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA);
+		pRAID_Context->Type = MPI2_TYPE_CUDA;
+		pRAID_Context->nseg = 0x1;
 	} else if (fusion->fast_path_io) {
 		pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id);
 		pRAID_Context->configSeqNum = 0;
@@ -2035,12 +2037,10 @@ megasas_build_syspd_fusion(struct megasa
 		pRAID_Context->timeoutValue =
 			cpu_to_le16((os_timeout_value > timeout_limit) ?
 			timeout_limit : os_timeout_value);
-		if (fusion->adapter_type == INVADER_SERIES) {
-			pRAID_Context->Type = MPI2_TYPE_CUDA;
-			pRAID_Context->nseg = 0x1;
+		if (fusion->adapter_type == INVADER_SERIES)
 			io_request->IoFlags |=
 				cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
-		}
+
 		cmd->request_desc->SCSIIO.RequestFlags =
 			(MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
 				MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);

[PATCH 4.9 058/116] iscsi-target: Return error if unable to add network portal

[Greg Kroah-Hartman]

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

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

From: Varun Prakash <varun@chelsio.com>

commit 83337e544323a8bd7492994d64af339175ac7107 upstream.

If iscsit_tpg_add_network_portal() fails then
return error code instead of 0 to user space.

If iscsi-target returns 0 then user space keeps
on retrying same command infinitely, targetcli or
echo hangs till command completes with non zero
return value. In some cases it is possible that
add network portal command never completes with
success even after retrying multiple times,
for example - cxgbit_setup_np() always returns
-EINVAL if portal IP does not belong to Chelsio
adapter interface.

Signed-off-by: Varun Prakash <varun@chelsio.com>
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
[ bvanassche: Added "Fixes:" and "Cc: stable" tags ]
Fixes: commit d4b3fa4b0881 ("iscsi-target: Make iscsi_tpg_np driver show/store use generic code")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/iscsi/iscsi_target_configfs.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -100,8 +100,10 @@ static ssize_t lio_target_np_driver_stor
 
 		tpg_np_new = iscsit_tpg_add_network_portal(tpg,
 					&np->np_sockaddr, tpg_np, type);
-		if (IS_ERR(tpg_np_new))
+		if (IS_ERR(tpg_np_new)) {
+			rc = PTR_ERR(tpg_np_new);
 			goto out;
+		}
 	} else {
 		tpg_np_new = iscsit_tpg_locate_child_np(tpg_np, type);
 		if (tpg_np_new) {

[PATCH 4.9 059/116] scsi: zfcp: fix use-after-"free" in FC ingress path after TMF

[Greg Kroah-Hartman]

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

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

From: Benjamin Block <bblock@linux.vnet.ibm.com>

commit dac37e15b7d511e026a9313c8c46794c144103cd upstream.

When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
eh_target_reset_handler(), it expects us to relent the ownership over
the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN
or target - when returning with SUCCESS from the callback ('release'
them).  SCSI EH can then reuse those commands.

We did not follow this rule to release commands upon SUCCESS; and if
later a reply arrived for one of those supposed to be released commands,
we would still make use of the scsi_cmnd in our ingress tasklet. This
will at least result in undefined behavior or a kernel panic because of
a wrong kernel pointer dereference.

To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req
*)->data in the matching scope if a TMF was successful. This is done
under the locks (struct zfcp_adapter *)->abort_lock and (struct
zfcp_reqlist *)->lock to prevent the requests from being removed from
the request-hashtable, and the ingress tasklet from making use of the
scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler().

For cases where a reply arrives during SCSI EH, but before we get a
chance to NULLify the pointer - but before we return from the callback
-, we assume that the code is protected from races via the CAS operation
in blk_complete_request() that is called in scsi_done().

The following stacktrace shows an example for a crash resulting from the
previous behavior:

Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000
Oops: 0038 [#1] SMP
CPU: 2 PID: 0 Comm: swapper/2 Not tainted
task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000
Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015
           ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800
           000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93
           00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918
Krnl Code: 00000000001156a2: a7190000        lghi    %r1,0
           00000000001156a6: a7380015        lhi    %r3,21
          #00000000001156aa: e32050000008    ag    %r2,0(%r5)
          >00000000001156b0: 482022b0        lh    %r2,688(%r2)
           00000000001156b4: ae123000        sigp    %r1,%r2,0(%r3)
           00000000001156b8: b2220020        ipm    %r2
           00000000001156bc: 8820001c        srl    %r2,28
           00000000001156c0: c02700000001    xilf    %r2,1
Call Trace:
([<0000000000000000>] 0x0)
 [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
 [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
 [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
 [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
 [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio]
 [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
 [<0000000000141fd4>] tasklet_action+0x9c/0x170
 [<0000000000141550>] __do_softirq+0xe8/0x258
 [<000000000010ce0a>] do_softirq+0xba/0xc0
 [<000000000014187c>] irq_exit+0xc4/0xe8
 [<000000000046b526>] do_IRQ+0x146/0x1d8
 [<00000000005d6a3c>] io_return+0x0/0x8
 [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0
([<0000000000000000>] 0x0)
 [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0
 [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8
 [<0000000000114782>] smp_start_secondary+0xda/0xe8
 [<00000000005d6efe>] restart_int_handler+0x56/0x6c
 [<0000000000000000>] 0x0
Last Breaking-Event-Address:
 [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0

Suggested-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_dbf.h     |   11 +++++++
 drivers/s390/scsi/zfcp_reqlist.h |   30 +++++++++++++++++++-
 drivers/s390/scsi/zfcp_scsi.c    |   57 +++++++++++++++++++++++++++++++++++++--
 3 files changed, 95 insertions(+), 3 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -388,4 +388,15 @@ void zfcp_dbf_scsi_devreset(char *tag, s
 	_zfcp_dbf_scsi(tmp_tag, 1, scmnd, NULL);
 }
 
+/**
+ * zfcp_dbf_scsi_nullcmnd() - trace NULLify of SCSI command in dev/tgt-reset.
+ * @scmnd: SCSI command that was NULLified.
+ * @fsf_req: request that owned @scmnd.
+ */
+static inline void zfcp_dbf_scsi_nullcmnd(struct scsi_cmnd *scmnd,
+					  struct zfcp_fsf_req *fsf_req)
+{
+	_zfcp_dbf_scsi("scfc__1", 3, scmnd, fsf_req);
+}
+
 #endif /* ZFCP_DBF_H */
--- a/drivers/s390/scsi/zfcp_reqlist.h
+++ b/drivers/s390/scsi/zfcp_reqlist.h
@@ -4,7 +4,7 @@
  * Data structure and helper functions for tracking pending FSF
  * requests.
  *
- * Copyright IBM Corp. 2009
+ * Copyright IBM Corp. 2009, 2016
  */
 
 #ifndef ZFCP_REQLIST_H
@@ -180,4 +180,32 @@ static inline void zfcp_reqlist_move(str
 	spin_unlock_irqrestore(&rl->lock, flags);
 }
 
+/**
+ * zfcp_reqlist_apply_for_all() - apply a function to every request.
+ * @rl: the requestlist that contains the target requests.
+ * @f: the function to apply to each request; the first parameter of the
+ *     function will be the target-request; the second parameter is the same
+ *     pointer as given with the argument @data.
+ * @data: freely chosen argument; passed through to @f as second parameter.
+ *
+ * Uses :c:macro:`list_for_each_entry` to iterate over the lists in the hash-
+ * table (not a 'safe' variant, so don't modify the list).
+ *
+ * Holds @rl->lock over the entire request-iteration.
+ */
+static inline void
+zfcp_reqlist_apply_for_all(struct zfcp_reqlist *rl,
+			   void (*f)(struct zfcp_fsf_req *, void *), void *data)
+{
+	struct zfcp_fsf_req *req;
+	unsigned long flags;
+	unsigned int i;
+
+	spin_lock_irqsave(&rl->lock, flags);
+	for (i = 0; i < ZFCP_REQ_LIST_BUCKETS; i++)
+		list_for_each_entry(req, &rl->buckets[i], list)
+			f(req, data);
+	spin_unlock_irqrestore(&rl->lock, flags);
+}
+
 #endif /* ZFCP_REQLIST_H */
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -3,7 +3,7 @@
  *
  * Interface to Linux SCSI midlayer.
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #define KMSG_COMPONENT "zfcp"
@@ -209,6 +209,57 @@ static int zfcp_scsi_eh_abort_handler(st
 	return retval;
 }
 
+struct zfcp_scsi_req_filter {
+	u8 tmf_scope;
+	u32 lun_handle;
+	u32 port_handle;
+};
+
+static void zfcp_scsi_forget_cmnd(struct zfcp_fsf_req *old_req, void *data)
+{
+	struct zfcp_scsi_req_filter *filter =
+		(struct zfcp_scsi_req_filter *)data;
+
+	/* already aborted - prevent side-effects - or not a SCSI command */
+	if (old_req->data == NULL || old_req->fsf_command != FSF_QTCB_FCP_CMND)
+		return;
+
+	/* (tmf_scope == FCP_TMF_TGT_RESET || tmf_scope == FCP_TMF_LUN_RESET) */
+	if (old_req->qtcb->header.port_handle != filter->port_handle)
+		return;
+
+	if (filter->tmf_scope == FCP_TMF_LUN_RESET &&
+	    old_req->qtcb->header.lun_handle != filter->lun_handle)
+		return;
+
+	zfcp_dbf_scsi_nullcmnd((struct scsi_cmnd *)old_req->data, old_req);
+	old_req->data = NULL;
+}
+
+static void zfcp_scsi_forget_cmnds(struct zfcp_scsi_dev *zsdev, u8 tm_flags)
+{
+	struct zfcp_adapter *adapter = zsdev->port->adapter;
+	struct zfcp_scsi_req_filter filter = {
+		.tmf_scope = FCP_TMF_TGT_RESET,
+		.port_handle = zsdev->port->handle,
+	};
+	unsigned long flags;
+
+	if (tm_flags == FCP_TMF_LUN_RESET) {
+		filter.tmf_scope = FCP_TMF_LUN_RESET;
+		filter.lun_handle = zsdev->lun_handle;
+	}
+
+	/*
+	 * abort_lock secures against other processings - in the abort-function
+	 * and normal cmnd-handler - of (struct zfcp_fsf_req *)->data
+	 */
+	write_lock_irqsave(&adapter->abort_lock, flags);
+	zfcp_reqlist_apply_for_all(adapter->req_list, zfcp_scsi_forget_cmnd,
+				   &filter);
+	write_unlock_irqrestore(&adapter->abort_lock, flags);
+}
+
 static int zfcp_task_mgmt_function(struct scsi_cmnd *scpnt, u8 tm_flags)
 {
 	struct zfcp_scsi_dev *zfcp_sdev = sdev_to_zfcp(scpnt->device);
@@ -241,8 +292,10 @@ static int zfcp_task_mgmt_function(struc
 	if (fsf_req->status & ZFCP_STATUS_FSFREQ_TMFUNCFAILED) {
 		zfcp_dbf_scsi_devreset("fail", scpnt, tm_flags);
 		retval = FAILED;
-	} else
+	} else {
 		zfcp_dbf_scsi_devreset("okay", scpnt, tm_flags);
+		zfcp_scsi_forget_cmnds(zfcp_sdev, tm_flags);
+	}
 
 	zfcp_fsf_req_free(fsf_req);
 	return retval;

[PATCH 4.9 060/116] scsi: zfcp: do not trace pure benign residual HBA responses at default level

[Greg Kroah-Hartman]

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

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

From: Steffen Maier <maier@linux.vnet.ibm.com>

commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.

Since quite a while, Linux issues enough SCSI commands per scsi_device
which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
other and important HBA trace records long enough.

Therefore, do not trace HBA response errors for pure benign residual
under counts at the default trace level.

This excludes benign residual under count combined with other validity
bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
cases, we still do want to see both the HBA record and the corresponding
SCSI record by default.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_dbf.h |   30 ++++++++++++++++++++++++++++--
 drivers/s390/scsi/zfcp_fsf.h |    3 ++-
 2 files changed, 30 insertions(+), 3 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -2,7 +2,7 @@
  * zfcp device driver
  * debug feature declarations
  *
- * Copyright IBM Corp. 2008, 2015
+ * Copyright IBM Corp. 2008, 2016
  */
 
 #ifndef ZFCP_DBF_H
@@ -283,6 +283,30 @@ struct zfcp_dbf {
 	struct zfcp_dbf_scsi		scsi_buf;
 };
 
+/**
+ * zfcp_dbf_hba_fsf_resp_suppress - true if we should not trace by default
+ * @req: request that has been completed
+ *
+ * Returns true if FCP response with only benign residual under count.
+ */
+static inline
+bool zfcp_dbf_hba_fsf_resp_suppress(struct zfcp_fsf_req *req)
+{
+	struct fsf_qtcb *qtcb = req->qtcb;
+	u32 fsf_stat = qtcb->header.fsf_status;
+	struct fcp_resp *fcp_rsp;
+	u8 rsp_flags, fr_status;
+
+	if (qtcb->prefix.qtcb_type != FSF_IO_COMMAND)
+		return false; /* not an FCP response */
+	fcp_rsp = (struct fcp_resp *)&qtcb->bottom.io.fcp_rsp;
+	rsp_flags = fcp_rsp->fr_flags;
+	fr_status = fcp_rsp->fr_status;
+	return (fsf_stat == FSF_FCP_RSP_AVAILABLE) &&
+		(rsp_flags == FCP_RESID_UNDER) &&
+		(fr_status == SAM_STAT_GOOD);
+}
+
 static inline
 void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
 {
@@ -304,7 +328,9 @@ void zfcp_dbf_hba_fsf_response(struct zf
 		zfcp_dbf_hba_fsf_resp("fs_perr", 1, req);
 
 	} else if (qtcb->header.fsf_status != FSF_GOOD) {
-		zfcp_dbf_hba_fsf_resp("fs_ferr", 1, req);
+		zfcp_dbf_hba_fsf_resp("fs_ferr",
+				      zfcp_dbf_hba_fsf_resp_suppress(req)
+				      ? 5 : 1, req);
 
 	} else if ((req->fsf_command == FSF_QTCB_OPEN_PORT_WITH_DID) ||
 		   (req->fsf_command == FSF_QTCB_OPEN_LUN)) {
--- a/drivers/s390/scsi/zfcp_fsf.h
+++ b/drivers/s390/scsi/zfcp_fsf.h
@@ -3,7 +3,7 @@
  *
  * Interface to the FSF support functions.
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #ifndef FSF_H
@@ -78,6 +78,7 @@
 #define FSF_APP_TAG_CHECK_FAILURE		0x00000082
 #define FSF_REF_TAG_CHECK_FAILURE		0x00000083
 #define FSF_ADAPTER_STATUS_AVAILABLE		0x000000AD
+#define FSF_FCP_RSP_AVAILABLE			0x000000AF
 #define FSF_UNKNOWN_COMMAND			0x000000E2
 #define FSF_UNKNOWN_OP_SUBTYPE                  0x000000E3
 #define FSF_INVALID_COMMAND_OPTION              0x000000E5

[PATCH 4.9 061/116] scsi: zfcp: fix rport unblock race with LUN recovery

[Greg Kroah-Hartman]

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

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

From: Steffen Maier <maier@linux.vnet.ibm.com>

commit 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c upstream.

It is unavoidable that zfcp_scsi_queuecommand() has to finish requests
with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time
window when zfcp detected an unavailable rport but
fc_remote_port_delete(), which is asynchronous via
zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.

However, for the case when the rport becomes available again, we should
prevent unblocking the rport too early.  In contrast to other FCP LLDDs,
zfcp has to open each LUN with the FCP channel hardware before it can
send I/O to a LUN.  So if a port already has LUNs attached and we
unblock the rport just after port recovery, recoveries of LUNs behind
this port can still be pending which in turn force
zfcp_scsi_queuecommand() to unnecessarily finish requests with
DID_IMM_RETRY.

This also opens a time window with unblocked rport (until the followup
LUN reopen recovery has finished).  If a scsi_cmnd timeout occurs during
this time window fc_timed_out() cannot work as desired and such command
would indeed time out and trigger scsi_eh. This prevents a clean and
timely path failover.  This should not happen if the path issue can be
recovered on FC transport layer such as path issues involving RSCNs.

Fix this by only calling zfcp_scsi_schedule_rport_register(), to
asynchronously trigger fc_remote_port_add(), after all LUN recoveries as
children of the rport have finished and no new recoveries of equal or
higher order were triggered meanwhile.  Finished intentionally includes
any recovery result no matter if successful or failed (still unblock
rport so other successful LUNs work).  For simplicity, we check after
each finished LUN recovery if there is another LUN recovery pending on
the same port and then do nothing.  We handle the special case of a
successful recovery of a port without LUN children the same way without
changing this case's semantics.

For debugging we introduce 2 new trace records written if the rport
unblock attempt was aborted due to still unfinished or freshly triggered
recovery. The records are only written above the default trace level.

Benjamin noticed the important special case of new recovery that can be
triggered between having given up the erp_lock and before calling
zfcp_erp_action_cleanup() within zfcp_erp_strategy().  We must avoid the
following sequence:

ERP thread                 rport_work      other context
-------------------------  --------------  --------------------------------
port is unblocked, rport still blocked,
 due to pending/running ERP action,
 so ((port->status & ...UNBLOCK) != 0)
 and (port->rport == NULL)
unlock ERP
zfcp_erp_action_cleanup()
case ZFCP_ERP_ACTION_REOPEN_LUN:
zfcp_erp_try_rport_unblock()
((status & ...UNBLOCK) != 0) [OLD!]
                                           zfcp_erp_port_reopen()
                                           lock ERP
                                           zfcp_erp_port_block()
                                           port->status clear ...UNBLOCK
                                           unlock ERP
                                           zfcp_scsi_schedule_rport_block()
                                           port->rport_task = RPORT_DEL
                                           queue_work(rport_work)
                           zfcp_scsi_rport_work()
                           (port->rport_task != RPORT_ADD)
                           port->rport_task = RPORT_NONE
                           zfcp_scsi_rport_block()
                           if (!port->rport) return
zfcp_scsi_schedule_rport_register()
port->rport_task = RPORT_ADD
queue_work(rport_work)
                           zfcp_scsi_rport_work()
                           (port->rport_task == RPORT_ADD)
                           port->rport_task = RPORT_NONE
                           zfcp_scsi_rport_register()
                           (port->rport == NULL)
                           rport = fc_remote_port_add()
                           port->rport = rport;

Now the rport was erroneously unblocked while the zfcp_port is blocked.
This is another situation we want to avoid due to scsi_eh
potential. This state would at least remain until the new recovery from
the other context finished successfully, or potentially forever if it
failed.  In order to close this race, we take the erp_lock inside
zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or
LUN.  With that, the possible corresponding rport state sequences would
be: (unblock[ERP thread],block[other context]) if the ERP thread gets
erp_lock first and still sees ((port->status & ...UNBLOCK) != 0),
(block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
after the other context has already cleard ...UNBLOCK from port->status.

Since checking fields of struct erp_action is unsafe because they could
have been overwritten (re-used for new recovery) meanwhile, we only
check status of zfcp_port and LUN since these are only changed under
erp_lock elsewhere. Regarding the check of the proper status flags (port
or port_forced are similar to the shown adapter recovery):

[zfcp_erp_adapter_shutdown()]
zfcp_erp_adapter_reopen()
 zfcp_erp_adapter_block()
  * clear UNBLOCK ---------------------------------------+
 zfcp_scsi_schedule_rports_block()                       |
 write_lock_irqsave(&adapter->erp_lock, flags);-------+  |
 zfcp_erp_action_enqueue()                            |  |
  zfcp_erp_setup_act()                                |  |
   * set ERP_INUSE -----------------------------------|--|--+
 write_unlock_irqrestore(&adapter->erp_lock, flags);--+  |  |
.context-switch.                                         |  |
zfcp_erp_thread()                                        |  |
 zfcp_erp_strategy()                                     |  |
  write_lock_irqsave(&adapter->erp_lock, flags);------+  |  |
  ...                                                 |  |  |
  zfcp_erp_strategy_check_target()                    |  |  |
   zfcp_erp_strategy_check_adapter()                  |  |  |
    zfcp_erp_adapter_unblock()                        |  |  |
     * set UNBLOCK -----------------------------------|--+  |
  zfcp_erp_action_dequeue()                           |     |
   * clear ERP_INUSE ---------------------------------|-----+
  ...                                                 |
  write_unlock_irqrestore(&adapter->erp_lock, flags);-+

Hence, we should check for both UNBLOCK and ERP_INUSE because they are
interleaved.  Also we need to explicitly check ERP_FAILED for the link
down case which currently does not clear the UNBLOCK flag in
zfcp_fsf_link_down_info_eval().

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 8830271c4819 ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport")
Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/scsi/zfcp_dbf.c  |   17 +++++++++--
 drivers/s390/scsi/zfcp_erp.c  |   61 ++++++++++++++++++++++++++++++++++++++++--
 drivers/s390/scsi/zfcp_ext.h  |    4 ++
 drivers/s390/scsi/zfcp_scsi.c |    4 --
 4 files changed, 77 insertions(+), 9 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -289,11 +289,12 @@ void zfcp_dbf_rec_trig(char *tag, struct
 
 
 /**
- * zfcp_dbf_rec_run - trace event related to running recovery
+ * zfcp_dbf_rec_run_lvl - trace event related to running recovery
+ * @level: trace level to be used for event
  * @tag: identifier for event
  * @erp: erp_action running
  */
-void zfcp_dbf_rec_run(char *tag, struct zfcp_erp_action *erp)
+void zfcp_dbf_rec_run_lvl(int level, char *tag, struct zfcp_erp_action *erp)
 {
 	struct zfcp_dbf *dbf = erp->adapter->dbf;
 	struct zfcp_dbf_rec *rec = &dbf->rec_buf;
@@ -319,11 +320,21 @@ void zfcp_dbf_rec_run(char *tag, struct
 	else
 		rec->u.run.rec_count = atomic_read(&erp->adapter->erp_counter);
 
-	debug_event(dbf->rec, 1, rec, sizeof(*rec));
+	debug_event(dbf->rec, level, rec, sizeof(*rec));
 	spin_unlock_irqrestore(&dbf->rec_lock, flags);
 }
 
 /**
+ * zfcp_dbf_rec_run - trace event related to running recovery
+ * @tag: identifier for event
+ * @erp: erp_action running
+ */
+void zfcp_dbf_rec_run(char *tag, struct zfcp_erp_action *erp)
+{
+	zfcp_dbf_rec_run_lvl(1, tag, erp);
+}
+
+/**
  * zfcp_dbf_rec_run_wka - trace wka port event with info like running recovery
  * @tag: identifier for event
  * @wka_port: well known address port
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -3,7 +3,7 @@
  *
  * Error Recovery Procedures (ERP).
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #define KMSG_COMPONENT "zfcp"
@@ -1204,6 +1204,62 @@ static void zfcp_erp_action_dequeue(stru
 	}
 }
 
+/**
+ * zfcp_erp_try_rport_unblock - unblock rport if no more/new recovery
+ * @port: zfcp_port whose fc_rport we should try to unblock
+ */
+static void zfcp_erp_try_rport_unblock(struct zfcp_port *port)
+{
+	unsigned long flags;
+	struct zfcp_adapter *adapter = port->adapter;
+	int port_status;
+	struct Scsi_Host *shost = adapter->scsi_host;
+	struct scsi_device *sdev;
+
+	write_lock_irqsave(&adapter->erp_lock, flags);
+	port_status = atomic_read(&port->status);
+	if ((port_status & ZFCP_STATUS_COMMON_UNBLOCKED)    == 0 ||
+	    (port_status & (ZFCP_STATUS_COMMON_ERP_INUSE |
+			    ZFCP_STATUS_COMMON_ERP_FAILED)) != 0) {
+		/* new ERP of severity >= port triggered elsewhere meanwhile or
+		 * local link down (adapter erp_failed but not clear unblock)
+		 */
+		zfcp_dbf_rec_run_lvl(4, "ertru_p", &port->erp_action);
+		write_unlock_irqrestore(&adapter->erp_lock, flags);
+		return;
+	}
+	spin_lock(shost->host_lock);
+	__shost_for_each_device(sdev, shost) {
+		struct zfcp_scsi_dev *zsdev = sdev_to_zfcp(sdev);
+		int lun_status;
+
+		if (zsdev->port != port)
+			continue;
+		/* LUN under port of interest */
+		lun_status = atomic_read(&zsdev->status);
+		if ((lun_status & ZFCP_STATUS_COMMON_ERP_FAILED) != 0)
+			continue; /* unblock rport despite failed LUNs */
+		/* LUN recovery not given up yet [maybe follow-up pending] */
+		if ((lun_status & ZFCP_STATUS_COMMON_UNBLOCKED) == 0 ||
+		    (lun_status & ZFCP_STATUS_COMMON_ERP_INUSE) != 0) {
+			/* LUN blocked:
+			 * not yet unblocked [LUN recovery pending]
+			 * or meanwhile blocked [new LUN recovery triggered]
+			 */
+			zfcp_dbf_rec_run_lvl(4, "ertru_l", &zsdev->erp_action);
+			spin_unlock(shost->host_lock);
+			write_unlock_irqrestore(&adapter->erp_lock, flags);
+			return;
+		}
+	}
+	/* now port has no child or all children have completed recovery,
+	 * and no ERP of severity >= port was meanwhile triggered elsewhere
+	 */
+	zfcp_scsi_schedule_rport_register(port);
+	spin_unlock(shost->host_lock);
+	write_unlock_irqrestore(&adapter->erp_lock, flags);
+}
+
 static void zfcp_erp_action_cleanup(struct zfcp_erp_action *act, int result)
 {
 	struct zfcp_adapter *adapter = act->adapter;
@@ -1214,6 +1270,7 @@ static void zfcp_erp_action_cleanup(stru
 	case ZFCP_ERP_ACTION_REOPEN_LUN:
 		if (!(act->status & ZFCP_STATUS_ERP_NO_REF))
 			scsi_device_put(sdev);
+		zfcp_erp_try_rport_unblock(port);
 		break;
 
 	case ZFCP_ERP_ACTION_REOPEN_PORT:
@@ -1224,7 +1281,7 @@ static void zfcp_erp_action_cleanup(stru
 		 */
 		if (act->step != ZFCP_ERP_STEP_UNINITIALIZED)
 			if (result == ZFCP_ERP_SUCCEEDED)
-				zfcp_scsi_schedule_rport_register(port);
+				zfcp_erp_try_rport_unblock(port);
 		/* fall through */
 	case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
 		put_device(&port->dev);
--- a/drivers/s390/scsi/zfcp_ext.h
+++ b/drivers/s390/scsi/zfcp_ext.h
@@ -3,7 +3,7 @@
  *
  * External function declarations.
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #ifndef ZFCP_EXT_H
@@ -35,6 +35,8 @@ extern void zfcp_dbf_adapter_unregister(
 extern void zfcp_dbf_rec_trig(char *, struct zfcp_adapter *,
 			      struct zfcp_port *, struct scsi_device *, u8, u8);
 extern void zfcp_dbf_rec_run(char *, struct zfcp_erp_action *);
+extern void zfcp_dbf_rec_run_lvl(int level, char *tag,
+				 struct zfcp_erp_action *erp);
 extern void zfcp_dbf_rec_run_wka(char *, struct zfcp_fc_wka_port *, u64);
 extern void zfcp_dbf_hba_fsf_uss(char *, struct zfcp_fsf_req *);
 extern void zfcp_dbf_hba_fsf_res(char *, int, struct zfcp_fsf_req *);
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -88,9 +88,7 @@ int zfcp_scsi_queuecommand(struct Scsi_H
 	}
 
 	if (unlikely(!(status & ZFCP_STATUS_COMMON_UNBLOCKED))) {
-		/* This could be either
-		 * open LUN pending: this is temporary, will result in
-		 *	open LUN or ERP_FAILED, so retry command
+		/* This could be
 		 * call to rport_delete pending: mimic retry from
 		 * 	fc_remote_port_chkready until rport is BLOCKED
 		 */

[PATCH 4.9 062/116] scsi: avoid a permanent stop of the scsi devices request queue

[Greg Kroah-Hartman]

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

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

From: Wei Fang <fangwei1@huawei.com>

commit d2a145252c52792bc59e4767b486b26c430af4bb upstream.

A race between scanning and fc_remote_port_delete() may result in a
permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
and unblocked after.  The reason is that blocking a device sets both the
SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED.  However,
scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
device to be ignored by scsi_target_unblock() and thus never have its
QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
running but has a stopped queue.

We actually have two places where SDEV_RUNNING is set: once in
scsi_add_lun() which respects the blocked flag and once in
scsi_sysfs_add_sdev() which doesn't.  Since the second set is entirely
spurious, simply remove it to fix the problem.

Reported-by: Zengxi Chen <chenzengxi@huawei.com>
Signed-off-by: Wei Fang <fangwei1@huawei.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/scsi_sysfs.c |    4 ----
 1 file changed, 4 deletions(-)

--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_devi
 	struct request_queue *rq = sdev->request_queue;
 	struct scsi_target *starget = sdev->sdev_target;
 
-	error = scsi_device_set_state(sdev, SDEV_RUNNING);
-	if (error)
-		return error;
-
 	error = scsi_target_add(starget);
 	if (error)
 		return error;

[PATCH 4.9 063/116] ARC: mm: arc700: Dont assume 2 colours for aliasing VIPT dcache

[Greg Kroah-Hartman]

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

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

From: Vineet Gupta <vgupta@synopsys.com>

commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream.

An ARC700 customer reported linux boot crashes when upgrading to bigger
L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
current code only assumed 2 colours, while theirs had 4. So default to 4
colours and complain if there are fewer. Ideally this needs to be a
Kconfig option, but heck that's too much of hassle for a single user.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arc/include/asm/cacheflush.h |    6 ++++--
 arch/arc/mm/cache.c               |   11 ++++++++---
 2 files changed, 12 insertions(+), 5 deletions(-)

--- a/arch/arc/include/asm/cacheflush.h
+++ b/arch/arc/include/asm/cacheflush.h
@@ -85,6 +85,10 @@ void flush_anon_page(struct vm_area_stru
  */
 #define PG_dc_clean	PG_arch_1
 
+#define CACHE_COLORS_NUM	4
+#define CACHE_COLORS_MSK	(CACHE_COLORS_NUM - 1)
+#define CACHE_COLOR(addr)	(((unsigned long)(addr) >> (PAGE_SHIFT)) & CACHE_COLORS_MSK)
+
 /*
  * Simple wrapper over config option
  * Bootup code ensures that hardware matches kernel configuration
@@ -94,8 +98,6 @@ static inline int cache_is_vipt_aliasing
 	return IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
 }
 
-#define CACHE_COLOR(addr)	(((unsigned long)(addr) >> (PAGE_SHIFT)) & 1)
-
 /*
  * checks if two addresses (after page aligning) index into same cache set
  */
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -979,11 +979,16 @@ void arc_cache_init(void)
 		/* check for D-Cache aliasing on ARCompact: ARCv2 has PIPT */
 		if (is_isa_arcompact()) {
 			int handled = IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
+			int num_colors = dc->sz_k/dc->assoc/TO_KB(PAGE_SIZE);
 
-			if (dc->alias && !handled)
-				panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
-			else if (!dc->alias && handled)
+			if (dc->alias) {
+				if (!handled)
+					panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
+				if (CACHE_COLORS_NUM != num_colors)
+					panic("CACHE_COLORS_NUM not optimized for config\n");
+			} else if (!dc->alias && handled) {
 				panic("Disable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
+			}
 		}
 	}
 

[PATCH 4.9 064/116] firmware: fix usermode helper fallback loading

[Greg Kroah-Hartman]

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

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

From: Yves-Alexis Perez <corsac@corsac.net>

commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.

When you use the firmware usermode helper fallback with a timeout value set to a
value greater than INT_MAX (2147483647) a cast overflow issue causes the
timeout value to go negative and breaks all usermode helper loading. This
regression was introduced through commit 68ff2a00dbf5 ("firmware_loader:
handle timeout via wait_for_completion_interruptible_timeout()") on kernel
v4.0.

The firmware_class drivers relies on the firmware usermode helper
fallback as a mechanism to look for firmware if the direct filesystem
search failed only if:

  a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):

  Then all of these callers will rely on the fallback mechanism in case
  the firmware is not found through an initial direct filesystem lookup:

  o request_firmware()
  o request_firmware_into_buf()
  o request_firmware_nowait()

  b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):

  Then only callers using request_firmware_nowait() with the second
  argument set to false, this explicitly is requesting the UMH firmware
  fallback to be relied on in case the first filesystem lookup fails.

  Using Coccinelle SmPL grammar we have identified only two drivers
  explicitly requesting the UMH firmware fallback mechanism:

  - drivers/firmware/dell_rbu.c
  - drivers/leds/leds-lp55xx-common.c

Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
biggest impact of this regression are users of the dell_rbu and
leds-lp55xx-common device driver which required the UMH to find their
respective needed firmwares.

The default timeout for the UMH is set to 60 seconds always, as of
commit 68ff2a00dbf5 ("firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()") the timeout was bumped
to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
value was also used if the timeout was configured by a user to 0.

The following works:

echo 2147483647 > /sys/class/firmware/timeout

But both of the following set the timeout to MAX_JIFFY_OFFSET even if
we display 0 back to userspace:

echo 2147483648 > /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

echo 0> /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
another cast with simple_strtol().

This fixes the secondary cast (the first one is simple_strtol() but its an
issue only by forcing an implicit limit) by re-using the timeout variable and
only setting retval in appropriate cases.

Lastly worth noting systemd had ripped out the UMH firmware fallback
mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
("udev: remove userspace firmware loading support"), so as of systemd v217.

Signed-off-by: Yves-Alexis Perez <corsac@corsac.net>
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[mcgrof@kernel.org: gave commit log a whole lot of love]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/base/firmware_class.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -955,13 +955,14 @@ static int _request_firmware_load(struct
 		timeout = MAX_JIFFY_OFFSET;
 	}
 
-	retval = wait_for_completion_interruptible_timeout(&buf->completion,
+	timeout = wait_for_completion_interruptible_timeout(&buf->completion,
 			timeout);
-	if (retval == -ERESTARTSYS || !retval) {
+	if (timeout == -ERESTARTSYS || !timeout) {
+		retval = timeout;
 		mutex_lock(&fw_lock);
 		fw_load_abort(fw_priv);
 		mutex_unlock(&fw_lock);
-	} else if (retval > 0) {
+	} else if (timeout > 0) {
 		retval = 0;
 	}
 

[PATCH 4.9 065/116] s390/vmlogrdr: fix IUCV buffer allocation

[Greg Kroah-Hartman]

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

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

From: Gerald Schaefer <gerald.schaefer@de.ibm.com>

commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream.

The buffer for iucv_message_receive() needs to be below 2 GB. In
__iucv_message_receive(), the buffer address is casted to an u32, which
would result in either memory corruption or an addressing exception when
using addresses >= 2 GB.

Fix this by using GFP_DMA for the buffer allocation.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/s390/char/vmlogrdr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/s390/char/vmlogrdr.c
+++ b/drivers/s390/char/vmlogrdr.c
@@ -870,7 +870,7 @@ static int __init vmlogrdr_init(void)
 		goto cleanup;
 
 	for (i=0; i < MAXMINOR; ++i ) {
-		sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL);
+		sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL | GFP_DMA);
 		if (!sys_ser[i].buffer) {
 			rc = -ENOMEM;
 			break;

[PATCH 4.9 066/116] s390/kexec: use node 0 when re-adding crash kernel memory

[Greg Kroah-Hartman]

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

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

From: Heiko Carstens <heiko.carstens@de.ibm.com>

commit 9f88eb4df728aebcd2ddd154d99f1d75b428b897 upstream.

When re-adding crash kernel memory within setup_resources() the
function memblock_add() is used. That function will add memory by
default to node "MAX_NUMNODES" instead of node 0, like the memory
detection code does. In case of !NUMA this will trigger this warning
when the kernel generates the vmemmap:

Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
WARNING: CPU: 0 PID: 0 at mm/memblock.c:1261 memblock_virt_alloc_internal+0x76/0x220
CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6 #16
Call Trace:
 [<0000000000d0b2e8>] memblock_virt_alloc_try_nid+0x88/0xc8
 [<000000000083c8ea>] __earlyonly_bootmem_alloc.constprop.1+0x42/0x50
 [<000000000083e7f4>] vmemmap_populate+0x1ac/0x1e0
 [<0000000000840136>] sparse_mem_map_populate+0x46/0x68
 [<0000000000d0c59c>] sparse_init+0x184/0x238
 [<0000000000cf45f6>] paging_init+0xbe/0xf8
 [<0000000000cf1d4a>] setup_arch+0xa02/0xae0
 [<0000000000ced75a>] start_kernel+0x72/0x450
 [<0000000000100020>] _stext+0x20/0x80

If NUMA is selected numa_setup_memory() will fix the node assignments
before the vmemmap will be populated; so this warning will only appear
if NUMA is not selected.

To fix this simply use memblock_add_node() and re-add crash kernel
memory explicitly to node 0.

Reported-and-tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Fixes: 4e042af463f8 ("s390/kexec: fix crash on resize of reserved memory")
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/s390/kernel/setup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -445,7 +445,7 @@ static void __init setup_resources(void)
 	 * part of the System RAM resource.
 	 */
 	if (crashk_res.end) {
-		memblock_add(crashk_res.start, resource_size(&crashk_res));
+		memblock_add_node(crashk_res.start, resource_size(&crashk_res), 0);
 		memblock_reserve(crashk_res.start, resource_size(&crashk_res));
 		insert_resource(&iomem_resource, &crashk_res);
 	}

[PATCH 4.9 067/116] arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest

[Greg Kroah-Hartman]

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

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

From: Marc Zyngier <marc.zyngier@arm.com>

commit 21cbe3cc8a48ff17059912e019fbde28ed54745a upstream.

The ARMv8 architecture allows the cycle counter to be configured
by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
hence accessing PMCCFILTR_EL0. But it disallows the use of
PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
PMXEVCNTR_EL0.

Linux itself doesn't violate this rule, but we may end up with
PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
despite the guest not having done anything wrong.

In order to avoid this unfortunate course of events (haha!), let's
sanitize PMSELR_EL0 on guest entry. This ensures that the guest
won't explode unexpectedly.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/kvm/hyp/switch.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -85,7 +85,13 @@ static void __hyp_text __activate_traps(
 	write_sysreg(val, hcr_el2);
 	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
 	write_sysreg(1 << 15, hstr_el2);
-	/* Make sure we trap PMU access from EL0 to EL2 */
+	/*
+	 * Make sure we trap PMU access from EL0 to EL2. Also sanitize
+	 * PMSELR_EL0 to make sure it never contains the cycle
+	 * counter, which could make a PMXEVCNTR_EL0 access UNDEF at
+	 * EL1 instead of being trapped to EL2.
+	 */
+	write_sysreg(0, pmselr_el0);
 	write_sysreg(ARMV8_PMU_USERENR_MASK, pmuserenr_el0);
 	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
 	__activate_traps_arch()();

[PATCH 4.9 068/116] latent_entropy: fix ARM build error on earlier gcc

[Greg Kroah-Hartman]

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

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

From: Kees Cook <keescook@chromium.org>

commit 9988f4d577f42f43b7612d755477585f35424af7 upstream.

This fixes build errors seen on gcc-4.9.3 or gcc-5.3.1 for an ARM:

arm-soc/init/initramfs.c: In function 'error':
arm-soc/init/initramfs.c:50:1: error: unrecognizable insn:
 }
 ^
(insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ])
        (rotatert:SI (reg:SI 116 [ local_entropy.243 ])
            (const_int -30 [0xffffffffffffffe2]))) -1
     (nil))

Patch from PaX Team <pageexec@freemail.hu>

Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 scripts/gcc-plugins/latent_entropy_plugin.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/scripts/gcc-plugins/latent_entropy_plugin.c
+++ b/scripts/gcc-plugins/latent_entropy_plugin.c
@@ -328,9 +328,9 @@ static enum tree_code get_op(tree *rhs)
 			op = LROTATE_EXPR;
 			/*
 			 * This code limits the value of random_const to
-			 * the size of a wide int for the rotation
+			 * the size of a long for the rotation
 			 */
-			random_const &= HOST_BITS_PER_WIDE_INT - 1;
+			random_const %= TYPE_PRECISION(long_unsigned_type_node);
 			break;
 		}
 

[PATCH 4.9 069/116] sc16is7xx: Drop bogus use of IRQF_ONESHOT

[Greg Kroah-Hartman]

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

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

From: Josh Cartwright <joshc@ni.com>

commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream.

The use of IRQF_ONESHOT when registering an interrupt handler with
request_irq() is non-sensical.

Not only that, it also prevents the handler from being threaded when it
otherwise should be w/ IRQ_FORCED_THREADING is enabled.  This causes the
following deadlock observed by Sean Nyekjaer on -rt:

Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[..]
   rt_spin_lock_slowlock from queue_kthread_work
   queue_kthread_work from sc16is7xx_irq
   sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
   handle_irq_event_percpu from handle_irq_event
   handle_irq_event from handle_level_irq
   handle_level_irq from generic_handle_irq
   generic_handle_irq from mxc_gpio_irq_handler
   mxc_gpio_irq_handler from mx3_gpio_irq_handler
   mx3_gpio_irq_handler from generic_handle_irq
   generic_handle_irq from __handle_domain_irq
   __handle_domain_irq from gic_handle_irq
   gic_handle_irq from __irq_svc
   __irq_svc from rt_spin_unlock
   rt_spin_unlock from kthread_worker_fn
   kthread_worker_fn from kthread
   kthread from ret_from_fork

Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq")
Reported-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Josh Cartwright <joshc@ni.com>
Cc: linux-rt-users@vger.kernel.org
Cc: Jakub Kicinski <moorray3@wp.pl>
Cc: linux-serial@vger.kernel.org
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/tty/serial/sc16is7xx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1264,7 +1264,7 @@ static int sc16is7xx_probe(struct device
 
 	/* Setup interrupt */
 	ret = devm_request_irq(dev, irq, sc16is7xx_irq,
-			       IRQF_ONESHOT | flags, dev_name(dev), s);
+			       flags, dev_name(dev), s);
 	if (!ret)
 		return 0;
 

[PATCH 4.9 070/116] md/raid5: limit request size according to implementation limits

[Greg Kroah-Hartman]

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

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

From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>

commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream.

Current implementation employ 16bit counter of active stripes in lower
bits of bio->bi_phys_segments. If request is big enough to overflow
this counter bio will be completed and freed too early.

Fortunately this not happens in default configuration because several
other limits prevent that: stripe_cache_size * nr_disks effectively
limits count of active stripes. And small max_sectors_kb at lower
disks prevent that during normal read/write operations.

Overflow easily happens in discard if it's enabled by module parameter
"devices_handle_discard_safely" and stripe_cache_size is set big enough.

This patch limits requests size with 256Mb - 8Kb to prevent overflows.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Shaohua Li <shli@kernel.org>
Cc: Neil Brown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/raid5.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6984,6 +6984,15 @@ static int raid5_run(struct mddev *mddev
 			stripe = (stripe | (stripe-1)) + 1;
 		mddev->queue->limits.discard_alignment = stripe;
 		mddev->queue->limits.discard_granularity = stripe;
+
+		/*
+		 * We use 16-bit counter of active stripes in bi_phys_segments
+		 * (minus one for over-loaded initialization)
+		 */
+		blk_queue_max_hw_sectors(mddev->queue, 0xfffe * STRIPE_SECTORS);
+		blk_queue_max_discard_sectors(mddev->queue,
+					      0xfffe * STRIPE_SECTORS);
+
 		/*
 		 * unaligned part of discard request will be ignored, so can't
 		 * guarantee discard_zeroes_data

[PATCH 4.9 071/116] scsi: aacraid: remove wildcard for series 9 controllers

[Greg Kroah-Hartman]

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

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

From: Kevin Barnett <kevin.barnett@microsemi.com>

commit ae2aae2421983f6f68eb7c4692624bc43ea50712 upstream.

Controllers with this PCI ID never shipped outside of
PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the
correct driver for these controllers.

[mkp: patch description]

Reviewed-by: Scott Teel <scott.teel@microsemi.com>
Signed-off-by: Kevin Barnett <kevin.barnett@microsemi.com>
Signed-off-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/aacraid/linit.c |    2 --
 1 file changed, 2 deletions(-)

--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -160,7 +160,6 @@ static const struct pci_device_id aac_pc
 	{ 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC Series 6 (Tupelo) */
 	{ 0x9005, 0x028c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 63 }, /* Adaptec PMC Series 7 (Denali) */
 	{ 0x9005, 0x028d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 64 }, /* Adaptec PMC Series 8 */
-	{ 0x9005, 0x028f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 65 }, /* Adaptec PMC Series 9 */
 	{ 0,}
 };
 MODULE_DEVICE_TABLE(pci, aac_pci_tbl);
@@ -239,7 +238,6 @@ static struct aac_driver_ident aac_drive
 	{ aac_src_init, "aacraid", "ADAPTEC ", "RAID            ", 2, AAC_QUIRK_SRC }, /* Adaptec PMC Series 6 (Tupelo) */
 	{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID            ", 2, AAC_QUIRK_SRC }, /* Adaptec PMC Series 7 (Denali) */
 	{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID            ", 2, AAC_QUIRK_SRC }, /* Adaptec PMC Series 8 */
-	{ aac_srcv_init, "aacraid", "ADAPTEC ", "RAID            ", 2, AAC_QUIRK_SRC } /* Adaptec PMC Series 9 */
 };
 
 /**

[PATCH 4.9 072/116] KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

[Greg Kroah-Hartman]

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

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

From: Paul Mackerras <paulus@ozlabs.org>

commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream.

When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state.  Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.

This fixes it by saving and restoring the XER.  To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.

The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.

Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 Documentation/virtual/kvm/api.txt       |    1 +
 arch/powerpc/include/asm/kvm_host.h     |    1 +
 arch/powerpc/include/uapi/asm/kvm.h     |    1 +
 arch/powerpc/kernel/asm-offsets.c       |    1 +
 arch/powerpc/kvm/book3s_hv.c            |    6 ++++++
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |    4 ++++
 6 files changed, 14 insertions(+)

--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2050,6 +2050,7 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_TM_VSCR           | 32
   PPC   | KVM_REG_PPC_TM_DSCR           | 64
   PPC   | KVM_REG_PPC_TM_TAR            | 64
+  PPC   | KVM_REG_PPC_TM_XER            | 64
         |                               |
   MIPS  | KVM_REG_MIPS_R0               | 64
           ...
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -546,6 +546,7 @@ struct kvm_vcpu_arch {
 	u64 tfiar;
 
 	u32 cr_tm;
+	u64 xer_tm;
 	u64 lr_tm;
 	u64 ctr_tm;
 	u64 amr_tm;
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -596,6 +596,7 @@ struct kvm_get_htab_header {
 #define KVM_REG_PPC_TM_VSCR	(KVM_REG_PPC_TM | KVM_REG_SIZE_U32 | 0x67)
 #define KVM_REG_PPC_TM_DSCR	(KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x68)
 #define KVM_REG_PPC_TM_TAR	(KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x69)
+#define KVM_REG_PPC_TM_XER	(KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x6a)
 
 /* PPC64 eXternal Interrupt Controller Specification */
 #define KVM_DEV_XICS_GRP_SOURCES	1	/* 64-bit source attributes */
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -569,6 +569,7 @@ int main(void)
 	DEFINE(VCPU_VRS_TM, offsetof(struct kvm_vcpu, arch.vr_tm.vr));
 	DEFINE(VCPU_VRSAVE_TM, offsetof(struct kvm_vcpu, arch.vrsave_tm));
 	DEFINE(VCPU_CR_TM, offsetof(struct kvm_vcpu, arch.cr_tm));
+	DEFINE(VCPU_XER_TM, offsetof(struct kvm_vcpu, arch.xer_tm));
 	DEFINE(VCPU_LR_TM, offsetof(struct kvm_vcpu, arch.lr_tm));
 	DEFINE(VCPU_CTR_TM, offsetof(struct kvm_vcpu, arch.ctr_tm));
 	DEFINE(VCPU_AMR_TM, offsetof(struct kvm_vcpu, arch.amr_tm));
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1288,6 +1288,9 @@ static int kvmppc_get_one_reg_hv(struct
 	case KVM_REG_PPC_TM_CR:
 		*val = get_reg_val(id, vcpu->arch.cr_tm);
 		break;
+	case KVM_REG_PPC_TM_XER:
+		*val = get_reg_val(id, vcpu->arch.xer_tm);
+		break;
 	case KVM_REG_PPC_TM_LR:
 		*val = get_reg_val(id, vcpu->arch.lr_tm);
 		break;
@@ -1498,6 +1501,9 @@ static int kvmppc_set_one_reg_hv(struct
 	case KVM_REG_PPC_TM_CR:
 		vcpu->arch.cr_tm = set_reg_val(id, *val);
 		break;
+	case KVM_REG_PPC_TM_XER:
+		vcpu->arch.xer_tm = set_reg_val(id, *val);
+		break;
 	case KVM_REG_PPC_TM_LR:
 		vcpu->arch.lr_tm = set_reg_val(id, *val);
 		break;
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2600,11 +2600,13 @@ kvmppc_save_tm:
 	mfctr	r7
 	mfspr	r8, SPRN_AMR
 	mfspr	r10, SPRN_TAR
+	mfxer	r11
 	std	r5, VCPU_LR_TM(r9)
 	stw	r6, VCPU_CR_TM(r9)
 	std	r7, VCPU_CTR_TM(r9)
 	std	r8, VCPU_AMR_TM(r9)
 	std	r10, VCPU_TAR_TM(r9)
+	std	r11, VCPU_XER_TM(r9)
 
 	/* Restore r12 as trap number. */
 	lwz	r12, VCPU_TRAP(r9)
@@ -2697,11 +2699,13 @@ kvmppc_restore_tm:
 	ld	r7, VCPU_CTR_TM(r4)
 	ld	r8, VCPU_AMR_TM(r4)
 	ld	r9, VCPU_TAR_TM(r4)
+	ld	r10, VCPU_XER_TM(r4)
 	mtlr	r5
 	mtcr	r6
 	mtctr	r7
 	mtspr	SPRN_AMR, r8
 	mtspr	SPRN_TAR, r9
+	mtxer	r10
 
 	/*
 	 * Load up PPR and DSCR values but don't put them in the actual SPRs

[PATCH 4.9 073/116] KVM: PPC: Book3S HV: Dont lose hardware R/C bit updates in H_PROTECT

[Greg Kroah-Hartman]

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

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

From: Paul Mackerras <paulus@ozlabs.org>

commit f064a0de1579fabded8990bed93971e30deb9ecb upstream.

The hashed page table MMU in POWER processors can update the R
(reference) and C (change) bits in a HPTE at any time until the
HPTE has been invalidated and the TLB invalidation sequence has
completed.  In kvmppc_h_protect, which implements the H_PROTECT
hypercall, we read the HPTE, modify the second doubleword,
invalidate the HPTE in memory, do the TLB invalidation sequence,
and then write the modified value of the second doubleword back
to memory.  In doing so we could overwrite an R/C bit update done
by hardware between when we read the HPTE and when the TLB
invalidation completed.  To fix this we re-read the second
doubleword after the TLB invalidation and OR in the (possibly)
new values of R and C.  We can use an OR since hardware only ever
sets R and C, never clears them.

This race was found by code inspection.  In principle this bug could
cause occasional guest memory corruption under host memory pressure.

Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/kvm/book3s_hv_rm_mmu.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -653,6 +653,8 @@ long kvmppc_h_protect(struct kvm_vcpu *v
 					      HPTE_V_ABSENT);
 			do_tlbies(kvm, &rb, 1, global_invalidates(kvm, flags),
 				  true);
+			/* Don't lose R/C bit updates done by hardware */
+			r |= be64_to_cpu(hpte[1]) & (HPTE_R_R | HPTE_R_C);
 			hpte[1] = cpu_to_be64(r);
 		}
 	}

[PATCH 4.9 074/116] kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

[Greg Kroah-Hartman]

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

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

From: Jim Mattson <jmattson@google.com>

commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream.

When L2 exits to L0 due to "exception or NMI", software exceptions
(#BP and #OF) for which L1 has requested an intercept should be
handled by L1 rather than L0. Previously, only hardware exceptions
were forwarded to L1.

Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kvm/vmx.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1343,10 +1343,10 @@ static inline bool nested_cpu_has_posted
 	return vmcs12->pin_based_vm_exec_control & PIN_BASED_POSTED_INTR;
 }
 
-static inline bool is_exception(u32 intr_info)
+static inline bool is_nmi(u32 intr_info)
 {
 	return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
-		== (INTR_TYPE_HARD_EXCEPTION | INTR_INFO_VALID_MASK);
+		== (INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK);
 }
 
 static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,
@@ -5476,7 +5476,7 @@ static int handle_exception(struct kvm_v
 	if (is_machine_check(intr_info))
 		return handle_machine_check(vcpu);
 
-	if ((intr_info & INTR_INFO_INTR_TYPE_MASK) == INTR_TYPE_NMI_INTR)
+	if (is_nmi(intr_info))
 		return 1;  /* already handled by vmx_vcpu_run() */
 
 	if (is_no_device(intr_info)) {
@@ -8018,7 +8018,7 @@ static bool nested_vmx_exit_handled(stru
 
 	switch (exit_reason) {
 	case EXIT_REASON_EXCEPTION_NMI:
-		if (!is_exception(intr_info))
+		if (is_nmi(intr_info))
 			return false;
 		else if (is_page_fault(intr_info))
 			return enable_ept;
@@ -8611,8 +8611,7 @@ static void vmx_complete_atomic_exit(str
 		kvm_machine_check();
 
 	/* We need to handle NMIs before interrupts are enabled */
-	if ((exit_intr_info & INTR_INFO_INTR_TYPE_MASK) == INTR_TYPE_NMI_INTR &&
-	    (exit_intr_info & INTR_INFO_VALID_MASK)) {
+	if (is_nmi(exit_intr_info)) {
 		kvm_before_handle_nmi(&vmx->vcpu);
 		asm("int $2");
 		kvm_after_handle_nmi(&vmx->vcpu);

[PATCH 4.9 075/116] fsnotify: Fix possible use-after-free in inode iteration on umount

[Greg Kroah-Hartman]

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

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

From: Jan Kara <jack@suse.cz>

commit 5716863e0f8251d3360d4cbfc0e44e08007075df upstream.

fsnotify_unmount_inodes() plays complex tricks to pin next inode in the
sb->s_inodes list when iterating over all inodes. Furthermore the code has a
bug that if the current inode is the last on i_sb_list that does not have e.g.
I_FREEING set, then we leave next_i pointing to inode which may get removed
from the i_sb_list once we drop s_inode_list_lock thus resulting in
use-after-free issues (usually manifesting as infinite looping in
fsnotify_unmount_inodes()).

Fix the problem by keeping current inode pinned somewhat longer. Then we can
make the code much simpler and standard.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/notify/inode_mark.c |   45 +++++++++------------------------------------
 1 file changed, 9 insertions(+), 36 deletions(-)

--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -150,12 +150,10 @@ int fsnotify_add_inode_mark(struct fsnot
  */
 void fsnotify_unmount_inodes(struct super_block *sb)
 {
-	struct inode *inode, *next_i, *need_iput = NULL;
+	struct inode *inode, *iput_inode = NULL;
 
 	spin_lock(&sb->s_inode_list_lock);
-	list_for_each_entry_safe(inode, next_i, &sb->s_inodes, i_sb_list) {
-		struct inode *need_iput_tmp;
-
+	list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
 		/*
 		 * We cannot __iget() an inode in state I_FREEING,
 		 * I_WILL_FREE, or I_NEW which is fine because by that point
@@ -178,49 +176,24 @@ void fsnotify_unmount_inodes(struct supe
 			continue;
 		}
 
-		need_iput_tmp = need_iput;
-		need_iput = NULL;
-
-		/* In case fsnotify_inode_delete() drops a reference. */
-		if (inode != need_iput_tmp)
-			__iget(inode);
-		else
-			need_iput_tmp = NULL;
+		__iget(inode);
 		spin_unlock(&inode->i_lock);
-
-		/* In case the dropping of a reference would nuke next_i. */
-		while (&next_i->i_sb_list != &sb->s_inodes) {
-			spin_lock(&next_i->i_lock);
-			if (!(next_i->i_state & (I_FREEING | I_WILL_FREE)) &&
-						atomic_read(&next_i->i_count)) {
-				__iget(next_i);
-				need_iput = next_i;
-				spin_unlock(&next_i->i_lock);
-				break;
-			}
-			spin_unlock(&next_i->i_lock);
-			next_i = list_next_entry(next_i, i_sb_list);
-		}
-
-		/*
-		 * We can safely drop s_inode_list_lock here because either
-		 * we actually hold references on both inode and next_i or
-		 * end of list.  Also no new inodes will be added since the
-		 * umount has begun.
-		 */
 		spin_unlock(&sb->s_inode_list_lock);
 
-		if (need_iput_tmp)
-			iput(need_iput_tmp);
+		if (iput_inode)
+			iput(iput_inode);
 
 		/* for each watch, send FS_UNMOUNT and then remove it */
 		fsnotify(inode, FS_UNMOUNT, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
 
 		fsnotify_inode_delete(inode);
 
-		iput(inode);
+		iput_inode = inode;
 
 		spin_lock(&sb->s_inode_list_lock);
 	}
 	spin_unlock(&sb->s_inode_list_lock);
+
+	if (iput_inode)
+		iput(iput_inode);
 }

[PATCH 4.9 076/116] vsock/virtio: fix src/dst cid format

[Greg Kroah-Hartman]

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

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

From: Michael S. Tsirkin <mst@redhat.com>

commit f83f12d660d11718d3eed9d979ee03e83aa55544 upstream.

These fields are 64 bit, using le32_to_cpu and friends
on these will not do the right thing.
Fix this up.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/vmw_vsock/virtio_transport_common.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -606,9 +606,9 @@ static int virtio_transport_reset_no_soc
 		return 0;
 
 	pkt = virtio_transport_alloc_pkt(&info, 0,
-					 le32_to_cpu(pkt->hdr.dst_cid),
+					 le64_to_cpu(pkt->hdr.dst_cid),
 					 le32_to_cpu(pkt->hdr.dst_port),
-					 le32_to_cpu(pkt->hdr.src_cid),
+					 le64_to_cpu(pkt->hdr.src_cid),
 					 le32_to_cpu(pkt->hdr.src_port));
 	if (!pkt)
 		return -ENOMEM;
@@ -823,7 +823,7 @@ virtio_transport_send_response(struct vs
 	struct virtio_vsock_pkt_info info = {
 		.op = VIRTIO_VSOCK_OP_RESPONSE,
 		.type = VIRTIO_VSOCK_TYPE_STREAM,
-		.remote_cid = le32_to_cpu(pkt->hdr.src_cid),
+		.remote_cid = le64_to_cpu(pkt->hdr.src_cid),
 		.remote_port = le32_to_cpu(pkt->hdr.src_port),
 		.reply = true,
 	};
@@ -863,9 +863,9 @@ virtio_transport_recv_listen(struct sock
 	child->sk_state = SS_CONNECTED;
 
 	vchild = vsock_sk(child);
-	vsock_addr_init(&vchild->local_addr, le32_to_cpu(pkt->hdr.dst_cid),
+	vsock_addr_init(&vchild->local_addr, le64_to_cpu(pkt->hdr.dst_cid),
 			le32_to_cpu(pkt->hdr.dst_port));
-	vsock_addr_init(&vchild->remote_addr, le32_to_cpu(pkt->hdr.src_cid),
+	vsock_addr_init(&vchild->remote_addr, le64_to_cpu(pkt->hdr.src_cid),
 			le32_to_cpu(pkt->hdr.src_port));
 
 	vsock_insert_connected(vchild);
@@ -904,9 +904,9 @@ void virtio_transport_recv_pkt(struct vi
 	struct sock *sk;
 	bool space_available;
 
-	vsock_addr_init(&src, le32_to_cpu(pkt->hdr.src_cid),
+	vsock_addr_init(&src, le64_to_cpu(pkt->hdr.src_cid),
 			le32_to_cpu(pkt->hdr.src_port));
-	vsock_addr_init(&dst, le32_to_cpu(pkt->hdr.dst_cid),
+	vsock_addr_init(&dst, le64_to_cpu(pkt->hdr.dst_cid),
 			le32_to_cpu(pkt->hdr.dst_port));
 
 	trace_virtio_transport_recv_pkt(src.svm_cid, src.svm_port,

[PATCH 4.9 077/116] ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it

[Greg Kroah-Hartman]

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

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

From: Steven Rostedt (Red Hat) <rostedt@goodmis.org>

commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.

With new binutils, gcc may get smart with its optimization and change a jmp
from a 5 byte jump to a 2 byte one even though it was jumping to a global
function. But that global function existed within a 2 byte radius, and gcc
was able to optimize it. Unfortunately, that jump was also being modified
when function graph tracing begins. Since ftrace expected that jump to be 5
bytes, but it was only two, it overwrote code after the jump, causing a
crash.

This was fixed for x86_64 with commit 8329e818f149, with the same subject as
this commit, but nothing was done for x86_32.

Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
Reported-by: Colin Ian King <colin.king@canonical.com>
Tested-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/entry/entry_32.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -889,8 +889,8 @@ ftrace_graph_call:
 	jmp	ftrace_stub
 #endif
 
-.globl ftrace_stub
-ftrace_stub:
+/* This is weak to keep gas from relaxing the jumps */
+WEAK(ftrace_stub)
 	ret
 END(ftrace_caller)
 

[PATCH 4.9 078/116] platform/x86: asus-nb-wmi.c: Add X45U quirk

[Greg Kroah-Hartman]

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

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

From: Marcos Paulo de Souza <marcos.souza.org@gmail.com>

commit e74e259939275a5dd4e0d02845c694f421e249ad upstream.

Without this patch, the Asus X45U wireless card can't be turned
on (hard-blocked), but after a suspend/resume it just starts working.

Following this bug report[1], there are other cases like this one, but
this Asus is the only model that I can test.

[1] https://ubuntuforums.org/showthread.php?t=2181558

Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/platform/x86/asus-nb-wmi.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -175,6 +175,15 @@ static const struct dmi_system_id asus_q
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "ASUSTeK COMPUTER INC. X45U",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "X45U"),
+		},
+		.driver_data = &quirk_asus_wapf4,
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "ASUSTeK COMPUTER INC. X456UA",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),

[PATCH 4.9 079/116] x86/smpboot: Make logical package management more robust

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit 9d85eb9119f4eeeb48e87adfcd71f752655700e9 upstream.

The logical package management has several issues:

 - The APIC ids provided by ACPI are not required to be the same as the
   initial APIC id which can be retrieved by CPUID. The APIC ids provided
   by ACPI are those which are written by the BIOS into the APIC. The
   initial id is set by hardware and can not be changed. The hardware
   provided ids contain the real hardware package information.

   Especially AMD sets the effective APIC id different from the hardware id
   as they need to reserve space for the IOAPIC ids starting at id 0.

   As a consequence those machines trigger the currently active firmware
   bug printouts in dmesg, These are obviously wrong.

 - Virtual machines have their own interesting of enumerating APICs and
   packages which are not reliably covered by the current implementation.

The sizing of the mapping array has been tweaked to be generously large to
handle systems which provide a wrong core count when HT is disabled so the
whole magic which checks for space in the physical hotplug case is not
needed anymore.

Simplify the whole machinery and do the mapping when the CPU starts and the
CPUID derived physical package information is available. This solves the
observed problems on AMD machines and works for the virtualization issues
as well.

Remove the extra call from XEN cpu bringup code as it is not longer
required.

Fixes: d49597fd3bc7 ("x86/cpu: Deal with broken firmware (VMWare/XEN)")
Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: M. Vefa Bicakci <m.v.b@runbox.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Cc: Charles (Chas) Williams <ciwillia@brocade.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Alok Kataria <akataria@vmware.com>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1612121102260.3429@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kernel/apic/apic.c  |   15 ------------
 arch/x86/kernel/cpu/common.c |   24 ++++++--------------
 arch/x86/kernel/smpboot.c    |   51 ++++++++++++++++---------------------------
 arch/x86/xen/smp.c           |    6 -----
 4 files changed, 27 insertions(+), 69 deletions(-)

--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2159,21 +2159,6 @@ int __generic_processor_info(int apicid,
 	}
 
 	/*
-	 * This can happen on physical hotplug. The sanity check at boot time
-	 * is done from native_smp_prepare_cpus() after num_possible_cpus() is
-	 * established.
-	 */
-	if (topology_update_package_map(apicid, cpu) < 0) {
-		int thiscpu = max + disabled_cpus;
-
-		pr_warning("APIC: Package limit reached. Processor %d/0x%x ignored.\n",
-			   thiscpu, apicid);
-
-		disabled_cpus++;
-		return -ENOSPC;
-	}
-
-	/*
 	 * Validate version
 	 */
 	if (version == 0x0) {
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -979,29 +979,21 @@ static void x86_init_cache_qos(struct cp
 }
 
 /*
- * The physical to logical package id mapping is initialized from the
- * acpi/mptables information. Make sure that CPUID actually agrees with
- * that.
+ * Validate that ACPI/mptables have the same information about the
+ * effective APIC id and update the package map.
  */
-static void sanitize_package_id(struct cpuinfo_x86 *c)
+static void validate_apic_and_package_id(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_SMP
-	unsigned int pkg, apicid, cpu = smp_processor_id();
+	unsigned int apicid, cpu = smp_processor_id();
 
 	apicid = apic->cpu_present_to_apicid(cpu);
-	pkg = apicid >> boot_cpu_data.x86_coreid_bits;
 
-	if (apicid != c->initial_apicid) {
-		pr_err(FW_BUG "CPU%u: APIC id mismatch. Firmware: %x CPUID: %x\n",
+	if (apicid != c->apicid) {
+		pr_err(FW_BUG "CPU%u: APIC id mismatch. Firmware: %x APIC: %x\n",
 		       cpu, apicid, c->initial_apicid);
-		c->initial_apicid = apicid;
 	}
-	if (pkg != c->phys_proc_id) {
-		pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of %u\n",
-		       cpu, pkg, c->phys_proc_id);
-		c->phys_proc_id = pkg;
-	}
-	c->logical_proc_id = topology_phys_to_logical_pkg(pkg);
+	BUG_ON(topology_update_package_map(c->phys_proc_id, cpu));
 #else
 	c->logical_proc_id = 0;
 #endif
@@ -1132,7 +1124,6 @@ static void identify_cpu(struct cpuinfo_
 #ifdef CONFIG_NUMA
 	numa_add_cpu(smp_processor_id());
 #endif
-	sanitize_package_id(c);
 }
 
 /*
@@ -1188,6 +1179,7 @@ void identify_secondary_cpu(struct cpuin
 	enable_sep_cpu();
 #endif
 	mtrr_ap_init();
+	validate_apic_and_package_id(c);
 }
 
 struct msr_range {
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -104,7 +104,6 @@ static unsigned int max_physical_pkg_id
 unsigned int __max_logical_packages __read_mostly;
 EXPORT_SYMBOL(__max_logical_packages);
 static unsigned int logical_packages __read_mostly;
-static bool logical_packages_frozen __read_mostly;
 
 /* Maximum number of SMT threads on any online core */
 int __max_smt_threads __read_mostly;
@@ -263,9 +262,14 @@ static void notrace start_secondary(void
 	cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
 }
 
-int topology_update_package_map(unsigned int apicid, unsigned int cpu)
+/**
+ * topology_update_package_map - Update the physical to logical package map
+ * @pkg:	The physical package id as retrieved via CPUID
+ * @cpu:	The cpu for which this is updated
+ */
+int topology_update_package_map(unsigned int pkg, unsigned int cpu)
 {
-	unsigned int new, pkg = apicid >> boot_cpu_data.x86_coreid_bits;
+	unsigned int new;
 
 	/* Called from early boot ? */
 	if (!physical_package_map)
@@ -278,16 +282,17 @@ int topology_update_package_map(unsigned
 	if (test_and_set_bit(pkg, physical_package_map))
 		goto found;
 
-	if (logical_packages_frozen) {
-		physical_to_logical_pkg[pkg] = -1;
-		pr_warn("APIC(%x) Package %u exceeds logical package max\n",
-			apicid, pkg);
+	if (logical_packages >= __max_logical_packages) {
+		pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
+			logical_packages, cpu, __max_logical_packages);
 		return -ENOSPC;
 	}
 
 	new = logical_packages++;
-	pr_info("APIC(%x) Converting physical %u to logical package %u\n",
-		apicid, pkg, new);
+	if (new != pkg) {
+		pr_info("CPU %u Converting physical %u to logical package %u\n",
+			cpu, pkg, new);
+	}
 	physical_to_logical_pkg[pkg] = new;
 
 found:
@@ -308,9 +313,9 @@ int topology_phys_to_logical_pkg(unsigne
 }
 EXPORT_SYMBOL(topology_phys_to_logical_pkg);
 
-static void __init smp_init_package_map(void)
+static void __init smp_init_package_map(struct cpuinfo_x86 *c, unsigned int cpu)
 {
-	unsigned int ncpus, cpu;
+	unsigned int ncpus;
 	size_t size;
 
 	/*
@@ -355,27 +360,9 @@ static void __init smp_init_package_map(
 	size = BITS_TO_LONGS(max_physical_pkg_id) * sizeof(unsigned long);
 	physical_package_map = kzalloc(size, GFP_KERNEL);
 
-	for_each_present_cpu(cpu) {
-		unsigned int apicid = apic->cpu_present_to_apicid(cpu);
-
-		if (apicid == BAD_APICID || !apic->apic_id_valid(apicid))
-			continue;
-		if (!topology_update_package_map(apicid, cpu))
-			continue;
-		pr_warn("CPU %u APICId %x disabled\n", cpu, apicid);
-		per_cpu(x86_bios_cpu_apicid, cpu) = BAD_APICID;
-		set_cpu_possible(cpu, false);
-		set_cpu_present(cpu, false);
-	}
-
-	if (logical_packages > __max_logical_packages) {
-		pr_warn("Detected more packages (%u), then computed by BIOS data (%u).\n",
-			logical_packages, __max_logical_packages);
-		logical_packages_frozen = true;
-		__max_logical_packages  = logical_packages;
-	}
-
 	pr_info("Max logical packages: %u\n", __max_logical_packages);
+
+	topology_update_package_map(c->phys_proc_id, cpu);
 }
 
 void __init smp_store_boot_cpu_info(void)
@@ -385,7 +372,7 @@ void __init smp_store_boot_cpu_info(void
 
 	*c = boot_cpu_data;
 	c->cpu_index = id;
-	smp_init_package_map();
+	smp_init_package_map(c, id);
 }
 
 /*
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -87,12 +87,6 @@ static void cpu_bringup(void)
 	cpu_data(cpu).x86_max_cores = 1;
 	set_cpu_sibling_map(cpu);
 
-	/*
-	 * identify_cpu() may have set logical_pkg_id to -1 due
-	 * to incorrect phys_proc_id. Let's re-comupte it.
-	 */
-	topology_update_package_map(apic->cpu_present_to_apicid(cpu), cpu);
-
 	xen_setup_cpu_clockevents();
 
 	notify_cpu_starting(cpu);

[PATCH 4.9 080/116] fgraph: Handle a case where a tracer ignores set_graph_notrace

[Greg Kroah-Hartman]

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

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

From: Steven Rostedt (Red Hat) <rostedt@goodmis.org>

commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 upstream.

Both the wakeup and irqsoff tracers can use the function graph tracer when
the display-graph option is set. The problem is that they ignore the notrace
file, and record the entry of functions that would be ignored by the
function_graph tracer. This causes the trace->depth to be recorded into the
ring buffer. The set_graph_notrace uses a trick by adding a large negative
number to the trace->depth when a graph function is to be ignored.

On trace output, the graph function uses the depth to record a stack of
functions. But since the depth is negative, it accesses the array with a
negative number and causes an out of bounds access that can cause a kernel
oops or corrupt data.

Have the print functions handle cases where a tracer still records functions
even when they are in set_graph_notrace.

Also add warnings if the depth is below zero before accessing the array.

Note, the function graph logic will still prevent the return of these
functions from being recorded, which means that they will be left hanging
without a return. For example:

   # echo '*spin*' > set_graph_notrace
   # echo 1 > options/display-graph
   # echo wakeup > current_tracer
   # cat trace
   [...]
      _raw_spin_lock() {
        preempt_count_add() {
        do_raw_spin_lock() {
      update_rq_clock();

Where it should look like:

      _raw_spin_lock() {
        preempt_count_add();
        do_raw_spin_lock();
      }
      update_rq_clock();

Cc: Namhyung Kim <namhyung.kim@lge.com>
Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/trace/trace_functions_graph.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -842,6 +842,10 @@ print_graph_entry_leaf(struct trace_iter
 
 		cpu_data = per_cpu_ptr(data->cpu_data, cpu);
 
+		/* If a graph tracer ignored set_graph_notrace */
+		if (call->depth < -1)
+			call->depth += FTRACE_NOTRACE_DEPTH;
+
 		/*
 		 * Comments display at + 1 to depth. Since
 		 * this is a leaf function, keep the comments
@@ -850,7 +854,8 @@ print_graph_entry_leaf(struct trace_iter
 		cpu_data->depth = call->depth - 1;
 
 		/* No need to keep this function around for this depth */
-		if (call->depth < FTRACE_RETFUNC_DEPTH)
+		if (call->depth < FTRACE_RETFUNC_DEPTH &&
+		    !WARN_ON_ONCE(call->depth < 0))
 			cpu_data->enter_funcs[call->depth] = 0;
 	}
 
@@ -880,11 +885,16 @@ print_graph_entry_nested(struct trace_it
 		struct fgraph_cpu_data *cpu_data;
 		int cpu = iter->cpu;
 
+		/* If a graph tracer ignored set_graph_notrace */
+		if (call->depth < -1)
+			call->depth += FTRACE_NOTRACE_DEPTH;
+
 		cpu_data = per_cpu_ptr(data->cpu_data, cpu);
 		cpu_data->depth = call->depth;
 
 		/* Save this function pointer to see if the exit matches */
-		if (call->depth < FTRACE_RETFUNC_DEPTH)
+		if (call->depth < FTRACE_RETFUNC_DEPTH &&
+		    !WARN_ON_ONCE(call->depth < 0))
 			cpu_data->enter_funcs[call->depth] = call->func;
 	}
 
@@ -1114,7 +1124,8 @@ print_graph_return(struct ftrace_graph_r
 		 */
 		cpu_data->depth = trace->depth - 1;
 
-		if (trace->depth < FTRACE_RETFUNC_DEPTH) {
+		if (trace->depth < FTRACE_RETFUNC_DEPTH &&
+		    !WARN_ON_ONCE(trace->depth < 0)) {
 			if (cpu_data->enter_funcs[trace->depth] != trace->func)
 				func_match = 0;
 			cpu_data->enter_funcs[trace->depth] = 0;

[PATCH 4.9 081/116] IB/mad: Fix an array index check

[Greg Kroah-Hartman]

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

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

From: Bart Van Assche <bart.vanassche@sandisk.com>

commit 2fe2f378dd45847d2643638c07a7658822087836 upstream.

The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
(80) elements. Hence compare the array index with that value instead
of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity
reports the following:

Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127).

Fixes: commit b7ab0b19a85f ("IB/mad: Verify mgmt class in received MADs")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Reviewed-by: Hal Rosenstock <hal@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/core/mad.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1746,7 +1746,7 @@ find_mad_agent(struct ib_mad_port_privat
 			if (!class)
 				goto out;
 			if (convert_mgmt_class(mad_hdr->mgmt_class) >=
-			    IB_MGMT_MAX_METHODS)
+			    ARRAY_SIZE(class->method_table))
 				goto out;
 			method = class->method_table[convert_mgmt_class(
 							mad_hdr->mgmt_class)];

[PATCH 4.9 082/116] IPoIB: Avoid reading an uninitialized member variable

[Greg Kroah-Hartman]

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

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

From: Bart Van Assche <bart.vanassche@sandisk.com>

commit 11b642b84e8c43e8597de031678d15c08dd057bc upstream.

This patch avoids that Coverity reports the following:

    Using uninitialized value port_attr.state when calling printk

Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -575,8 +575,11 @@ void ipoib_mcast_join_task(struct work_s
 	if (!test_bit(IPOIB_FLAG_OPER_UP, &priv->flags))
 		return;
 
-	if (ib_query_port(priv->ca, priv->port, &port_attr) ||
-	    port_attr.state != IB_PORT_ACTIVE) {
+	if (ib_query_port(priv->ca, priv->port, &port_attr)) {
+		ipoib_dbg(priv, "ib_query_port() failed\n");
+		return;
+	}
+	if (port_attr.state != IB_PORT_ACTIVE) {
 		ipoib_dbg(priv, "port state is not ACTIVE (state = %d) suspending join task\n",
 			  port_attr.state);
 		return;

[PATCH 4.9 083/116] IB/multicast: Check ib_find_pkey() return value

[Greg Kroah-Hartman]

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

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

From: Bart Van Assche <bart.vanassche@sandisk.com>

commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 upstream.

This patch avoids that Coverity complains about not checking the
ib_find_pkey() return value.

Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/core/multicast.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/infiniband/core/multicast.c
+++ b/drivers/infiniband/core/multicast.c
@@ -518,8 +518,11 @@ static void join_handler(int status, str
 		process_join_error(group, status);
 	else {
 		int mgids_changed, is_mgid0;
-		ib_find_pkey(group->port->dev->device, group->port->port_num,
-			     be16_to_cpu(rec->pkey), &pkey_index);
+
+		if (ib_find_pkey(group->port->dev->device,
+				 group->port->port_num, be16_to_cpu(rec->pkey),
+				 &pkey_index))
+			pkey_index = MCAST_INVALID_PKEY_INDEX;
 
 		spin_lock_irq(&group->port->lock);
 		if (group->state == MCAST_BUSY &&

[PATCH 4.9 084/116] IB/rxe: Fix a memory leak in rxe_qp_cleanup()

[Greg Kroah-Hartman]

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

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

From: Bart Van Assche <bart.vanassche@sandisk.com>

commit e259934d4df7f99f2a5c2c4f074f6a55bd4b1722 upstream.

A socket is associated with every QP by the rxe driver but sock_release()
is never called. Add a call to sock_release() in rxe_qp_cleanup().

Fixes: commit 8700e3e7c48A5 ("Add Soft RoCE driver")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Moni Shoua <monis@mellanox.com>
Cc: Kamal Heib <kamalh@mellanox.com>
Cc: Amir Vadai <amirv@mellanox.com>
Cc: Haggai Eran <haggaie@mellanox.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/sw/rxe/rxe_qp.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/infiniband/sw/rxe/rxe_qp.c
+++ b/drivers/infiniband/sw/rxe/rxe_qp.c
@@ -855,4 +855,5 @@ void rxe_qp_cleanup(void *arg)
 	free_rd_atomic_resources(qp);
 
 	kernel_sock_shutdown(qp->sk, SHUT_RDWR);
+	sock_release(qp->sk);
 }

[PATCH 4.9 085/116] IB/cma: Fix a race condition in iboe_addr_get_sgid()

[Greg Kroah-Hartman]

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

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

From: Bart Van Assche <bart.vanassche@sandisk.com>

commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.

Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.

Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Roland Dreier <roland@purestorage.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/rdma/ib_addr.h |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -205,10 +205,12 @@ static inline void iboe_addr_get_sgid(st
 
 	dev = dev_get_by_index(&init_net, dev_addr->bound_dev_if);
 	if (dev) {
-		ip4 = (struct in_device *)dev->ip_ptr;
-		if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
+		ip4 = in_dev_get(dev);
+		if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address) {
 			ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
 					       (struct in6_addr *)gid);
+			in_dev_put(ip4);
+		}
 		dev_put(dev);
 	}
 }

[PATCH 4.9 086/116] [media] mn88472: fix chip id check on probe

[Greg Kroah-Hartman]

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

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

From: Antti Palosaari <crope@iki.fi>

commit 365fe4e0ce218dc5ad10df17b150a366b6015499 upstream.

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 94d0eaa41987 ("[media] mn88472: move out of staging to media")

Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/dvb-frontends/mn88472.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

--- a/drivers/media/dvb-frontends/mn88472.c
+++ b/drivers/media/dvb-frontends/mn88472.c
@@ -488,18 +488,6 @@ static int mn88472_probe(struct i2c_clie
 		goto err_kfree;
 	}
 
-	/* Check demod answers with correct chip id */
-	ret = regmap_read(dev->regmap[0], 0xff, &utmp);
-	if (ret)
-		goto err_regmap_0_regmap_exit;
-
-	dev_dbg(&client->dev, "chip id=%02x\n", utmp);
-
-	if (utmp != 0x02) {
-		ret = -ENODEV;
-		goto err_regmap_0_regmap_exit;
-	}
-
 	/*
 	 * Chip has three I2C addresses for different register banks. Used
 	 * addresses are 0x18, 0x1a and 0x1c. We register two dummy clients,
@@ -536,6 +524,18 @@ static int mn88472_probe(struct i2c_clie
 	}
 	i2c_set_clientdata(dev->client[2], dev);
 
+	/* Check demod answers with correct chip id */
+	ret = regmap_read(dev->regmap[2], 0xff, &utmp);
+	if (ret)
+		goto err_regmap_2_regmap_exit;
+
+	dev_dbg(&client->dev, "chip id=%02x\n", utmp);
+
+	if (utmp != 0x02) {
+		ret = -ENODEV;
+		goto err_regmap_2_regmap_exit;
+	}
+
 	/* Sleep because chip is active by default */
 	ret = regmap_write(dev->regmap[2], 0x05, 0x3e);
 	if (ret)

[PATCH 4.9 087/116] [media] mn88473: fix chip id check on probe

[Greg Kroah-Hartman]

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

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

From: Antti Palosaari <crope@iki.fi>

commit d930b5b5bf122a61952cfebabb1e618682a2631a upstream.

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 7908fad99a6c ("[media] mn88473: finalize driver")

Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/dvb-frontends/mn88473.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

--- a/drivers/media/dvb-frontends/mn88473.c
+++ b/drivers/media/dvb-frontends/mn88473.c
@@ -485,18 +485,6 @@ static int mn88473_probe(struct i2c_clie
 		goto err_kfree;
 	}
 
-	/* Check demod answers with correct chip id */
-	ret = regmap_read(dev->regmap[0], 0xff, &uitmp);
-	if (ret)
-		goto err_regmap_0_regmap_exit;
-
-	dev_dbg(&client->dev, "chip id=%02x\n", uitmp);
-
-	if (uitmp != 0x03) {
-		ret = -ENODEV;
-		goto err_regmap_0_regmap_exit;
-	}
-
 	/*
 	 * Chip has three I2C addresses for different register banks. Used
 	 * addresses are 0x18, 0x1a and 0x1c. We register two dummy clients,
@@ -533,6 +521,18 @@ static int mn88473_probe(struct i2c_clie
 	}
 	i2c_set_clientdata(dev->client[2], dev);
 
+	/* Check demod answers with correct chip id */
+	ret = regmap_read(dev->regmap[2], 0xff, &uitmp);
+	if (ret)
+		goto err_regmap_2_regmap_exit;
+
+	dev_dbg(&client->dev, "chip id=%02x\n", uitmp);
+
+	if (uitmp != 0x03) {
+		ret = -ENODEV;
+		goto err_regmap_2_regmap_exit;
+	}
+
 	/* Sleep because chip is active by default */
 	ret = regmap_write(dev->regmap[2], 0x05, 0x3e);
 	if (ret)

[PATCH 4.9 088/116] [media] s5p-mfc: fix failure path of s5p_mfc_alloc_memdev()

[Greg Kroah-Hartman]

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

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

From: Marek Szyprowski <m.szyprowski@samsung.com>

commit 3467c9a7e7f9209a9ecd8f9db65b04a323a13932 upstream.

s5p_mfc_alloc_memdev() function lacks proper releasing
of allocated device in case of reserved memory initialization
failure. This results in NULL pointer dereference:

[    2.828457] Unable to handle kernel NULL pointer dereference at virtual address 00000001
[    2.835089] pgd = c0004000
[    2.837752] [00000001] *pgd=00000000
[    2.844696] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    2.848680] Modules linked in:
[    2.851722] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00002-gafa1b97 #878
[    2.859357] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    2.865433] task: ef080000 task.stack: ef06c000
[    2.869952] PC is at strcmp+0x0/0x30
[    2.873508] LR is at platform_match+0x84/0xac
[    2.877847] pc : [<c032621c>]    lr : [<c03f65e8>]    psr: 20000013
[    2.877847] sp : ef06dea0  ip : 00000000  fp : 00000000
[    2.889303] r10: 00000000  r9 : c0b34848  r8 : c0b1e968
[    2.894511] r7 : 00000000  r6 : 00000001  r5 : c086e7fc  r4 : eeb8e010
[    2.901021] r3 : 0000006d  r2 : 00000000  r1 : c086e7fc  r0 : 00000001
[    2.907533] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    2.914649] Control: 10c5387d  Table: 4000404a  DAC: 00000051
[    2.920378] Process swapper/0 (pid: 1, stack limit = 0xef06c210)
[    2.926367] Stack: (0xef06dea0 to 0xef06e000)
[    2.930711] dea0: eeb8e010 c0c2d91c c03f4a6c c03f4a8c 00000000 c0c2d91c c03f4a6c c03f2fc8
[    2.938870] dec0: ef003274 ef10c4c0 c0c2d91c ef10cc80 c0c21270 c03f3fa4 c09c1be8 c0c2d91c
[    2.947028] dee0: 00000006 c0c2d91c 00000006 c0b3483c c0c47000 c03f5314 c0c2d908 c0b5fed8
[    2.955188] df00: 00000006 c010178c 60000013 c0a4ef14 00000000 c06feaa0 ef080000 60000013
[    2.963347] df20: 00000000 c0c095c8 efffca76 c0816b8c 000000d5 c0134098 c0b34848 c09d6cdc
[    2.971506] df40: c0a4de70 00000000 00000006 00000006 c0c09568 efffca40 c0b5fed8 00000006
[    2.979665] df60: c0b3483c c0c47000 000000d5 c0b34848 c0b005a4 c0b00d84 00000006 00000006
[    2.987824] df80: 00000000 c0b005a4 00000000 c06fb4d8 00000000 00000000 00000000 00000000
[    2.995983] dfa0: 00000000 c06fb4e0 00000000 c01079b8 00000000 00000000 00000000 00000000
[    3.004142] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    3.012302] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[    3.020469] [<c032621c>] (strcmp) from [<c03f65e8>] (platform_match+0x84/0xac)
[    3.027672] [<c03f65e8>] (platform_match) from [<c03f4a8c>] (__driver_attach+0x20/0xb0)
[    3.035654] [<c03f4a8c>] (__driver_attach) from [<c03f2fc8>] (bus_for_each_dev+0x54/0x88)
[    3.043812] [<c03f2fc8>] (bus_for_each_dev) from [<c03f3fa4>] (bus_add_driver+0xe8/0x1f4)
[    3.051971] [<c03f3fa4>] (bus_add_driver) from [<c03f5314>] (driver_register+0x78/0xf4)
[    3.059958] [<c03f5314>] (driver_register) from [<c010178c>] (do_one_initcall+0x3c/0x16c)
[    3.068123] [<c010178c>] (do_one_initcall) from [<c0b00d84>] (kernel_init_freeable+0x120/0x1ec)
[    3.076802] [<c0b00d84>] (kernel_init_freeable) from [<c06fb4e0>] (kernel_init+0x8/0x118)
[    3.084958] [<c06fb4e0>] (kernel_init) from [<c01079b8>] (ret_from_fork+0x14/0x3c)
[    3.092506] Code: 1afffffb e12fff1e e1a03000 eafffff7 (e4d03001)
[    3.098618] ---[ end trace 511bf9d750810709 ]---
[    3.103207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

This patch fixes this issue.

Fixes: c79667dd93b084fe412bcfe7fbf0ba43f7dec520 ("media: s5p-mfc: replace custom
	reserved memory handling code with generic one")

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1082,6 +1082,7 @@ static struct device *s5p_mfc_alloc_memd
 							 idx);
 		if (ret == 0)
 			return child;
+		device_del(child);
 	}
 
 	put_device(child);

[PATCH 4.9 089/116] [media] media: solo6x10: fix lockup by avoiding delayed register write

[Greg Kroah-Hartman]

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

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

From: Andrey Utkin <andrey.utkin@corp.bluecherry.net>

commit 5fc4b067ec082c3127e0156f800769b7e0dce078 upstream.

This fixes a lockup at device probing which happens on some solo6010
hardware samples. This is a regression introduced by commit e1ceb25a1569
("[media] SOLO6x10: remove unneeded register locking and barriers")

The observed lockup happens in solo_set_motion_threshold() called from
solo_motion_config().

This extra "flushing" is not fundamentally needed for every write, but
apparently the code in driver assumes such behaviour at last in some
places.

Actual fix was proposed by Hans Verkuil.

Fixes: e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers")

Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/pci/solo6x10/solo6x10.h |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/media/pci/solo6x10/solo6x10.h
+++ b/drivers/media/pci/solo6x10/solo6x10.h
@@ -284,7 +284,10 @@ static inline u32 solo_reg_read(struct s
 static inline void solo_reg_write(struct solo_dev *solo_dev, int reg,
 				  u32 data)
 {
+	u16 val;
+
 	writel(data, solo_dev->reg_base + reg);
+	pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
 }
 
 static inline void solo_irq_on(struct solo_dev *dev, u32 mask)

[PATCH 4.9 090/116] [media] v4l: tvp5150: Add missing break in set control handler

[Greg Kroah-Hartman]

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

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

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

commit d183e4efcae8d88a2f252e546978658ca6d273cc upstream.

A break is missing resulting in the hue control enabling or disabling
the decode completely. Fix it.

Fixes: c43875f66140 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control")

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/i2c/tvp5150.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -815,6 +815,7 @@ static int tvp5150_s_ctrl(struct v4l2_ct
 		return 0;
 	case V4L2_CID_HUE:
 		tvp5150_write(sd, TVP5150_HUE_CTL, ctrl->val);
+		break;
 	case V4L2_CID_TEST_PATTERN:
 		decoder->enable = ctrl->val ? false : true;
 		tvp5150_selmux(sd);

[PATCH 4.9 091/116] Input: drv260x - fix input devices parent assignment

[Greg Kroah-Hartman]

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

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

From: Jingkui Wang <jkwang@google.com>

commit 5a8a6b89c15766446d845671d574a9243b6d8786 upstream.

We were assigning I2C bus controller instead of client as parent device.
Besides being logically wrong, it messed up with devm handling of input
device. As a result we were leaving input device and event node behind
after rmmod-ing the driver, which lead to a kernel oops if one were to
access the event node later.

Let's remove the assignment and rely on devm_input_allocate_device() to
set it up properly for us.

Signed-off-by: Jingkui Wang <jkwang@google.com>
Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/misc/drv260x.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -592,7 +592,6 @@ static int drv260x_probe(struct i2c_clie
 	}
 
 	haptics->input_dev->name = "drv260x:haptics";
-	haptics->input_dev->dev.parent = client->dev.parent;
 	haptics->input_dev->close = drv260x_close;
 	input_set_drvdata(haptics->input_dev, haptics);
 	input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);

[PATCH 4.9 092/116] bad_inode: add missing i_op initializers

[Greg Kroah-Hartman]

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

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

From: Miklos Szeredi <mszeredi@redhat.com>

commit 3f9ca75516a7e581ff803f751a869c1da5ae5fa5 upstream.

New inode operations were forgotten to be added to bad_inode.  Most of the
time the op is checked for NULL before being called but marking the inode
bad and the check can race (very unlikely).

However in case of ->get_link() only DCACHE_SYMLINK_TYPE is checked before
calling the op, so there's no race and will definitely oops when trying to
follow links on such a beast.

Also remove comments about extinct ops.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/bad_inode.c |   55 +++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 51 insertions(+), 4 deletions(-)

--- a/fs/bad_inode.c
+++ b/fs/bad_inode.c
@@ -106,6 +106,50 @@ static ssize_t bad_inode_listxattr(struc
 	return -EIO;
 }
 
+static const char *bad_inode_get_link(struct dentry *dentry,
+				      struct inode *inode,
+				      struct delayed_call *done)
+{
+	return ERR_PTR(-EIO);
+}
+
+static struct posix_acl *bad_inode_get_acl(struct inode *inode, int type)
+{
+	return ERR_PTR(-EIO);
+}
+
+static int bad_inode_fiemap(struct inode *inode,
+			    struct fiemap_extent_info *fieinfo, u64 start,
+			    u64 len)
+{
+	return -EIO;
+}
+
+static int bad_inode_update_time(struct inode *inode, struct timespec *time,
+				 int flags)
+{
+	return -EIO;
+}
+
+static int bad_inode_atomic_open(struct inode *inode, struct dentry *dentry,
+				 struct file *file, unsigned int open_flag,
+				 umode_t create_mode, int *opened)
+{
+	return -EIO;
+}
+
+static int bad_inode_tmpfile(struct inode *inode, struct dentry *dentry,
+			     umode_t mode)
+{
+	return -EIO;
+}
+
+static int bad_inode_set_acl(struct inode *inode, struct posix_acl *acl,
+			     int type)
+{
+	return -EIO;
+}
+
 static const struct inode_operations bad_inode_ops =
 {
 	.create		= bad_inode_create,
@@ -118,14 +162,17 @@ static const struct inode_operations bad
 	.mknod		= bad_inode_mknod,
 	.rename		= bad_inode_rename2,
 	.readlink	= bad_inode_readlink,
-	/* follow_link must be no-op, otherwise unmounting this inode
-	   won't work */
-	/* put_link returns void */
-	/* truncate returns void */
 	.permission	= bad_inode_permission,
 	.getattr	= bad_inode_getattr,
 	.setattr	= bad_inode_setattr,
 	.listxattr	= bad_inode_listxattr,
+	.get_link	= bad_inode_get_link,
+	.get_acl	= bad_inode_get_acl,
+	.fiemap		= bad_inode_fiemap,
+	.update_time	= bad_inode_update_time,
+	.atomic_open	= bad_inode_atomic_open,
+	.tmpfile	= bad_inode_tmpfile,
+	.set_acl	= bad_inode_set_acl,
 };
 
 

[PATCH 4.9 093/116] i40iw: Use correct src address in memcpy to rdma stats counters

[Greg Kroah-Hartman]

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

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

From: Shiraz Saleem <shiraz.saleem@intel.com>

commit 91c42b72f8e8b45961ff05a05009b644e6316ca2 upstream.

hw_stats is a pointer to i40_iw_dev_stats struct in i40iw_get_hw_stats().
Use hw_stats and not &hw_stats in the memcpy to copy the i40iw device stats
data into rdma_hw_stats counters.

Fixes: b40f4757daa1 ("IB/core: Make device counter infrastructure dynamic")

Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
Signed-off-by: Faisal Latif <faisal.latif@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/infiniband/hw/i40iw/i40iw_verbs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -2501,7 +2501,7 @@ static int i40iw_get_hw_stats(struct ib_
 			return -ENOSYS;
 	}
 
-	memcpy(&stats->value[0], &hw_stats, sizeof(*hw_stats));
+	memcpy(&stats->value[0], hw_stats, sizeof(*hw_stats));
 
 	return stats->num_counters;
 }

[PATCH 4.9 094/116] PCI: Check for PME in targeted sleep state

[Greg Kroah-Hartman]

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

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

From: Alan Stern <stern@rowland.harvard.edu>

commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil <flyos@mailoo.org>
Tested-by: Pierre de Villemereuil <flyos@mailoo.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pci/pci.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2106,6 +2106,10 @@ bool pci_dev_run_wake(struct pci_dev *de
 	if (!dev->pme_support)
 		return false;
 
+	/* PME-capable in principle, but not from the intended sleep state */
+	if (!pci_pme_capable(dev, pci_target_state(dev)))
+		return false;
+
 	while (bus->parent) {
 		struct pci_dev *bridge = bus->self;
 

[PATCH 4.9 095/116] libceph: verify authorize reply on connect

[Greg Kroah-Hartman]

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

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

From: Ilya Dryomov <idryomov@gmail.com>

commit 5c056fdc5b474329037f2aa18401bd73033e0ce0 upstream.

After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b),
the client gets back a ceph_x_authorize_reply, which it is supposed to
verify to ensure the authenticity and protect against replay attacks.
The code for doing this is there (ceph_x_verify_authorizer_reply(),
ceph_auth_verify_authorizer_reply() + plumbing), but it is never
invoked by the the messenger.

AFAICT this goes back to 2009, when ceph authentication protocols
support was added to the kernel client in 4e7a5dcd1bba ("ceph:
negotiate authentication protocol; implement AUTH_NONE protocol").

The second param of ceph_connection_operations::verify_authorizer_reply
is unused all the way down.  Pass 0 to facilitate backporting, and kill
it in the next commit.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/ceph/messenger.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -2027,6 +2027,19 @@ static int process_connect(struct ceph_c
 
 	dout("process_connect on %p tag %d\n", con, (int)con->in_tag);
 
+	if (con->auth_reply_buf) {
+		/*
+		 * Any connection that defines ->get_authorizer()
+		 * should also define ->verify_authorizer_reply().
+		 * See get_connect_authorizer().
+		 */
+		ret = con->ops->verify_authorizer_reply(con, 0);
+		if (ret < 0) {
+			con->error_msg = "bad authorize reply";
+			return ret;
+		}
+	}
+
 	switch (con->in_reply.tag) {
 	case CEPH_MSGR_TAG_FEATURES:
 		pr_err("%s%lld %s feature set mismatch,"

[PATCH 4.9 096/116] nfs_write_end(): fix handling of short copies

[Greg Kroah-Hartman]

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

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

From: Al Viro <viro@zeniv.linux.org.uk>

commit c0cf3ef5e0f47e385920450b245d22bead93e7ad upstream.

What matters when deciding if we should make a page uptodate is
not how much we _wanted_ to copy, but how much we actually have
copied.  As it is, on architectures that do not zero tail on
short copy we can leave uninitialized data in page marked uptodate.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/file.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -374,7 +374,7 @@ static int nfs_write_end(struct file *fi
 	 */
 	if (!PageUptodate(page)) {
 		unsigned pglen = nfs_page_length(page);
-		unsigned end = offset + len;
+		unsigned end = offset + copied;
 
 		if (pglen == 0) {
 			zero_user_segments(page, 0, offset,

[PATCH 4.9 097/116] pNFS: On error, do not send LAYOUTGET until the LAYOUTRETURN has completed

[Greg Kroah-Hartman]

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

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

From: Trond Myklebust <trond.myklebust@primarydata.com>

commit 6604b203fb6394ed1f24c21bfa3c207e5ae8e461 upstream.

If there is an I/O error, we should not call LAYOUTGET until the
LAYOUTRETURN that reports the error is complete.

Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/pnfs.c |    6 +++++-
 fs/nfs/pnfs.h |    1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -944,6 +944,7 @@ static void pnfs_clear_layoutcommit(stru
 void pnfs_clear_layoutreturn_waitbit(struct pnfs_layout_hdr *lo)
 {
 	clear_bit_unlock(NFS_LAYOUT_RETURN, &lo->plh_flags);
+	clear_bit(NFS_LAYOUT_RETURN_LOCK, &lo->plh_flags);
 	smp_mb__after_atomic();
 	wake_up_bit(&lo->plh_flags, NFS_LAYOUT_RETURN);
 	rpc_wake_up(&NFS_SERVER(lo->plh_inode)->roc_rpcwaitq);
@@ -957,8 +958,9 @@ pnfs_prepare_layoutreturn(struct pnfs_la
 	/* Serialise LAYOUTGET/LAYOUTRETURN */
 	if (atomic_read(&lo->plh_outstanding) != 0)
 		return false;
-	if (test_and_set_bit(NFS_LAYOUT_RETURN, &lo->plh_flags))
+	if (test_and_set_bit(NFS_LAYOUT_RETURN_LOCK, &lo->plh_flags))
 		return false;
+	set_bit(NFS_LAYOUT_RETURN, &lo->plh_flags);
 	pnfs_get_layout_hdr(lo);
 	if (test_bit(NFS_LAYOUT_RETURN_REQUESTED, &lo->plh_flags)) {
 		if (stateid != NULL) {
@@ -1950,6 +1952,8 @@ void pnfs_error_mark_layout_for_return(s
 
 	spin_lock(&inode->i_lock);
 	pnfs_set_plh_return_info(lo, range.iomode, 0);
+	/* Block LAYOUTGET */
+	set_bit(NFS_LAYOUT_RETURN, &lo->plh_flags);
 	/*
 	 * mark all matching lsegs so that we are sure to have no live
 	 * segments at hand when sending layoutreturn. See pnfs_put_lseg()
--- a/fs/nfs/pnfs.h
+++ b/fs/nfs/pnfs.h
@@ -96,6 +96,7 @@ enum {
 	NFS_LAYOUT_RW_FAILED,		/* get rw layout failed stop trying */
 	NFS_LAYOUT_BULK_RECALL,		/* bulk recall affecting layout */
 	NFS_LAYOUT_RETURN,		/* layoutreturn in progress */
+	NFS_LAYOUT_RETURN_LOCK,		/* Serialise layoutreturn */
 	NFS_LAYOUT_RETURN_REQUESTED,	/* Return this layout ASAP */
 	NFS_LAYOUT_INVALID_STID,	/* layout stateid id is invalid */
 	NFS_LAYOUT_FIRST_LAYOUTGET,	/* Serialize first layoutget */

[PATCH 4.9 098/116] pNFS: Dont clear the layout stateid if a layout return is outstanding

[Greg Kroah-Hartman]

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

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

From: Trond Myklebust <trond.myklebust@primarydata.com>

commit 7b650994ab07434ae58a247dc9ac87d2488ca75c upstream.

If we no longer hold any layout segments, we're normally expected to
consider the layout stateid to be invalid. However we cannot assume this
if we're about to, or in the process of sending a layoutreturn.

Fixes: 334a8f37115b ("pNFS: Don't forget the layout stateid if...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/pnfs.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -411,7 +411,9 @@ pnfs_layout_remove_lseg(struct pnfs_layo
 	list_del_init(&lseg->pls_list);
 	/* Matched by pnfs_get_layout_hdr in pnfs_layout_insert_lseg */
 	atomic_dec(&lo->plh_refcount);
-	if (list_empty(&lo->plh_segs)) {
+	if (list_empty(&lo->plh_segs) &&
+	    !test_bit(NFS_LAYOUT_RETURN_REQUESTED, &lo->plh_flags) &&
+	    !test_bit(NFS_LAYOUT_RETURN, &lo->plh_flags)) {
 		if (atomic_read(&lo->plh_outstanding) == 0)
 			set_bit(NFS_LAYOUT_INVALID_STID, &lo->plh_flags);
 		clear_bit(NFS_LAYOUT_BULK_RECALL, &lo->plh_flags);

[PATCH 4.9 099/116] pNFS: Clear NFS_LAYOUT_RETURN_REQUESTED when invalidating the layout stateid

[Greg Kroah-Hartman]

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

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

From: Trond Myklebust <trond.myklebust@primarydata.com>

commit ae5a459d5f65c3e83f3e14068dde5fb9c9d81807 upstream.

We must ensure that we don't schedule a layoutreturn if the layout stateid
has been marked as invalid.

Fixes: 2a59a0411671e ("pNFS: Fix pnfs_set_layout_stateid() to clear...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/pnfs.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -299,6 +299,14 @@ pnfs_put_layout_hdr(struct pnfs_layout_h
 	}
 }
 
+static void
+pnfs_clear_layoutreturn_info(struct pnfs_layout_hdr *lo)
+{
+	lo->plh_return_iomode = 0;
+	lo->plh_return_seq = 0;
+	clear_bit(NFS_LAYOUT_RETURN_REQUESTED, &lo->plh_flags);
+}
+
 /*
  * Mark a pnfs_layout_hdr and all associated layout segments as invalid
  *
@@ -317,6 +325,7 @@ pnfs_mark_layout_stateid_invalid(struct
 	};
 
 	set_bit(NFS_LAYOUT_INVALID_STID, &lo->plh_flags);
+	pnfs_clear_layoutreturn_info(lo);
 	return pnfs_mark_matching_lsegs_invalid(lo, lseg_list, &range, 0);
 }
 
@@ -818,14 +827,6 @@ pnfs_destroy_all_layouts(struct nfs_clie
 	pnfs_destroy_layouts_byclid(clp, false);
 }
 
-static void
-pnfs_clear_layoutreturn_info(struct pnfs_layout_hdr *lo)
-{
-	lo->plh_return_iomode = 0;
-	lo->plh_return_seq = 0;
-	clear_bit(NFS_LAYOUT_RETURN_REQUESTED, &lo->plh_flags);
-}
-
 /* update lo->plh_stateid with new if is more recent */
 void
 pnfs_set_layout_stateid(struct pnfs_layout_hdr *lo, const nfs4_stateid *new,

[PATCH 4.9 100/116] pNFS: Fix a deadlock between read resends and layoutreturn

[Greg Kroah-Hartman]

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

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

From: Trond Myklebust <trond.myklebust@primarydata.com>

commit 54e4a0dfa25d9365c4e80a639e80d9213eb6edbe upstream.

We must not call nfs_pageio_init_read() on a new nfs_pageio_descriptor
while holding a reference to a layout segment, as that can deadlock
pnfs_update_layout().

Fixes: d67ae825a59d6 ("pnfs/flexfiles: Add the FlexFile Layout Driver")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/flexfilelayout/flexfilelayout.c |    4 ++++
 fs/nfs/pnfs.c                          |    4 ++++
 2 files changed, 8 insertions(+)

--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -28,6 +28,9 @@
 
 static struct group_info	*ff_zero_group;
 
+static void ff_layout_read_record_layoutstats_done(struct rpc_task *task,
+		struct nfs_pgio_header *hdr);
+
 static struct pnfs_layout_hdr *
 ff_layout_alloc_layout_hdr(struct inode *inode, gfp_t gfp_flags)
 {
@@ -1293,6 +1296,7 @@ static int ff_layout_read_done_cb(struct
 					hdr->pgio_mirror_idx + 1,
 					&hdr->pgio_mirror_idx))
 			goto out_eagain;
+		ff_layout_read_record_layoutstats_done(task, hdr);
 		pnfs_read_resend_pnfs(hdr);
 		return task->tk_status;
 	case -NFS4ERR_RESET_TO_MDS:
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2293,6 +2293,10 @@ void pnfs_read_resend_pnfs(struct nfs_pg
 	struct nfs_pageio_descriptor pgio;
 
 	if (!test_and_set_bit(NFS_IOHDR_REDO, &hdr->flags)) {
+		/* Prevent deadlocks with layoutreturn! */
+		pnfs_put_lseg(hdr->lseg);
+		hdr->lseg = NULL;
+
 		nfs_pageio_init_read(&pgio, hdr->inode, false,
 					hdr->completion_ops);
 		hdr->task.tk_status = nfs_pageio_resend(&pgio, hdr);

[PATCH 4.9 101/116] SUNRPC: fix refcounting problems with auth_gss messages.

[Greg Kroah-Hartman]

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

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

From: NeilBrown <neilb@suse.com>

commit 1cded9d2974fe4fe339fc0ccd6638b80d465ab2c upstream.

There are two problems with refcounting of auth_gss messages.

First, the reference on the pipe->pipe list (taken by a call
to rpc_queue_upcall()) is not counted.  It seems to be
assumed that a message in pipe->pipe will always also be in
pipe->in_downcall, where it is correctly reference counted.

However there is no guaranty of this.  I have a report of a
NULL dereferences in rpc_pipe_read() which suggests a msg
that has been freed is still on the pipe->pipe list.

One way I imagine this might happen is:
- message is queued for uid=U and auth->service=S1
- rpc.gssd reads this message and starts processing.
  This removes the message from pipe->pipe
- message is queued for uid=U and auth->service=S2
- rpc.gssd replies to the first message. gss_pipe_downcall()
  calls __gss_find_upcall(pipe, U, NULL) and it finds the
  *second* message, as new messages are placed at the head
  of ->in_downcall, and the service type is not checked.
- This second message is removed from ->in_downcall and freed
  by gss_release_msg() (even though it is still on pipe->pipe)
- rpc.gssd tries to read another message, and dereferences a pointer
  to this message that has just been freed.

I fix this by incrementing the reference count before calling
rpc_queue_upcall(), and decrementing it if that fails, or normally in
gss_pipe_destroy_msg().

It seems strange that the reply doesn't target the message more
precisely, but I don't know all the details.  In any case, I think the
reference counting irregularity became a measureable bug when the
extra arg was added to __gss_find_upcall(), hence the Fixes: line
below.

The second problem is that if rpc_queue_upcall() fails, the new
message is not freed. gss_alloc_msg() set the ->count to 1,
gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1,
then the pointer is discarded so the memory never gets freed.

Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service")
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/sunrpc/auth_gss/auth_gss.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -541,9 +541,13 @@ gss_setup_upcall(struct gss_auth *gss_au
 		return gss_new;
 	gss_msg = gss_add_msg(gss_new);
 	if (gss_msg == gss_new) {
-		int res = rpc_queue_upcall(gss_new->pipe, &gss_new->msg);
+		int res;
+		atomic_inc(&gss_msg->count);
+		res = rpc_queue_upcall(gss_new->pipe, &gss_new->msg);
 		if (res) {
 			gss_unhash_msg(gss_new);
+			atomic_dec(&gss_msg->count);
+			gss_release_msg(gss_new);
 			gss_msg = ERR_PTR(res);
 		}
 	} else
@@ -836,6 +840,7 @@ gss_pipe_destroy_msg(struct rpc_pipe_msg
 			warn_gssd();
 		gss_release_msg(gss_msg);
 	}
+	gss_release_msg(gss_msg);
 }
 
 static void gss_pipe_dentry_destroy(struct dentry *dir,

[PATCH 4.9 102/116] powerpc/64e: Convert cmpi to cmpwi in head_64.S

[Greg Kroah-Hartman]

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

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

From: Nicholas Piggin <npiggin@gmail.com>

commit f87f253bac3ce4a4eb2a60a1ae604d74e65f9042 upstream.

>From 80f23935cadb ("powerpc: Convert cmp to cmpd in idle enter sequence"):

  PowerPC's "cmp" instruction has four operands. Normally people write
  "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
  people forget, and write "cmp" with just three operands.

  With older binutils this is silently accepted as if this was "cmpw",
  while often "cmpd" is wanted. With newer binutils GAS will complain
  about this for 64-bit code. For 32-bit code it still silently assumes
  "cmpw" is what is meant.

In this case, cmpwi is called for, so this is just a build fix for
new toolchains.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/kernel/head_64.S |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -214,9 +214,9 @@ booting_thread_hwid:
  */
 _GLOBAL(book3e_start_thread)
 	LOAD_REG_IMMEDIATE(r5, MSR_KERNEL)
-	cmpi	0, r3, 0
+	cmpwi	r3, 0
 	beq	10f
-	cmpi	0, r3, 1
+	cmpwi	r3, 1
 	beq	11f
 	/* If the thread id is invalid, just exit. */
 	b	13f
@@ -241,9 +241,9 @@ _GLOBAL(book3e_start_thread)
  * r3 = the thread physical id
  */
 _GLOBAL(book3e_stop_thread)
-	cmpi	0, r3, 0
+	cmpwi	r3, 0
 	beq	10f
-	cmpi	0, r3, 1
+	cmpwi	r3, 1
 	beq	10f
 	/* If the thread id is invalid, just exit. */
 	b	13f

[PATCH 4.9 103/116] powerpc/ps3: Fix system hang with GCC 5 builds

[Greg Kroah-Hartman]

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

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

From: Geoff Levand <geoff@infradead.org>

commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.

GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This check is of
limited value, so just get rid of it.

Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/boot/ps3-head.S |    5 -----
 arch/powerpc/boot/ps3.c      |    8 +-------
 2 files changed, 1 insertion(+), 12 deletions(-)

--- a/arch/powerpc/boot/ps3-head.S
+++ b/arch/powerpc/boot/ps3-head.S
@@ -57,11 +57,6 @@ __system_reset_overlay:
 	bctr
 
 1:
-	/* Save the value at addr zero for a null pointer write check later. */
-
-	li	r4, 0
-	lwz	r3, 0(r4)
-
 	/* Primary delays then goes to _zimage_start in wrapper. */
 
 	or	31, 31, 31 /* db16cyc */
--- a/arch/powerpc/boot/ps3.c
+++ b/arch/powerpc/boot/ps3.c
@@ -119,13 +119,12 @@ void ps3_copy_vectors(void)
 	flush_cache((void *)0x100, 512);
 }
 
-void platform_init(unsigned long null_check)
+void platform_init(void)
 {
 	const u32 heapsize = 0x1000000 - (u32)_end; /* 16MiB */
 	void *chosen;
 	unsigned long ft_addr;
 	u64 rm_size;
-	unsigned long val;
 
 	console_ops.write = ps3_console_write;
 	platform_ops.exit = ps3_exit;
@@ -153,11 +152,6 @@ void platform_init(unsigned long null_ch
 
 	printf(" flat tree at 0x%lx\n\r", ft_addr);
 
-	val = *(unsigned long *)0;
-
-	if (val != null_check)
-		printf("null check failed: %lx != %lx\n\r", val, null_check);
-
 	((kernel_entry_t)0)(ft_addr, 0, NULL);
 
 	ps3_exit();

[PATCH 4.9 104/116] powerpc/boot: Request no dynamic linker for boot wrapper

[Greg Kroah-Hartman]

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

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

From: Nicholas Piggin <npiggin@gmail.com>

commit ff45000fcb56b5b0f1a14a865d3541746d838a0a upstream.

The boot wrapper performs its own relocations and does not require
PT_INTERP segment. However currently we don't tell the linker that.

Prior to binutils 2.28 that works OK. But since binutils commit
1a9ccd70f9a7 ("Fix the linker so that it will not silently generate ELF
binaries with invalid program headers. Fix readelf to report such
invalid binaries.") binutils tries to create a program header segment
due to PT_INTERP, and the link fails because there is no space for it:

  ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N
  ld: final link failed: Bad value

So tell the linker not to do that, by passing --no-dynamic-linker.

Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Drop dependency on ld-version.sh and massage change log]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/boot/wrapper |   24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -181,6 +181,28 @@ case "$elfformat" in
     elf32-powerpc)	format=elf32ppc	;;
 esac
 
+ld_version()
+{
+    # Poached from scripts/ld-version.sh, but we don't want to call that because
+    # this script (wrapper) is distributed separately from the kernel source.
+    # Extract linker version number from stdin and turn into single number.
+    awk '{
+	gsub(".*\\)", "");
+	gsub(".*version ", "");
+	gsub("-.*", "");
+	split($1,a, ".");
+	print a[1]*100000000 + a[2]*1000000 + a[3]*10000;
+	exit
+    }'
+}
+
+# Do not include PT_INTERP segment when linking pie. Non-pie linking
+# just ignores this option.
+LD_VERSION=$(${CROSS}ld --version | ld_version)
+LD_NO_DL_MIN_VERSION=$(echo 2.26 | ld_version)
+if [ "$LD_VERSION" -ge "$LD_NO_DL_MIN_VERSION" ] ; then
+	nodl="--no-dynamic-linker"
+fi
 
 platformo=$object/"$platform".o
 lds=$object/zImage.lds
@@ -446,7 +468,7 @@ if [ "$platform" != "miboot" ]; then
         text_start="-Ttext $link_address"
     fi
 #link everything
-    ${CROSS}ld -m $format -T $lds $text_start $pie -o "$ofile" \
+    ${CROSS}ld -m $format -T $lds $text_start $pie $nodl -o "$ofile" \
 	$platformo $tmp $object/wrapper.a
     rm $tmp
 fi

[PATCH 4.9 105/116] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.

[Greg Kroah-Hartman]

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

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

From: David Daney <david.daney@cavium.com>

commit b6cc9474e2dd9f0c19b694b40961d81117f1e918 upstream.

On arm64 NUMA kernels we can pass "numa=off" on the command line to
disable NUMA.  A side effect of this is that kmalloc_node() calls to
non-zero nodes will crash the system with an OOPS:

[    0.000000] ITS@0x0000901000020000: allocated 2097152 Devices @10002000000 (flat, esz 8, psz 64K, shr 1)
[    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00001680
[    0.000000] pgd = fffffc0009470000
[    0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003, *pmd=0000010ffff90003, *pte=0000000000000000
[    0.000000] Internal error: Oops: 96000006 [#1] SMP
.
.
.
[    0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68
[    0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564
[    0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514
[    0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58
[    0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc
[    0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164
[    0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c
[    0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0
[    0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360
[    0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc
[    0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298
[    0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38
[    0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30
[    0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8
[    0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c
[    0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300)
.
.
.

This is caused by code like this in kernel/irq/irqdomain.c

    domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
                  GFP_KERNEL, of_node_to_nid(of_node));

When NUMA is disabled, the concept of a node is really undefined, so
of_node_to_nid() should unconditionally return NUMA_NO_NODE.

Fix by returning NUMA_NO_NODE when the nid is not in the set of
possible nodes.

Reported-by: Gilbert Netzer <noname@pdc.kth.se>
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/of/of_numa.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -176,7 +176,12 @@ int of_node_to_nid(struct device_node *d
 			np->name);
 	of_node_put(np);
 
-	if (!r)
+	/*
+	 * If numa=off passed on command line, or with a defective
+	 * device tree, the nid may not be in the set of possible
+	 * nodes.  Check for this case and return NUMA_NO_NODE.
+	 */
+	if (!r && nid < MAX_NUMNODES && node_possible(nid))
 		return nid;
 
 	return NUMA_NO_NODE;

[PATCH 4.9 106/116] libnvdimm, pfn: fix align attribute

[Greg Kroah-Hartman]

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

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

From: Dan Williams <dan.j.williams@intel.com>

commit af7d9f0c57941b465043681cb5c3410f7f3f1a41 upstream.

Fix the format specifier so that the attribute can be parsed correctly.
Currently it returns decimal 1000 for a 4096-byte alignment.

Reported-by: Dave Jiang <dave.jiang@intel.com>
Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute, default to HPAGE_SIZE")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/nvdimm/pfn_devs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -108,7 +108,7 @@ static ssize_t align_show(struct device
 {
 	struct nd_pfn *nd_pfn = to_nd_pfn_safe(dev);
 
-	return sprintf(buf, "%lx\n", nd_pfn->align);
+	return sprintf(buf, "%ld\n", nd_pfn->align);
 }
 
 static ssize_t __align_store(struct nd_pfn *nd_pfn, const char *buf)

[PATCH 4.9 107/116] target/user: Fix use-after-free of tcmu_cmds if they are expired

[Greg Kroah-Hartman]

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

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

From: Andy Grover <agrover@redhat.com>

commit d0905ca757bc40bd1ebc261a448a521b064777d7 upstream.

Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.

Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.

Reported-by: Bryant G Ly <bgly@us.ibm.com>
Tested-by: Bryant G Ly <bgly@us.ibm.com>
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/target_core_user.c |    2 --
 1 file changed, 2 deletions(-)

--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -685,8 +685,6 @@ static int tcmu_check_expired_cmd(int id
 	target_complete_cmd(cmd->se_cmd, SAM_STAT_CHECK_CONDITION);
 	cmd->se_cmd = NULL;
 
-	kmem_cache_free(tcmu_cmd_cache, cmd);
-
 	return 0;
 }
 

[PATCH 4.9 108/116] kconfig/nconf: Fix hang when editing symbol with a long prompt

[Greg Kroah-Hartman]

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

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

From: Ben Hutchings <ben.hutchings@codethink.co.uk>

commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream.

Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters.  dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid.  It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.

The additions in the offset calculations also don't match the intended
size of the window.

Limit the window size and calculate the offset similarly to
show_scroll_win().

Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 scripts/kconfig/nconf.gui.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -364,12 +364,14 @@ int dialog_inputbox(WINDOW *main_window,
 	WINDOW *prompt_win;
 	WINDOW *form_win;
 	PANEL *panel;
-	int i, x, y;
+	int i, x, y, lines, columns, win_lines, win_cols;
 	int res = -1;
 	int cursor_position = strlen(init);
 	int cursor_form_win;
 	char *result = *resultp;
 
+	getmaxyx(stdscr, lines, columns);
+
 	if (strlen(init)+1 > *result_len) {
 		*result_len = strlen(init)+1;
 		*resultp = result = realloc(result, *result_len);
@@ -386,14 +388,19 @@ int dialog_inputbox(WINDOW *main_window,
 	if (title)
 		prompt_width = max(prompt_width, strlen(title));
 
+	win_lines = min(prompt_lines+6, lines-2);
+	win_cols = min(prompt_width+7, columns-2);
+	prompt_lines = max(win_lines-6, 0);
+	prompt_width = max(win_cols-7, 0);
+
 	/* place dialog in middle of screen */
-	y = (getmaxy(stdscr)-(prompt_lines+4))/2;
-	x = (getmaxx(stdscr)-(prompt_width+4))/2;
+	y = (lines-win_lines)/2;
+	x = (columns-win_cols)/2;
 
 	strncpy(result, init, *result_len);
 
 	/* create the windows */
-	win = newwin(prompt_lines+6, prompt_width+7, y, x);
+	win = newwin(win_lines, win_cols, y, x);
 	prompt_win = derwin(win, prompt_lines+1, prompt_width, 2, 2);
 	form_win = derwin(win, 1, prompt_width, prompt_lines+3, 2);
 	keypad(form_win, TRUE);

[PATCH 4.9 109/116] sg_write()/bsg_write() is not fit to be called under KERNEL_DS

[Greg Kroah-Hartman]

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

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

From: Al Viro <viro@zeniv.linux.org.uk>

commit 128394eff343fc6d2f32172f03e24829539c5835 upstream.

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/bsg.c       |    3 +++
 drivers/scsi/sg.c |    3 +++
 2 files changed, 6 insertions(+)

--- a/block/bsg.c
+++ b/block/bsg.c
@@ -655,6 +655,9 @@ bsg_write(struct file *file, const char
 
 	dprintk("%s: write %Zd bytes\n", bd->name, count);
 
+	if (unlikely(segment_eq(get_fs(), KERNEL_DS)))
+		return -EINVAL;
+
 	bsg_set_block(bd, file);
 
 	bytes_written = 0;
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -581,6 +581,9 @@ sg_write(struct file *filp, const char _
 	sg_io_hdr_t *hp;
 	unsigned char cmnd[SG_MAX_CDB_SIZE];
 
+	if (unlikely(segment_eq(get_fs(), KERNEL_DS)))
+		return -EINVAL;
+
 	if ((!(sfp = (Sg_fd *) filp->private_data)) || (!(sdp = sfp->parentdp)))
 		return -ENXIO;
 	SCSI_LOG_TIMEOUT(3, sg_printk(KERN_INFO, sdp,

[PATCH 4.9 110/116] net: mvpp2: fix dma unmapping of TX buffers for fragments

[Greg Kroah-Hartman]

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

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

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

commit 8354491c9d5b06709384cea91d13019bf5e61449 upstream.

Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.

Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:

 - We have a NULL physical address when calling DMA unmap
 - skb_headlen(skb) crashes because skb is NULL

This causes random crashes when fragments are used.

To solve this problem, we need to:

 - Store the physical address of the buffer to be unmapped
   unconditionally, regardless of whether it is tied to a SKB or not.

 - Store the length of the buffer to be unmapped, which requires a new
   field.

Instead of adding a third array to store the length of the buffer to be
unmapped, and as suggested by David Miller, this commit refactors the
tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
added. Therefore, instead of having three arrays to allocate/free, we
have a single one, which also improve data locality, reducing the
impact on the CPU cache.

Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: Raphael G <raphael.glon@corp.ovh.com>
Cc: Raphael G <raphael.glon@corp.ovh.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/ethernet/marvell/mvpp2.c |   59 +++++++++++++++++------------------
 1 file changed, 30 insertions(+), 29 deletions(-)

--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -770,6 +770,17 @@ struct mvpp2_rx_desc {
 	u32 reserved8;
 };
 
+struct mvpp2_txq_pcpu_buf {
+	/* Transmitted SKB */
+	struct sk_buff *skb;
+
+	/* Physical address of transmitted buffer */
+	dma_addr_t phys;
+
+	/* Size transmitted */
+	size_t size;
+};
+
 /* Per-CPU Tx queue control */
 struct mvpp2_txq_pcpu {
 	int cpu;
@@ -785,11 +796,8 @@ struct mvpp2_txq_pcpu {
 	/* Number of Tx DMA descriptors reserved for each CPU */
 	int reserved_num;
 
-	/* Array of transmitted skb */
-	struct sk_buff **tx_skb;
-
-	/* Array of transmitted buffers' physical addresses */
-	dma_addr_t *tx_buffs;
+	/* Infos about transmitted buffers */
+	struct mvpp2_txq_pcpu_buf *buffs;
 
 	/* Index of last TX DMA descriptor that was inserted */
 	int txq_put_index;
@@ -979,10 +987,11 @@ static void mvpp2_txq_inc_put(struct mvp
 			      struct sk_buff *skb,
 			      struct mvpp2_tx_desc *tx_desc)
 {
-	txq_pcpu->tx_skb[txq_pcpu->txq_put_index] = skb;
-	if (skb)
-		txq_pcpu->tx_buffs[txq_pcpu->txq_put_index] =
-							 tx_desc->buf_phys_addr;
+	struct mvpp2_txq_pcpu_buf *tx_buf =
+		txq_pcpu->buffs + txq_pcpu->txq_put_index;
+	tx_buf->skb = skb;
+	tx_buf->size = tx_desc->data_size;
+	tx_buf->phys = tx_desc->buf_phys_addr;
 	txq_pcpu->txq_put_index++;
 	if (txq_pcpu->txq_put_index == txq_pcpu->size)
 		txq_pcpu->txq_put_index = 0;
@@ -4401,17 +4410,16 @@ static void mvpp2_txq_bufs_free(struct m
 	int i;
 
 	for (i = 0; i < num; i++) {
-		dma_addr_t buf_phys_addr =
-				    txq_pcpu->tx_buffs[txq_pcpu->txq_get_index];
-		struct sk_buff *skb = txq_pcpu->tx_skb[txq_pcpu->txq_get_index];
+		struct mvpp2_txq_pcpu_buf *tx_buf =
+			txq_pcpu->buffs + txq_pcpu->txq_get_index;
 
 		mvpp2_txq_inc_get(txq_pcpu);
 
-		dma_unmap_single(port->dev->dev.parent, buf_phys_addr,
-				 skb_headlen(skb), DMA_TO_DEVICE);
-		if (!skb)
+		dma_unmap_single(port->dev->dev.parent, tx_buf->phys,
+				 tx_buf->size, DMA_TO_DEVICE);
+		if (!tx_buf->skb)
 			continue;
-		dev_kfree_skb_any(skb);
+		dev_kfree_skb_any(tx_buf->skb);
 	}
 }
 
@@ -4651,15 +4659,10 @@ static int mvpp2_txq_init(struct mvpp2_p
 	for_each_present_cpu(cpu) {
 		txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
 		txq_pcpu->size = txq->size;
-		txq_pcpu->tx_skb = kmalloc(txq_pcpu->size *
-					   sizeof(*txq_pcpu->tx_skb),
-					   GFP_KERNEL);
-		if (!txq_pcpu->tx_skb)
-			goto error;
-
-		txq_pcpu->tx_buffs = kmalloc(txq_pcpu->size *
-					     sizeof(dma_addr_t), GFP_KERNEL);
-		if (!txq_pcpu->tx_buffs)
+		txq_pcpu->buffs = kmalloc(txq_pcpu->size *
+					  sizeof(struct mvpp2_txq_pcpu_buf),
+					  GFP_KERNEL);
+		if (!txq_pcpu->buffs)
 			goto error;
 
 		txq_pcpu->count = 0;
@@ -4673,8 +4676,7 @@ static int mvpp2_txq_init(struct mvpp2_p
 error:
 	for_each_present_cpu(cpu) {
 		txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
-		kfree(txq_pcpu->tx_skb);
-		kfree(txq_pcpu->tx_buffs);
+		kfree(txq_pcpu->buffs);
 	}
 
 	dma_free_coherent(port->dev->dev.parent,
@@ -4693,8 +4695,7 @@ static void mvpp2_txq_deinit(struct mvpp
 
 	for_each_present_cpu(cpu) {
 		txq_pcpu = per_cpu_ptr(txq->pcpu, cpu);
-		kfree(txq_pcpu->tx_skb);
-		kfree(txq_pcpu->tx_buffs);
+		kfree(txq_pcpu->buffs);
 	}
 
 	if (txq->descs)

[PATCH 4.9 115/116] drm/i915: skip the first 4k of stolen memory on everything >= gen8

[Greg Kroah-Hartman]

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

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

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

commit 6ba0566cf2afcdb17bff882e3a95cbbcb22c4a83 upstream.

BSpec got updated and this workaround is now listed as standard
required programming for all subsequent projects. This is confirmed to
fix Skylake screen flickering issues (probably caused by the fact that
we initialized a ring in the first page of stolen, but I didn't 100%
confirm this theory).

v2: this is the patch that fixes the screen flickering, document it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
Tested-by: Dominik Klementowski <dominik232@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/i915_gem_stolen.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -55,10 +55,9 @@ int i915_gem_stolen_insert_node_in_range
 		return -ENODEV;
 
 	/* See the comment at the drm_mm_init() call for more about this check.
-	 * WaSkipStolenMemoryFirstPage:bdw,chv,kbl (incomplete)
+	 * WaSkipStolenMemoryFirstPage:bdw+ (incomplete)
 	 */
-	if (start < 4096 && (IS_GEN8(dev_priv) ||
-			     IS_KBL_REVID(dev_priv, 0, KBL_REVID_A0)))
+	if (start < 4096 && INTEL_GEN(dev_priv) >= 8)
 		start = 4096;
 
 	mutex_lock(&dev_priv->mm.stolen_lock);

[PATCH 4.9 116/116] drm/i915: Fix setting of boost freq tunable

[Greg Kroah-Hartman]

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

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

From: Mika Kuoppala <mika.kuoppala@linux.intel.com>

commit b1b7ec985805e005055d1d471ca586a715ffc10a upstream.

For limiting the max frequency of gpu, the max freq tunable
is not enough to hard limit the max gap. We now have also per
client boost max freq. When this tunable was introduced,
it was mistakenly made read only. Allow user to gain control by
setting it writable.

Fixes: 29ecd78d3b79 ("drm/i915: Define a separate variable and control for RPS waitboost frequency")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481718380-9170-1-git-send-email-mika.kuoppala@intel.com
(cherry picked from commit 73a798711314b54cbd4fe224e24db92c306a8d8c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/i915_sysfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -460,7 +460,7 @@ static ssize_t gt_min_freq_mhz_store(str
 
 static DEVICE_ATTR(gt_act_freq_mhz, S_IRUGO, gt_act_freq_mhz_show, NULL);
 static DEVICE_ATTR(gt_cur_freq_mhz, S_IRUGO, gt_cur_freq_mhz_show, NULL);
-static DEVICE_ATTR(gt_boost_freq_mhz, S_IRUGO, gt_boost_freq_mhz_show, gt_boost_freq_mhz_store);
+static DEVICE_ATTR(gt_boost_freq_mhz, S_IRUGO | S_IWUSR, gt_boost_freq_mhz_show, gt_boost_freq_mhz_store);
 static DEVICE_ATTR(gt_max_freq_mhz, S_IRUGO | S_IWUSR, gt_max_freq_mhz_show, gt_max_freq_mhz_store);
 static DEVICE_ATTR(gt_min_freq_mhz, S_IRUGO | S_IWUSR, gt_min_freq_mhz_show, gt_min_freq_mhz_store);
 

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Shuah Khan]

On 01/06/2017 02:42 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.2 release.
> There are 116 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.2-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

On Fri, Jan 06, 2017 at 07:04:20PM -0700, Shuah Khan wrote:
> On 01/06/2017 02:42 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.2 release.
> > There are 116 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.2-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

On Fri, Jan 06, 2017 at 09:42:24PM -0800, kernelci.org bot wrote:
> stable-rc boot: 513 boots: 4 failed, 489 passed with 20 offline (v4.9.1-117-ge3bc65e52a08)
> 
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
> 
> Tree: stable-rc
> Branch: local/linux-4.9.y
> Git Describe: v4.9.1-117-ge3bc65e52a08
> Git Commit: e3bc65e52a086ea9bcc31605737bbf0476f9bcd3
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 88 unique boards, 25 SoC families, 35 builds out of 206
> 
> Boot Regressions Detected:
> 
> arm:
> 
>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>         vexpress-v2p-ca15_a7:
>             lab-broonie: new failure (last pass: v4.9.1)
> 
> Boot Failures Detected:
> 
> arm:
> 
>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
>         vexpress-v2p-ca15_a7: 1 failed lab
> 
>     sunxi_defconfig
>         sun4i-a10-cubieboard: 1 failed lab
> 
>     exynos_defconfig
>         exynos5422-odroidxu3_rootfs:nfs: 1 failed lab
> 
> arm64:
> 
>     defconfig+CONFIG_CPU_BIG_ENDIAN=y
>         juno-r2: 1 failed lab

Are all of these really "failures"?  Some of them seem like they really
did boot, but the test system didn't detect it?

I don't know what to do with these reports, should I trust them that I
broke something, or just ignore them and let someone else dig into them
to determine if it's a false-positive or something like that?

thanks,

greg k-h

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Guenter Roeck]

On 01/06/2017 01:42 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.2 release.
> There are 116 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
	total: 150 pass: 149 fail: 1
Failed builds:
	avr32:merisc_defconfig

Qemu test results:
	total: 122 pass: 122 fail: 0

As before, the avr32 failure is caused by a toolchain problem.

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

On Sat, Jan 07, 2017 at 08:02:28AM -0800, Guenter Roeck wrote:
> On 01/06/2017 01:42 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.2 release.
> > There are 116 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Jan  8 21:38:42 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 150 pass: 149 fail: 1
> Failed builds:
> 	avr32:merisc_defconfig
> 
> Qemu test results:
> 	total: 122 pass: 122 fail: 0
> 
> As before, the avr32 failure is caused by a toolchain problem.

Wonderful, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Kevin Hilman]

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Fri, Jan 06, 2017 at 09:42:24PM -0800, kernelci.org bot wrote:
>> stable-rc boot: 513 boots: 4 failed, 489 passed with 20 offline (v4.9.1-117-ge3bc65e52a08)
>> 
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
>> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
>> 
>> Tree: stable-rc
>> Branch: local/linux-4.9.y
>> Git Describe: v4.9.1-117-ge3bc65e52a08
>> Git Commit: e3bc65e52a086ea9bcc31605737bbf0476f9bcd3
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 88 unique boards, 25 SoC families, 35 builds out of 206
>> 
>> Boot Regressions Detected:
>> 
>> arm:
>> 
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>         vexpress-v2p-ca15_a7:
>>             lab-broonie: new failure (last pass: v4.9.1)
>> 
>> Boot Failures Detected:
>> 
>> arm:
>> 
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
>>         vexpress-v2p-ca15_a7: 1 failed lab
>> 
>>     sunxi_defconfig
>>         sun4i-a10-cubieboard: 1 failed lab
>> 
>>     exynos_defconfig
>>         exynos5422-odroidxu3_rootfs:nfs: 1 failed lab
>> 
>> arm64:
>> 
>>     defconfig+CONFIG_CPU_BIG_ENDIAN=y
>>         juno-r2: 1 failed lab
>
> Are all of these really "failures"?  Some of them seem like they really
> did boot, but the test system didn't detect it?
>
> I don't know what to do with these reports, should I trust them that I
> broke something, or just ignore them and let someone else dig into them
> to determine if it's a false-positive or something like that?

Until we get these more reliable, you can assume that I'll flag
something that's really a blocker.

Only the exynos5422-odroidxu3 failure is a true failure which is also
happendin in mainline. It's been reported and fixed.

The others are silly lab/hardware issues that are hard to get
stabilized. e.g. QEMU taking a really long time to boot
CONFIG_PROVE_LOCKING=y kernels, flaky USB-UART cables etc.

Kevin

Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Greg Kroah-Hartman]

On Mon, Jan 09, 2017 at 10:19:31AM -0800, Kevin Hilman wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> 
> > On Fri, Jan 06, 2017 at 09:42:24PM -0800, kernelci.org bot wrote:
> >> stable-rc boot: 513 boots: 4 failed, 489 passed with 20 offline (v4.9.1-117-ge3bc65e52a08)
> >> 
> >> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
> >> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
> >> 
> >> Tree: stable-rc
> >> Branch: local/linux-4.9.y
> >> Git Describe: v4.9.1-117-ge3bc65e52a08
> >> Git Commit: e3bc65e52a086ea9bcc31605737bbf0476f9bcd3
> >> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> Tested: 88 unique boards, 25 SoC families, 35 builds out of 206
> >> 
> >> Boot Regressions Detected:
> >> 
> >> arm:
> >> 
> >>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> >>         vexpress-v2p-ca15_a7:
> >>             lab-broonie: new failure (last pass: v4.9.1)
> >> 
> >> Boot Failures Detected:
> >> 
> >> arm:
> >> 
> >>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
> >>         vexpress-v2p-ca15_a7: 1 failed lab
> >> 
> >>     sunxi_defconfig
> >>         sun4i-a10-cubieboard: 1 failed lab
> >> 
> >>     exynos_defconfig
> >>         exynos5422-odroidxu3_rootfs:nfs: 1 failed lab
> >> 
> >> arm64:
> >> 
> >>     defconfig+CONFIG_CPU_BIG_ENDIAN=y
> >>         juno-r2: 1 failed lab
> >
> > Are all of these really "failures"?  Some of them seem like they really
> > did boot, but the test system didn't detect it?
> >
> > I don't know what to do with these reports, should I trust them that I
> > broke something, or just ignore them and let someone else dig into them
> > to determine if it's a false-positive or something like that?
> 
> Until we get these more reliable, you can assume that I'll flag
> something that's really a blocker.

Ok, thanks for that, it makes my life easier in trying to parse these
reports :)

greg k-h

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Dmitry Osipenko]

Hello, this patch causes a kernel panic with the rtl8192cu driver.

<6>[   20.847025] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
<1>[   21.699551] BUG: unable to handle kernel NULL pointer dereference at
0000000000000048
<1>[   21.699626] IP: [<ffffffffc037de33>] rtl_lps_leave+0x13/0x40 [rtlwifi]
<4>[   21.699681] PGD 20cf47067
<4>[   21.699702] PUD 20cf42067
<4>[   21.699725] PMD 0
<4>[   21.699732]
<4>[   21.699759] Oops: 0000 [#1] PREEMPT SMP
<4>[   21.699794] Modules linked in: rtl8192cu rtl_usb rtl8192c_common rtlwifi
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec
snd_hwdep snd_hda_core dm_mod thermal
<4>[   21.699985] CPU: 0 PID: 2656 Comm: ntpdate Not tainted 4.9.2 #1
<4>[   21.700036] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./Z77-DS3H, BIOS F11a 11/13/2013
<4>[   21.700118] task: ffff9ce2509ca4c0 task.stack: ffffa41003eac000
<4>[   21.700168] RIP: 0010:[<ffffffffc037de33>]  [<ffffffffc037de33>]
rtl_lps_leave+0x13/0x40 [rtlwifi]
<4>[   21.700250] RSP: 0018:ffffa41003eaf520  EFLAGS: 00010206
<4>[   21.700296] RAX: 0000000080000802 RBX: ffff9ce251371420 RCX: ffff9ce254ff4640
<4>[   21.700356] RDX: 0000000000000806 RSI: ffff9ce25137afb8 RDI: 0000000000000000
<4>[   21.700416] RBP: ffff9ce25137afb8 R08: ffffffffc0382d00 R09: ffff9ce254e38c31
<4>[   21.700475] R10: 0000000000000000 R11: ffff9ce251370700 R12: 0000000000000000
<4>[   21.700535] R13: 0000000000000000 R14: ffff9ce251371420 R15: ffff9ce254e38c00
<4>[   21.700595] FS:  00007f22f6da8700(0000) GS:ffff9ce25f200000(0000)
knlGS:0000000000000000
<4>[   21.700662] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   21.700711] CR2: 0000000000000048 CR3: 000000020cf65000 CR4: 00000000001406f0
<4>[   21.700770] Stack:
<4>[   21.700790]  ffffffffc0375088 0000000000000008 ffff9ce251370700
0000000000000001
<4>[   21.700867]  ffffffffc03751c7 0100000000000000 ffffa41003eaf618
ffff9ce252b5a800
<4>[   21.700944]  0000000000000000 ffff9ce251371420 0000000000000000
ffff9ce254e38c00
<4>[   21.701021] Call Trace:
<4>[   21.701048]  [<ffffffffc0375088>] ? setup_arp_tx.isra.20+0x48/0x60 [rtlwifi]
<4>[   21.701110]  [<ffffffffc03751c7>] ? rtl_is_special_data+0x127/0x210 [rtlwifi]
<4>[   21.701171]  [<ffffffffc037e8c7>] ? rtl_get_rate+0x97/0x210 [rtlwifi]
<4>[   21.701228]  [<ffffffff9a87deb6>] ? rate_control_get_rate+0xb6/0x140
<4>[   21.701283]  [<ffffffff9a88cf30>] ? ieee80211_tx_h_rate_ctrl+0x1e0/0x3f0
<4>[   21.701340]  [<ffffffff9a88fcc2>] ? invoke_tx_handlers_early+0x222/0x5a0
<4>[   21.701397]  [<ffffffff9a89186e>] ? ieee80211_tx+0x6e/0x130
<4>[   21.701446]  [<ffffffff9a892661>] ? __ieee80211_subif_start_xmit+0x4d1/0x9d0
<4>[   21.701506]  [<ffffffff9a741874>] ? nf_conntrack_tuple_taken+0x1c4/0x1d0
<4>[   21.701565]  [<ffffffff9a749779>] ? get_unique_tuple+0xe9/0x510
<4>[   21.701617]  [<ffffffff9a892b6c>] ? ieee80211_subif_start_xmit+0xc/0x10
<4>[   21.701675]  [<ffffffff9a6e606a>] ? dev_hard_start_xmit+0x9a/0x210
<4>[   21.701729]  [<ffffffff9a708a46>] ? sch_direct_xmit+0xd6/0x1a0
<4>[   21.701780]  [<ffffffff9a6e66d2>] ? __dev_queue_xmit+0x422/0x620
<4>[   21.701832]  [<ffffffff9a79859f>] ? arp_xmit+0x9f/0xb0
<4>[   21.701878]  [<ffffffff9a798220>] ? arp_create+0x250/0x250
<4>[   21.701926]  [<ffffffff9a7986ee>] ? arp_solicit+0xee/0x240
<4>[   21.701974]  [<ffffffff9a1335cd>] ? mod_timer+0x1ad/0x360
<4>[   21.702022]  [<ffffffff9a6edf12>] ? neigh_probe+0x42/0x60
<4>[   21.702071]  [<ffffffff9a6ef2f2>] ? __neigh_event_send+0x1e2/0x230
<4>[   21.702124]  [<ffffffff9a6ef520>] ? neigh_resolve_output+0x120/0x1b0
<4>[   21.702179]  [<ffffffff9a76ac37>] ? ip_finish_output2+0x127/0x300
<4>[   21.702231]  [<ffffffff9a76c524>] ? ip_output+0x64/0x100
<4>[   21.702277]  [<ffffffff9a76b9b0>] ?
__ip_flush_pending_frames.isra.46+0x80/0x80
<4>[   21.702339]  [<ffffffff9a76ceb5>] ? ip_send_skb+0x15/0x40
<4>[   21.702386]  [<ffffffff9a79308f>] ? udp_send_skb+0x15f/0x240
<4>[   21.702436]  [<ffffffff9a7944e6>] ? udp_sendmsg+0x2b6/0x840
<4>[   21.702485]  [<ffffffff9a0e10ba>] ? __local_bh_enable_ip+0x8a/0x90
<4>[   21.702538]  [<ffffffff9a76ac4a>] ? ip_finish_output2+0x13a/0x300
<4>[   21.702592]  [<ffffffff9a1fda33>] ? rw_copy_check_uvector+0x53/0x110
<4>[   21.702648]  [<ffffffff9a382b37>] ? import_iovec+0x27/0xc0
<4>[   21.702698]  [<ffffffff9a6c8d01>] ? ___sys_sendmsg+0x111/0x2a0
<4>[   21.702749]  [<ffffffff9a20fa50>] ? poll_select_copy_remaining+0x130/0x130
<4>[   21.702808]  [<ffffffff9a7944f5>] ? udp_sendmsg+0x2c5/0x840
<4>[   21.702857]  [<ffffffff9a79b2b1>] ? __ip_dev_find+0x111/0x130
<4>[   21.702908]  [<ffffffff9a764885>] ? __ip_route_output_key_hash+0x2c5/0x870
<4>[   21.702968]  [<ffffffff9a6c94e9>] ? __sys_sendmmsg+0x89/0x160
<4>[   21.703018]  [<ffffffff9a6c8490>] ? SYSC_connect+0x50/0xa0
<4>[   21.703066]  [<ffffffff9a6c626a>] ? sock_alloc_file+0x9a/0x110
<4>[   21.703119]  [<ffffffff9a6c95ce>] ? SyS_sendmmsg+0xe/0x20
<4>[   21.703166]  [<ffffffff9a8c8837>] ? entry_SYSCALL_64_fastpath+0x1a/0xa9
<4>[   21.703222] Code: 05 e9 32 ff ff ff e9 2d fe ff ff 0f 1f 00 66 2e 0f 1f 84
00 00 00 00 00 0f 1f 44 00 00 65 8b 05 24 f4 c8 3f a9 00 ff 1f 00 74 23 <48> 8b
57 48 bf 40 00 00 00 48 8b 35 3d ba b7 da c6 82 ad a2 00
<1>[   21.709488] RIP  [<ffffffffc037de33>] rtl_lps_leave+0x13/0x40 [rtlwifi]
<4>[   21.712533]  RSP <ffffa41003eaf520>
<4>[   21.715589] CR2: 0000000000000048
<4>[   21.735721] ---[ end trace f6ce402401b0b86a ]---

> 4.9-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Larry Finger <Larry.Finger@lwfinger.net>
> 
> commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.
> 
> In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
> commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
> to use work queue"), an error was introduced in the power-save routines
> due to the fact that leaving PS was delayed by the use of a work queue.
> 
> This problem is fixed by detecting if the enter or leave routines are
> in interrupt mode. If so, the workqueue is used to place the request.
> If in normal mode, the enter or leave routines are called directly.
> 
> Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
> Reported-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
>  drivers/net/wireless/realtek/rtlwifi/base.c |    8 +++---
>  drivers/net/wireless/realtek/rtlwifi/core.c |    9 ++-----
>  drivers/net/wireless/realtek/rtlwifi/pci.c  |   14 +++-------
>  drivers/net/wireless/realtek/rtlwifi/ps.c   |   36 +++++++++++++++++++++-------
>  4 files changed, 40 insertions(+), 27 deletions(-)
> 
> --- a/drivers/net/wireless/realtek/rtlwifi/base.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/base.c
> @@ -1303,12 +1303,13 @@ EXPORT_SYMBOL_GPL(rtl_action_proc);
>  
>  static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc)
>  {
> +	struct ieee80211_hw *hw = rtlpriv->hw;
> +
>  	rtlpriv->ra.is_special_data = true;
>  	if (rtlpriv->cfg->ops->get_btc_status())
>  		rtlpriv->btcoexist.btc_ops->btc_special_packet_notify(
>  					rtlpriv, 1);
> -	rtlpriv->enter_ps = false;
> -	schedule_work(&rtlpriv->works.lps_change_work);
> +	rtl_lps_leave(hw);
>  	ppsc->last_delaylps_stamp_jiffies = jiffies;
>  }
>  
> @@ -1381,8 +1382,7 @@ u8 rtl_is_special_data(struct ieee80211_
>  
>  		if (is_tx) {
>  			rtlpriv->ra.is_special_data = true;
> -			rtlpriv->enter_ps = false;
> -			schedule_work(&rtlpriv->works.lps_change_work);
> +			rtl_lps_leave(hw);
>  			ppsc->last_delaylps_stamp_jiffies = jiffies;
>  		}
>  
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -1150,10 +1150,8 @@ static void rtl_op_bss_info_changed(stru
>  		} else {
>  			mstatus = RT_MEDIA_DISCONNECT;
>  
> -			if (mac->link_state == MAC80211_LINKED) {
> -				rtlpriv->enter_ps = false;
> -				schedule_work(&rtlpriv->works.lps_change_work);
> -			}
> +			if (mac->link_state == MAC80211_LINKED)
> +				rtl_lps_leave(hw);
>  			if (ppsc->p2p_ps_info.p2p_ps_mode > P2P_PS_NONE)
>  				rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE);
>  			mac->link_state = MAC80211_NOLINK;
> @@ -1431,8 +1429,7 @@ static void rtl_op_sw_scan_start(struct
>  	}
>  
>  	if (mac->link_state == MAC80211_LINKED) {
> -		rtlpriv->enter_ps = false;
> -		schedule_work(&rtlpriv->works.lps_change_work);
> +		rtl_lps_leave(hw);
>  		mac->link_state = MAC80211_LINKED_SCANNING;
>  	} else {
>  		rtl_ips_nic_on(hw);
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -663,11 +663,9 @@ tx_status_ok:
>  	}
>  
>  	if (((rtlpriv->link_info.num_rx_inperiod +
> -		rtlpriv->link_info.num_tx_inperiod) > 8) ||
> -		(rtlpriv->link_info.num_rx_inperiod > 2)) {
> -		rtlpriv->enter_ps = false;
> -		schedule_work(&rtlpriv->works.lps_change_work);
> -	}
> +	      rtlpriv->link_info.num_tx_inperiod) > 8) ||
> +	      (rtlpriv->link_info.num_rx_inperiod > 2))
> +		rtl_lps_leave(hw);
>  }
>  
>  static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw,
> @@ -918,10 +916,8 @@ new_trx_end:
>  		}
>  		if (((rtlpriv->link_info.num_rx_inperiod +
>  		      rtlpriv->link_info.num_tx_inperiod) > 8) ||
> -		      (rtlpriv->link_info.num_rx_inperiod > 2)) {
> -			rtlpriv->enter_ps = false;
> -			schedule_work(&rtlpriv->works.lps_change_work);
> -		}
> +		      (rtlpriv->link_info.num_rx_inperiod > 2))
> +			rtl_lps_leave(hw);
>  		skb = new_skb;
>  no_new:
>  		if (rtlpriv->use_new_trx_flow) {
> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> @@ -407,8 +407,8 @@ void rtl_lps_set_psmode(struct ieee80211
>  	}
>  }
>  
> -/*Enter the leisure power save mode.*/
> -void rtl_lps_enter(struct ieee80211_hw *hw)
> +/* Interrupt safe routine to enter the leisure power save mode.*/
> +static void rtl_lps_enter_core(struct ieee80211_hw *hw)
>  {
>  	struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
>  	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> @@ -444,10 +444,9 @@ void rtl_lps_enter(struct ieee80211_hw *
>  
>  	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
>  }
> -EXPORT_SYMBOL(rtl_lps_enter);
>  
> -/*Leave the leisure power save mode.*/
> -void rtl_lps_leave(struct ieee80211_hw *hw)
> +/* Interrupt safe routine to leave the leisure power save mode.*/
> +static void rtl_lps_leave_core(struct ieee80211_hw *hw)
>  {
>  	struct rtl_priv *rtlpriv = rtl_priv(hw);
>  	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> @@ -477,7 +476,6 @@ void rtl_lps_leave(struct ieee80211_hw *
>  	}
>  	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
>  }
> -EXPORT_SYMBOL(rtl_lps_leave);
>  
>  /* For sw LPS*/
>  void rtl_swlps_beacon(struct ieee80211_hw *hw, void *data, unsigned int len)
> @@ -670,12 +668,34 @@ void rtl_lps_change_work_callback(struct
>  	struct rtl_priv *rtlpriv = rtl_priv(hw);
>  
>  	if (rtlpriv->enter_ps)
> -		rtl_lps_enter(hw);
> +		rtl_lps_enter_core(hw);
>  	else
> -		rtl_lps_leave(hw);
> +		rtl_lps_leave_core(hw);
>  }
>  EXPORT_SYMBOL_GPL(rtl_lps_change_work_callback);
>  
> +void rtl_lps_enter(struct ieee80211_hw *hw)
> +{
> +	struct rtl_priv *rtlpriv = rtl_priv(hw);
> +
> +	if (!in_interrupt())
> +		return rtl_lps_enter_core(hw);
> +	rtlpriv->enter_ps = true;
> +	schedule_work(&rtlpriv->works.lps_change_work);
> +}
> +EXPORT_SYMBOL_GPL(rtl_lps_enter);
> +
> +void rtl_lps_leave(struct ieee80211_hw *hw)
> +{
> +	struct rtl_priv *rtlpriv = rtl_priv(hw);
> +
> +	if (!in_interrupt())
> +		return rtl_lps_leave_core(hw);
> +	rtlpriv->enter_ps = false;
> +	schedule_work(&rtlpriv->works.lps_change_work);
> +}
> +EXPORT_SYMBOL_GPL(rtl_lps_leave);
> +
>  void rtl_swlps_wq_callback(void *data)
>  {
>  	struct rtl_works *rtlworks = container_of_dwork_rtl(data,
> 
> 


-- 
Dmitry

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Greg Kroah-Hartman]

On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
> Hello, this patch causes a kernel panic with the rtl8192cu driver.

Ick, not good!  Does this cause a problem in Linus's tree as well?

thanks,

greg k-h

> 
> <6>[   20.847025] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> <1>[   21.699551] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000048
> <1>[   21.699626] IP: [<ffffffffc037de33>] rtl_lps_leave+0x13/0x40 [rtlwifi]
> <4>[   21.699681] PGD 20cf47067
> <4>[   21.699702] PUD 20cf42067
> <4>[   21.699725] PMD 0
> <4>[   21.699732]
> <4>[   21.699759] Oops: 0000 [#1] PREEMPT SMP
> <4>[   21.699794] Modules linked in: rtl8192cu rtl_usb rtl8192c_common rtlwifi
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec
> snd_hwdep snd_hda_core dm_mod thermal
> <4>[   21.699985] CPU: 0 PID: 2656 Comm: ntpdate Not tainted 4.9.2 #1
> <4>[   21.700036] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
> O.E.M./Z77-DS3H, BIOS F11a 11/13/2013
> <4>[   21.700118] task: ffff9ce2509ca4c0 task.stack: ffffa41003eac000
> <4>[   21.700168] RIP: 0010:[<ffffffffc037de33>]  [<ffffffffc037de33>]
> rtl_lps_leave+0x13/0x40 [rtlwifi]
> <4>[   21.700250] RSP: 0018:ffffa41003eaf520  EFLAGS: 00010206
> <4>[   21.700296] RAX: 0000000080000802 RBX: ffff9ce251371420 RCX: ffff9ce254ff4640
> <4>[   21.700356] RDX: 0000000000000806 RSI: ffff9ce25137afb8 RDI: 0000000000000000
> <4>[   21.700416] RBP: ffff9ce25137afb8 R08: ffffffffc0382d00 R09: ffff9ce254e38c31
> <4>[   21.700475] R10: 0000000000000000 R11: ffff9ce251370700 R12: 0000000000000000
> <4>[   21.700535] R13: 0000000000000000 R14: ffff9ce251371420 R15: ffff9ce254e38c00
> <4>[   21.700595] FS:  00007f22f6da8700(0000) GS:ffff9ce25f200000(0000)
> knlGS:0000000000000000
> <4>[   21.700662] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> <4>[   21.700711] CR2: 0000000000000048 CR3: 000000020cf65000 CR4: 00000000001406f0
> <4>[   21.700770] Stack:
> <4>[   21.700790]  ffffffffc0375088 0000000000000008 ffff9ce251370700
> 0000000000000001
> <4>[   21.700867]  ffffffffc03751c7 0100000000000000 ffffa41003eaf618
> ffff9ce252b5a800
> <4>[   21.700944]  0000000000000000 ffff9ce251371420 0000000000000000
> ffff9ce254e38c00
> <4>[   21.701021] Call Trace:
> <4>[   21.701048]  [<ffffffffc0375088>] ? setup_arp_tx.isra.20+0x48/0x60 [rtlwifi]
> <4>[   21.701110]  [<ffffffffc03751c7>] ? rtl_is_special_data+0x127/0x210 [rtlwifi]
> <4>[   21.701171]  [<ffffffffc037e8c7>] ? rtl_get_rate+0x97/0x210 [rtlwifi]
> <4>[   21.701228]  [<ffffffff9a87deb6>] ? rate_control_get_rate+0xb6/0x140
> <4>[   21.701283]  [<ffffffff9a88cf30>] ? ieee80211_tx_h_rate_ctrl+0x1e0/0x3f0
> <4>[   21.701340]  [<ffffffff9a88fcc2>] ? invoke_tx_handlers_early+0x222/0x5a0
> <4>[   21.701397]  [<ffffffff9a89186e>] ? ieee80211_tx+0x6e/0x130
> <4>[   21.701446]  [<ffffffff9a892661>] ? __ieee80211_subif_start_xmit+0x4d1/0x9d0
> <4>[   21.701506]  [<ffffffff9a741874>] ? nf_conntrack_tuple_taken+0x1c4/0x1d0
> <4>[   21.701565]  [<ffffffff9a749779>] ? get_unique_tuple+0xe9/0x510
> <4>[   21.701617]  [<ffffffff9a892b6c>] ? ieee80211_subif_start_xmit+0xc/0x10
> <4>[   21.701675]  [<ffffffff9a6e606a>] ? dev_hard_start_xmit+0x9a/0x210
> <4>[   21.701729]  [<ffffffff9a708a46>] ? sch_direct_xmit+0xd6/0x1a0
> <4>[   21.701780]  [<ffffffff9a6e66d2>] ? __dev_queue_xmit+0x422/0x620
> <4>[   21.701832]  [<ffffffff9a79859f>] ? arp_xmit+0x9f/0xb0
> <4>[   21.701878]  [<ffffffff9a798220>] ? arp_create+0x250/0x250
> <4>[   21.701926]  [<ffffffff9a7986ee>] ? arp_solicit+0xee/0x240
> <4>[   21.701974]  [<ffffffff9a1335cd>] ? mod_timer+0x1ad/0x360
> <4>[   21.702022]  [<ffffffff9a6edf12>] ? neigh_probe+0x42/0x60
> <4>[   21.702071]  [<ffffffff9a6ef2f2>] ? __neigh_event_send+0x1e2/0x230
> <4>[   21.702124]  [<ffffffff9a6ef520>] ? neigh_resolve_output+0x120/0x1b0
> <4>[   21.702179]  [<ffffffff9a76ac37>] ? ip_finish_output2+0x127/0x300
> <4>[   21.702231]  [<ffffffff9a76c524>] ? ip_output+0x64/0x100
> <4>[   21.702277]  [<ffffffff9a76b9b0>] ?
> __ip_flush_pending_frames.isra.46+0x80/0x80
> <4>[   21.702339]  [<ffffffff9a76ceb5>] ? ip_send_skb+0x15/0x40
> <4>[   21.702386]  [<ffffffff9a79308f>] ? udp_send_skb+0x15f/0x240
> <4>[   21.702436]  [<ffffffff9a7944e6>] ? udp_sendmsg+0x2b6/0x840
> <4>[   21.702485]  [<ffffffff9a0e10ba>] ? __local_bh_enable_ip+0x8a/0x90
> <4>[   21.702538]  [<ffffffff9a76ac4a>] ? ip_finish_output2+0x13a/0x300
> <4>[   21.702592]  [<ffffffff9a1fda33>] ? rw_copy_check_uvector+0x53/0x110
> <4>[   21.702648]  [<ffffffff9a382b37>] ? import_iovec+0x27/0xc0
> <4>[   21.702698]  [<ffffffff9a6c8d01>] ? ___sys_sendmsg+0x111/0x2a0
> <4>[   21.702749]  [<ffffffff9a20fa50>] ? poll_select_copy_remaining+0x130/0x130
> <4>[   21.702808]  [<ffffffff9a7944f5>] ? udp_sendmsg+0x2c5/0x840
> <4>[   21.702857]  [<ffffffff9a79b2b1>] ? __ip_dev_find+0x111/0x130
> <4>[   21.702908]  [<ffffffff9a764885>] ? __ip_route_output_key_hash+0x2c5/0x870
> <4>[   21.702968]  [<ffffffff9a6c94e9>] ? __sys_sendmmsg+0x89/0x160
> <4>[   21.703018]  [<ffffffff9a6c8490>] ? SYSC_connect+0x50/0xa0
> <4>[   21.703066]  [<ffffffff9a6c626a>] ? sock_alloc_file+0x9a/0x110
> <4>[   21.703119]  [<ffffffff9a6c95ce>] ? SyS_sendmmsg+0xe/0x20
> <4>[   21.703166]  [<ffffffff9a8c8837>] ? entry_SYSCALL_64_fastpath+0x1a/0xa9
> <4>[   21.703222] Code: 05 e9 32 ff ff ff e9 2d fe ff ff 0f 1f 00 66 2e 0f 1f 84
> 00 00 00 00 00 0f 1f 44 00 00 65 8b 05 24 f4 c8 3f a9 00 ff 1f 00 74 23 <48> 8b
> 57 48 bf 40 00 00 00 48 8b 35 3d ba b7 da c6 82 ad a2 00
> <1>[   21.709488] RIP  [<ffffffffc037de33>] rtl_lps_leave+0x13/0x40 [rtlwifi]
> <4>[   21.712533]  RSP <ffffa41003eaf520>
> <4>[   21.715589] CR2: 0000000000000048
> <4>[   21.735721] ---[ end trace f6ce402401b0b86a ]---
> 
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Larry Finger <Larry.Finger@lwfinger.net>
> > 
> > commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.
> > 
> > In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
> > commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
> > to use work queue"), an error was introduced in the power-save routines
> > due to the fact that leaving PS was delayed by the use of a work queue.
> > 
> > This problem is fixed by detecting if the enter or leave routines are
> > in interrupt mode. If so, the workqueue is used to place the request.
> > If in normal mode, the enter or leave routines are called directly.
> > 
> > Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
> > Reported-by: Ping-Ke Shih <pkshih@realtek.com>
> > Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> > Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > ---
> >  drivers/net/wireless/realtek/rtlwifi/base.c |    8 +++---
> >  drivers/net/wireless/realtek/rtlwifi/core.c |    9 ++-----
> >  drivers/net/wireless/realtek/rtlwifi/pci.c  |   14 +++-------
> >  drivers/net/wireless/realtek/rtlwifi/ps.c   |   36 +++++++++++++++++++++-------
> >  4 files changed, 40 insertions(+), 27 deletions(-)
> > 
> > --- a/drivers/net/wireless/realtek/rtlwifi/base.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/base.c
> > @@ -1303,12 +1303,13 @@ EXPORT_SYMBOL_GPL(rtl_action_proc);
> >  
> >  static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc)
> >  {
> > +	struct ieee80211_hw *hw = rtlpriv->hw;
> > +
> >  	rtlpriv->ra.is_special_data = true;
> >  	if (rtlpriv->cfg->ops->get_btc_status())
> >  		rtlpriv->btcoexist.btc_ops->btc_special_packet_notify(
> >  					rtlpriv, 1);
> > -	rtlpriv->enter_ps = false;
> > -	schedule_work(&rtlpriv->works.lps_change_work);
> > +	rtl_lps_leave(hw);
> >  	ppsc->last_delaylps_stamp_jiffies = jiffies;
> >  }
> >  
> > @@ -1381,8 +1382,7 @@ u8 rtl_is_special_data(struct ieee80211_
> >  
> >  		if (is_tx) {
> >  			rtlpriv->ra.is_special_data = true;
> > -			rtlpriv->enter_ps = false;
> > -			schedule_work(&rtlpriv->works.lps_change_work);
> > +			rtl_lps_leave(hw);
> >  			ppsc->last_delaylps_stamp_jiffies = jiffies;
> >  		}
> >  
> > --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> > @@ -1150,10 +1150,8 @@ static void rtl_op_bss_info_changed(stru
> >  		} else {
> >  			mstatus = RT_MEDIA_DISCONNECT;
> >  
> > -			if (mac->link_state == MAC80211_LINKED) {
> > -				rtlpriv->enter_ps = false;
> > -				schedule_work(&rtlpriv->works.lps_change_work);
> > -			}
> > +			if (mac->link_state == MAC80211_LINKED)
> > +				rtl_lps_leave(hw);
> >  			if (ppsc->p2p_ps_info.p2p_ps_mode > P2P_PS_NONE)
> >  				rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE);
> >  			mac->link_state = MAC80211_NOLINK;
> > @@ -1431,8 +1429,7 @@ static void rtl_op_sw_scan_start(struct
> >  	}
> >  
> >  	if (mac->link_state == MAC80211_LINKED) {
> > -		rtlpriv->enter_ps = false;
> > -		schedule_work(&rtlpriv->works.lps_change_work);
> > +		rtl_lps_leave(hw);
> >  		mac->link_state = MAC80211_LINKED_SCANNING;
> >  	} else {
> >  		rtl_ips_nic_on(hw);
> > --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> > @@ -663,11 +663,9 @@ tx_status_ok:
> >  	}
> >  
> >  	if (((rtlpriv->link_info.num_rx_inperiod +
> > -		rtlpriv->link_info.num_tx_inperiod) > 8) ||
> > -		(rtlpriv->link_info.num_rx_inperiod > 2)) {
> > -		rtlpriv->enter_ps = false;
> > -		schedule_work(&rtlpriv->works.lps_change_work);
> > -	}
> > +	      rtlpriv->link_info.num_tx_inperiod) > 8) ||
> > +	      (rtlpriv->link_info.num_rx_inperiod > 2))
> > +		rtl_lps_leave(hw);
> >  }
> >  
> >  static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw,
> > @@ -918,10 +916,8 @@ new_trx_end:
> >  		}
> >  		if (((rtlpriv->link_info.num_rx_inperiod +
> >  		      rtlpriv->link_info.num_tx_inperiod) > 8) ||
> > -		      (rtlpriv->link_info.num_rx_inperiod > 2)) {
> > -			rtlpriv->enter_ps = false;
> > -			schedule_work(&rtlpriv->works.lps_change_work);
> > -		}
> > +		      (rtlpriv->link_info.num_rx_inperiod > 2))
> > +			rtl_lps_leave(hw);
> >  		skb = new_skb;
> >  no_new:
> >  		if (rtlpriv->use_new_trx_flow) {
> > --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> > +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> > @@ -407,8 +407,8 @@ void rtl_lps_set_psmode(struct ieee80211
> >  	}
> >  }
> >  
> > -/*Enter the leisure power save mode.*/
> > -void rtl_lps_enter(struct ieee80211_hw *hw)
> > +/* Interrupt safe routine to enter the leisure power save mode.*/
> > +static void rtl_lps_enter_core(struct ieee80211_hw *hw)
> >  {
> >  	struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
> >  	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> > @@ -444,10 +444,9 @@ void rtl_lps_enter(struct ieee80211_hw *
> >  
> >  	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
> >  }
> > -EXPORT_SYMBOL(rtl_lps_enter);
> >  
> > -/*Leave the leisure power save mode.*/
> > -void rtl_lps_leave(struct ieee80211_hw *hw)
> > +/* Interrupt safe routine to leave the leisure power save mode.*/
> > +static void rtl_lps_leave_core(struct ieee80211_hw *hw)
> >  {
> >  	struct rtl_priv *rtlpriv = rtl_priv(hw);
> >  	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
> > @@ -477,7 +476,6 @@ void rtl_lps_leave(struct ieee80211_hw *
> >  	}
> >  	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
> >  }
> > -EXPORT_SYMBOL(rtl_lps_leave);
> >  
> >  /* For sw LPS*/
> >  void rtl_swlps_beacon(struct ieee80211_hw *hw, void *data, unsigned int len)
> > @@ -670,12 +668,34 @@ void rtl_lps_change_work_callback(struct
> >  	struct rtl_priv *rtlpriv = rtl_priv(hw);
> >  
> >  	if (rtlpriv->enter_ps)
> > -		rtl_lps_enter(hw);
> > +		rtl_lps_enter_core(hw);
> >  	else
> > -		rtl_lps_leave(hw);
> > +		rtl_lps_leave_core(hw);
> >  }
> >  EXPORT_SYMBOL_GPL(rtl_lps_change_work_callback);
> >  
> > +void rtl_lps_enter(struct ieee80211_hw *hw)
> > +{
> > +	struct rtl_priv *rtlpriv = rtl_priv(hw);
> > +
> > +	if (!in_interrupt())
> > +		return rtl_lps_enter_core(hw);
> > +	rtlpriv->enter_ps = true;
> > +	schedule_work(&rtlpriv->works.lps_change_work);
> > +}
> > +EXPORT_SYMBOL_GPL(rtl_lps_enter);
> > +
> > +void rtl_lps_leave(struct ieee80211_hw *hw)
> > +{
> > +	struct rtl_priv *rtlpriv = rtl_priv(hw);
> > +
> > +	if (!in_interrupt())
> > +		return rtl_lps_leave_core(hw);
> > +	rtlpriv->enter_ps = false;
> > +	schedule_work(&rtlpriv->works.lps_change_work);
> > +}
> > +EXPORT_SYMBOL_GPL(rtl_lps_leave);
> > +
> >  void rtl_swlps_wq_callback(void *data)
> >  {
> >  	struct rtl_works *rtlworks = container_of_dwork_rtl(data,
> > 
> > 
> 
> 
> -- 
> Dmitry

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[lkml]

On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
> > Hello, this patch causes a kernel panic with the rtl8192cu driver.
> 
> Ick, not good!  Does this cause a problem in Linus's tree as well?
> 

http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Willy Tarreau]

On Tue, Jan 10, 2017 at 03:23:27PM -0600, lkml@pengaru.com wrote:
> On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
> > > Hello, this patch causes a kernel panic with the rtl8192cu driver.
> > 
> > Ick, not good!  Does this cause a problem in Linus's tree as well?
> > 
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html

OK the pending patch is here and not yet upstream :

    http://marc.info/?l=linux-wireless&m=148234081512703&w=2

It fixes ba9f93f82aba (patch 3/116) so better postpone it until
the patch above gets merged.

Willy

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Larry Finger]

On 01/10/2017 11:40 AM, Dmitry Osipenko wrote:
> Hello, this patch causes a kernel panic with the rtl8192cu driver.
>
> <6>[   20.847025] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> <1>[   21.699551] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000048
> <1>[   21.699626] IP: [<ffffffffc037de33>] rtl_lps_leave+0x13/0x40 [rtlwifi]
> <4>[   21.699681] PGD 20cf47067
> <4>[   21.699702] PUD 20cf42067
> <4>[   21.699725] PMD 0
> <4>[   21.699732]
> <4>[   21.699759] Oops: 0000 [#1] PREEMPT SMP
> <4>[   21.699794] Modules linked in: rtl8192cu rtl_usb rtl8192c_common rtlwifi
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec
> snd_hwdep snd_hda_core dm_mod thermal
> <4>[   21.699985] CPU: 0 PID: 2656 Comm: ntpdate Not tainted 4.9.2 #1
> <4>[   21.700036] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
> O.E.M./Z77-DS3H, BIOS F11a 11/13/2013
> <4>[   21.700118] task: ffff9ce2509ca4c0 task.stack: ffffa41003eac000
> <4>[   21.700168] RIP: 0010:[<ffffffffc037de33>]  [<ffffffffc037de33>]
> rtl_lps_leave+0x13/0x40 [rtlwifi]
> <4>[   21.700250] RSP: 0018:ffffa41003eaf520  EFLAGS: 00010206
> <4>[   21.700296] RAX: 0000000080000802 RBX: ffff9ce251371420 RCX: ffff9ce254ff4640
> <4>[   21.700356] RDX: 0000000000000806 RSI: ffff9ce25137afb8 RDI: 0000000000000000
> <4>[   21.700416] RBP: ffff9ce25137afb8 R08: ffffffffc0382d00 R09: ffff9ce254e38c31
> <4>[   21.700475] R10: 0000000000000000 R11: ffff9ce251370700 R12: 0000000000000000
> <4>[   21.700535] R13: 0000000000000000 R14: ffff9ce251371420 R15: ffff9ce254e38c00
> <4>[   21.700595] FS:  00007f22f6da8700(0000) GS:ffff9ce25f200000(0000)
> knlGS:0000000000000000
> <4>[   21.700662] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> <4>[   21.700711] CR2: 0000000000000048 CR3: 000000020cf65000 CR4: 00000000001406f0
> <4>[   21.700770] Stack:
> <4>[   21.700790]  ffffffffc0375088 0000000000000008 ffff9ce251370700
> 0000000000000001
> <4>[   21.700867]  ffffffffc03751c7 0100000000000000 ffffa41003eaf618
> ffff9ce252b5a800
> <4>[   21.700944]  0000000000000000 ffff9ce251371420 0000000000000000
> ffff9ce254e38c00
> <4>[   21.701021] Call Trace:
> <4>[   21.701048]  [<ffffffffc0375088>] ? setup_arp_tx.isra.20+0x48/0x60 [rtlwifi]
> <4>[   21.701110]  [<ffffffffc03751c7>] ? rtl_is_special_data+0x127/0x210 [rtlwifi]
> <4>[   21.701171]  [<ffffffffc037e8c7>] ? rtl_get_rate+0x97/0x210 [rtlwifi]
> <4>[   21.701228]  [<ffffffff9a87deb6>] ? rate_control_get_rate+0xb6/0x140
> <4>[   21.701283]  [<ffffffff9a88cf30>] ? ieee80211_tx_h_rate_ctrl+0x1e0/0x3f0
> <4>[   21.701340]  [<ffffffff9a88fcc2>] ? invoke_tx_handlers_early+0x222/0x5a0
> <4>[   21.701397]  [<ffffffff9a89186e>] ? ieee80211_tx+0x6e/0x130
> <4>[   21.701446]  [<ffffffff9a892661>] ? __ieee80211_subif_start_xmit+0x4d1/0x9d0
> <4>[   21.701506]  [<ffffffff9a741874>] ? nf_conntrack_tuple_taken+0x1c4/0x1d0
> <4>[   21.701565]  [<ffffffff9a749779>] ? get_unique_tuple+0xe9/0x510
> <4>[   21.701617]  [<ffffffff9a892b6c>] ? ieee80211_subif_start_xmit+0xc/0x10
> <4>[   21.701675]  [<ffffffff9a6e606a>] ? dev_hard_start_xmit+0x9a/0x210
> <4>[   21.701729]  [<ffffffff9a708a46>] ? sch_direct_xmit+0xd6/0x1a0
> <4>[   21.701780]  [<ffffffff9a6e66d2>] ? __dev_queue_xmit+0x422/0x620
> <4>[   21.701832]  [<ffffffff9a79859f>] ? arp_xmit+0x9f/0xb0
> <4>[   21.701878]  [<ffffffff9a798220>] ? arp_create+0x250/0x250
> <4>[   21.701926]  [<ffffffff9a7986ee>] ? arp_solicit+0xee/0x240
> <4>[   21.701974]  [<ffffffff9a1335cd>] ? mod_timer+0x1ad/0x360
> <4>[   21.702022]  [<ffffffff9a6edf12>] ? neigh_probe+0x42/0x60
> <4>[   21.702071]  [<ffffffff9a6ef2f2>] ? __neigh_event_send+0x1e2/0x230
> <4>[   21.702124]  [<ffffffff9a6ef520>] ? neigh_resolve_output+0x120/0x1b0
> <4>[   21.702179]  [<ffffffff9a76ac37>] ? ip_finish_output2+0x127/0x300
> <4>[   21.702231]  [<ffffffff9a76c524>] ? ip_output+0x64/0x100
> <4>[   21.702277]  [<ffffffff9a76b9b0>] ?
> __ip_flush_pending_frames.isra.46+0x80/0x80
> <4>[   21.702339]  [<ffffffff9a76ceb5>] ? ip_send_skb+0x15/0x40
> <4>[   21.702386]  [<ffffffff9a79308f>] ? udp_send_skb+0x15f/0x240
> <4>[   21.702436]  [<ffffffff9a7944e6>] ? udp_sendmsg+0x2b6/0x840
> <4>[   21.702485]  [<ffffffff9a0e10ba>] ? __local_bh_enable_ip+0x8a/0x90
> <4>[   21.702538]  [<ffffffff9a76ac4a>] ? ip_finish_output2+0x13a/0x300
> <4>[   21.702592]  [<ffffffff9a1fda33>] ? rw_copy_check_uvector+0x53/0x110
> <4>[   21.702648]  [<ffffffff9a382b37>] ? import_iovec+0x27/0xc0
> <4>[   21.702698]  [<ffffffff9a6c8d01>] ? ___sys_sendmsg+0x111/0x2a0
> <4>[   21.702749]  [<ffffffff9a20fa50>] ? poll_select_copy_remaining+0x130/0x130
> <4>[   21.702808]  [<ffffffff9a7944f5>] ? udp_sendmsg+0x2c5/0x840
> <4>[   21.702857]  [<ffffffff9a79b2b1>] ? __ip_dev_find+0x111/0x130
> <4>[   21.702908]  [<ffffffff9a764885>] ? __ip_route_output_key_hash+0x2c5/0x870
> <4>[   21.702968]  [<ffffffff9a6c94e9>] ? __sys_sendmmsg+0x89/0x160
> <4>[   21.703018]  [<ffffffff9a6c8490>] ? SYSC_connect+0x50/0xa0
> <4>[   21.703066]  [<ffffffff9a6c626a>] ? sock_alloc_file+0x9a/0x110
> <4>[   21.703119]  [<ffffffff9a6c95ce>] ? SyS_sendmmsg+0xe/0x20
> <4>[   21.703166]  [<ffffffff9a8c8837>] ? entry_SYSCALL_64_fastpath+0x1a/0xa9
> <4>[   21.703222] Code: 05 e9 32 ff ff ff e9 2d fe ff ff 0f 1f 00 66 2e 0f 1f 84
> 00 00 00 00 00 0f 1f 44 00 00 65 8b 05 24 f4 c8 3f a9 00 ff 1f 00 74 23 <48> 8b
> 57 48 bf 40 00 00 00 48 8b 35 3d ba b7 da c6 82 ad a2 00
> <1>[   21.709488] RIP  [<ffffffffc037de33>] rtl_lps_leave+0x13/0x40 [rtlwifi]
> <4>[   21.712533]  RSP <ffffa41003eaf520>
> <4>[   21.715589] CR2: 0000000000000048
> <4>[   21.735721] ---[ end trace f6ce402401b0b86a ]---
>
>> 4.9-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Larry Finger <Larry.Finger@lwfinger.net>
>>
>> commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.
>>
>> In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
>> commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
>> to use work queue"), an error was introduced in the power-save routines
>> due to the fact that leaving PS was delayed by the use of a work queue.
>>
>> This problem is fixed by detecting if the enter or leave routines are
>> in interrupt mode. If so, the workqueue is used to place the request.
>> If in normal mode, the enter or leave routines are called directly.
>>
>> Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
>> Reported-by: Ping-Ke Shih <pkshih@realtek.com>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> ---
>>  drivers/net/wireless/realtek/rtlwifi/base.c |    8 +++---
>>  drivers/net/wireless/realtek/rtlwifi/core.c |    9 ++-----
>>  drivers/net/wireless/realtek/rtlwifi/pci.c  |   14 +++-------
>>  drivers/net/wireless/realtek/rtlwifi/ps.c   |   36 +++++++++++++++++++++-------
>>  4 files changed, 40 insertions(+), 27 deletions(-)
>>
>> --- a/drivers/net/wireless/realtek/rtlwifi/base.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/base.c
>> @@ -1303,12 +1303,13 @@ EXPORT_SYMBOL_GPL(rtl_action_proc);
>>
>>  static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc)
>>  {
>> +	struct ieee80211_hw *hw = rtlpriv->hw;
>> +
>>  	rtlpriv->ra.is_special_data = true;
>>  	if (rtlpriv->cfg->ops->get_btc_status())
>>  		rtlpriv->btcoexist.btc_ops->btc_special_packet_notify(
>>  					rtlpriv, 1);
>> -	rtlpriv->enter_ps = false;
>> -	schedule_work(&rtlpriv->works.lps_change_work);
>> +	rtl_lps_leave(hw);
>>  	ppsc->last_delaylps_stamp_jiffies = jiffies;
>>  }
>>
>> @@ -1381,8 +1382,7 @@ u8 rtl_is_special_data(struct ieee80211_
>>
>>  		if (is_tx) {
>>  			rtlpriv->ra.is_special_data = true;
>> -			rtlpriv->enter_ps = false;
>> -			schedule_work(&rtlpriv->works.lps_change_work);
>> +			rtl_lps_leave(hw);
>>  			ppsc->last_delaylps_stamp_jiffies = jiffies;
>>  		}
>>
>> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
>> @@ -1150,10 +1150,8 @@ static void rtl_op_bss_info_changed(stru
>>  		} else {
>>  			mstatus = RT_MEDIA_DISCONNECT;
>>
>> -			if (mac->link_state == MAC80211_LINKED) {
>> -				rtlpriv->enter_ps = false;
>> -				schedule_work(&rtlpriv->works.lps_change_work);
>> -			}
>> +			if (mac->link_state == MAC80211_LINKED)
>> +				rtl_lps_leave(hw);
>>  			if (ppsc->p2p_ps_info.p2p_ps_mode > P2P_PS_NONE)
>>  				rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE);
>>  			mac->link_state = MAC80211_NOLINK;
>> @@ -1431,8 +1429,7 @@ static void rtl_op_sw_scan_start(struct
>>  	}
>>
>>  	if (mac->link_state == MAC80211_LINKED) {
>> -		rtlpriv->enter_ps = false;
>> -		schedule_work(&rtlpriv->works.lps_change_work);
>> +		rtl_lps_leave(hw);
>>  		mac->link_state = MAC80211_LINKED_SCANNING;
>>  	} else {
>>  		rtl_ips_nic_on(hw);
>> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
>> @@ -663,11 +663,9 @@ tx_status_ok:
>>  	}
>>
>>  	if (((rtlpriv->link_info.num_rx_inperiod +
>> -		rtlpriv->link_info.num_tx_inperiod) > 8) ||
>> -		(rtlpriv->link_info.num_rx_inperiod > 2)) {
>> -		rtlpriv->enter_ps = false;
>> -		schedule_work(&rtlpriv->works.lps_change_work);
>> -	}
>> +	      rtlpriv->link_info.num_tx_inperiod) > 8) ||
>> +	      (rtlpriv->link_info.num_rx_inperiod > 2))
>> +		rtl_lps_leave(hw);
>>  }
>>
>>  static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw,
>> @@ -918,10 +916,8 @@ new_trx_end:
>>  		}
>>  		if (((rtlpriv->link_info.num_rx_inperiod +
>>  		      rtlpriv->link_info.num_tx_inperiod) > 8) ||
>> -		      (rtlpriv->link_info.num_rx_inperiod > 2)) {
>> -			rtlpriv->enter_ps = false;
>> -			schedule_work(&rtlpriv->works.lps_change_work);
>> -		}
>> +		      (rtlpriv->link_info.num_rx_inperiod > 2))
>> +			rtl_lps_leave(hw);
>>  		skb = new_skb;
>>  no_new:
>>  		if (rtlpriv->use_new_trx_flow) {
>> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
>> @@ -407,8 +407,8 @@ void rtl_lps_set_psmode(struct ieee80211
>>  	}
>>  }
>>
>> -/*Enter the leisure power save mode.*/
>> -void rtl_lps_enter(struct ieee80211_hw *hw)
>> +/* Interrupt safe routine to enter the leisure power save mode.*/
>> +static void rtl_lps_enter_core(struct ieee80211_hw *hw)
>>  {
>>  	struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
>>  	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
>> @@ -444,10 +444,9 @@ void rtl_lps_enter(struct ieee80211_hw *
>>
>>  	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
>>  }
>> -EXPORT_SYMBOL(rtl_lps_enter);
>>
>> -/*Leave the leisure power save mode.*/
>> -void rtl_lps_leave(struct ieee80211_hw *hw)
>> +/* Interrupt safe routine to leave the leisure power save mode.*/
>> +static void rtl_lps_leave_core(struct ieee80211_hw *hw)
>>  {
>>  	struct rtl_priv *rtlpriv = rtl_priv(hw);
>>  	struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
>> @@ -477,7 +476,6 @@ void rtl_lps_leave(struct ieee80211_hw *
>>  	}
>>  	spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag);
>>  }
>> -EXPORT_SYMBOL(rtl_lps_leave);
>>
>>  /* For sw LPS*/
>>  void rtl_swlps_beacon(struct ieee80211_hw *hw, void *data, unsigned int len)
>> @@ -670,12 +668,34 @@ void rtl_lps_change_work_callback(struct
>>  	struct rtl_priv *rtlpriv = rtl_priv(hw);
>>
>>  	if (rtlpriv->enter_ps)
>> -		rtl_lps_enter(hw);
>> +		rtl_lps_enter_core(hw);
>>  	else
>> -		rtl_lps_leave(hw);
>> +		rtl_lps_leave_core(hw);
>>  }
>>  EXPORT_SYMBOL_GPL(rtl_lps_change_work_callback);
>>
>> +void rtl_lps_enter(struct ieee80211_hw *hw)
>> +{
>> +	struct rtl_priv *rtlpriv = rtl_priv(hw);
>> +
>> +	if (!in_interrupt())
>> +		return rtl_lps_enter_core(hw);
>> +	rtlpriv->enter_ps = true;
>> +	schedule_work(&rtlpriv->works.lps_change_work);
>> +}
>> +EXPORT_SYMBOL_GPL(rtl_lps_enter);
>> +
>> +void rtl_lps_leave(struct ieee80211_hw *hw)
>> +{
>> +	struct rtl_priv *rtlpriv = rtl_priv(hw);
>> +
>> +	if (!in_interrupt())
>> +		return rtl_lps_leave_core(hw);
>> +	rtlpriv->enter_ps = false;
>> +	schedule_work(&rtlpriv->works.lps_change_work);
>> +}
>> +EXPORT_SYMBOL_GPL(rtl_lps_leave);
>> +
>>  void rtl_swlps_wq_callback(void *data)
>>  {
>>  	struct rtl_works *rtlworks = container_of_dwork_rtl(data,

The fix is being merged into mainline. The reference is 
http://marc.info/?l=linux-wireless&m=148234081512703&w=2.

Larry

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Larry Finger]

On 01/10/2017 02:40 PM, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
>> Hello, this patch causes a kernel panic with the rtl8192cu driver.
>
> Ick, not good!  Does this cause a problem in Linus's tree as well?

Yes, but he is aware that the pacth exists and has asked the wireless maintainer 
about it. It went to DaveM today.

Larry

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Greg Kroah-Hartman]

On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote:
> On Tue, Jan 10, 2017 at 03:23:27PM -0600, lkml@pengaru.com wrote:
> > On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
> > > > Hello, this patch causes a kernel panic with the rtl8192cu driver.
> > > 
> > > Ick, not good!  Does this cause a problem in Linus's tree as well?
> > > 
> > 
> > http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html
> 
> OK the pending patch is here and not yet upstream :
> 
>     http://marc.info/?l=linux-wireless&m=148234081512703&w=2
> 
> It fixes ba9f93f82aba (patch 3/116) so better postpone it until
> the patch above gets merged.

Yes, I've reverted this now and will wait for this fixup to hit Linus's
tree.  Larry, can you remind me to include the original patch in the
stable tree when this fixup is merged?

thanks,

greg k-h

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Dmitry Osipenko]

On 11.01.2017 04:53, Larry Finger wrote:
> On 01/10/2017 11:40 AM, Dmitry Osipenko wrote:
>> Hello, this patch causes a kernel panic with the rtl8192cu driver.
>>

<snip>

> 
> The fix is being merged into mainline. The reference is
> http://marc.info/?l=linux-wireless&m=148234081512703&w=2.

That indeed fixes the issue, thanks!

-- 
Dmitry

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Dmitry Osipenko]

On 12.01.2017 10:32, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote:
>> On Tue, Jan 10, 2017 at 03:23:27PM -0600, lkml@pengaru.com wrote:
>>> On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
>>>> On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
>>>>> Hello, this patch causes a kernel panic with the rtl8192cu driver.
>>>>
>>>> Ick, not good!  Does this cause a problem in Linus's tree as well?
>>>>
>>>
>>> http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html
>>
>> OK the pending patch is here and not yet upstream :
>>
>>     http://marc.info/?l=linux-wireless&m=148234081512703&w=2
>>
>> It fixes ba9f93f82aba (patch 3/116) so better postpone it until
>> the patch above gets merged.
> 
> Yes, I've reverted this now and will wait for this fixup to hit Linus's
> tree.  Larry, can you remind me to include the original patch in the
> stable tree when this fixup is merged?
> 

Thanks a lot for taking an action.

-- 
Dmitry

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Kalle Valo]

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote:
>> On Tue, Jan 10, 2017 at 03:23:27PM -0600, lkml@pengaru.com wrote:
>> > On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
>> > > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
>> > > > Hello, this patch causes a kernel panic with the rtl8192cu driver.
>> > > 
>> > > Ick, not good!  Does this cause a problem in Linus's tree as well?
>> > > 
>> > 
>> > http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html
>> 
>> OK the pending patch is here and not yet upstream :
>> 
>>     http://marc.info/?l=linux-wireless&m=148234081512703&w=2
>> 
>> It fixes ba9f93f82aba (patch 3/116) so better postpone it until
>> the patch above gets merged.
>
> Yes, I've reverted this now and will wait for this fixup to hit Linus's
> tree.  Larry, can you remind me to include the original patch in the
> stable tree when this fixup is merged?

Linus pulled it now:

commit 60f59ce0278557f7896d5158ae6d12a4855a72cc
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Dec 21 11:18:55 2016 -0600

    rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
    
    These drivers need to be able to reference "struct ieee80211_hw"
    from
    the driver's private data, and vice versa. The USB driver failed to
    store the address of ieee80211_hw in the private data. Although this
    bug has been present for a long time, it was not exposed until
    commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").
    
    Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

-- 
Kalle Valo

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[Greg Kroah-Hartman]

On Fri, Jan 13, 2017 at 08:42:03AM +0200, Kalle Valo wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> 
> > On Tue, Jan 10, 2017 at 10:51:56PM +0100, Willy Tarreau wrote:
> >> On Tue, Jan 10, 2017 at 03:23:27PM -0600, lkml@pengaru.com wrote:
> >> > On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
> >> > > On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
> >> > > > Hello, this patch causes a kernel panic with the rtl8192cu driver.
> >> > > 
> >> > > Ick, not good!  Does this cause a problem in Linus's tree as well?
> >> > > 
> >> > 
> >> > http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html
> >> 
> >> OK the pending patch is here and not yet upstream :
> >> 
> >>     http://marc.info/?l=linux-wireless&m=148234081512703&w=2
> >> 
> >> It fixes ba9f93f82aba (patch 3/116) so better postpone it until
> >> the patch above gets merged.
> >
> > Yes, I've reverted this now and will wait for this fixup to hit Linus's
> > tree.  Larry, can you remind me to include the original patch in the
> > stable tree when this fixup is merged?
> 
> Linus pulled it now:
> 
> commit 60f59ce0278557f7896d5158ae6d12a4855a72cc
> Author: Larry Finger <Larry.Finger@lwfinger.net>
> Date:   Wed Dec 21 11:18:55 2016 -0600
> 
>     rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
>     
>     These drivers need to be able to reference "struct ieee80211_hw"
>     from
>     the driver's private data, and vice versa. The USB driver failed to
>     store the address of ieee80211_hw in the private data. Although this
>     bug has been present for a long time, it was not exposed until
>     commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").
>     
>     Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
>     Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>     Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Thanks will queue these two up now.

greg k-h