commit 92b8a3b2136d3051170ed6b14f21bac7808acc09
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 20 15:46:35 2016 +0900

    Linux 4.5.2

commit 9378a3b5d6d6930b218a6e6cefcbe4014556bf02
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Thu Jan 21 11:57:47 2016 +0000

    staging: android: ion: Set the length of the DMA sg entries in buffer
    
    commit 70bc916b2c80913753fb188d4daee50a64d21ba0 upstream.
    
    ion_buffer_create() will allocate a buffer and then create a DMA
    mapping for it, but it forgot to set the length of the page entries.
    
    Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
    Signed-off-by: Jon Medhurst <tixy@linaro.org>
    Acked-by: Laura Abbott <labbott@redhat.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 383b59f1349536dc242026dc4edc818547ddcdd2
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Mar 23 12:17:09 2016 -0400

    HID: usbhid: fix inconsistent reset/resume/reset-resume behavior
    
    commit 972e6a993f278b416a8ee3ec65475724fc36feb2 upstream.
    
    The usbhid driver has inconsistently duplicated code in its post-reset,
    resume, and reset-resume pathways.
    
    	reset-resume doesn't check HID_STARTED before trying to
    	restart the I/O queues.
    
    	resume fails to clear the HID_SUSPENDED flag if HID_STARTED
    	isn't set.
    
    	resume calls usbhid_restart_queues() with usbhid->lock held
    	and the others call it without holding the lock.
    
    The first item in particular causes a problem following a reset-resume
    if the driver hasn't started up its I/O.  URB submission fails because
    usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
    
    This patch fixes the problem by creating a new subroutine,
    hid_restart_io(), to carry out all the common activities.  It also
    adds some checks that were missing in the original code:
    
    	After a reset, there's no need to clear any halted endpoints.
    
    	After a resume, if a reset is pending there's no need to
    	restart any I/O until the reset is finished.
    
    	After a resume, if the interrupt-IN endpoint is halted there's
    	no need to submit the input URB until the halt has been
    	cleared.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Daniel Fraga <fragabr@gmail.com>
    Tested-by: Daniel Fraga <fragabr@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fa2fc16d9aad7270c9175f7d121517a1c3aff06
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Mar 25 15:26:55 2016 +0100

    HID: wacom: fix Bamboo ONE oops
    
    commit 580549ef6b3e3fb3b958de490ca99f43a089a2cf upstream.
    
    Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
    The tablet behaves as if it was a regular Bamboo device with pen, touch
    and pad, but there is no physical pad connected to it.
    The weird part is that the pad is still sending events and given that
    there is no input node connected to it, we get  anull pointer exception.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
    
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Ping Cheng <pingc@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bfe5a572e2549cda69a46973d0a977bf74cdbf0
Author: Kailang Yang <kailang@realtek.com>
Date:   Tue Apr 12 10:55:03 2016 +0800

    ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock
    
    commit adcdd0d5a1cb779f6d455ae70882c19c527627a8 upstream.
    
    This is Dell usb dock audio workaround.
    It was fixed the master volume keep lower.
    
    [Some background: the patch essentially skips the controls of a couple
     of FU volumes.  Although the firmware exposes the dB and the value
     information via the usb descriptor, changing the values (we set the
     min volume as default) screws up the device.  Although this has been
     fixed in the newer firmware, the devices are shipped with the old
     firmware, thus we need the workaround in the driver side.  -- tiwai]
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b040b32927d6569b8647a90a71c74c0a5976171
Author: Dennis Kadioglu <denk@post.com>
Date:   Wed Apr 6 08:39:01 2016 +0200

    ALSA: usb-audio: Add a quirk for Plantronics BT300
    
    commit b4203ff5464da00b7812e7b480192745b0d66bbf upstream.
    
    Plantronics BT300 does not support reading the sample rate which leads
    to many lines of "cannot get freq at ep 0x1". This patch adds the USB
    ID of the BT300 to quirks.c and avoids those error messages.
    
    Signed-off-by: Dennis Kadioglu <denk@post.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e088a69277fed8fc65cef419506ba7872f5ff01
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Apr 4 11:47:50 2016 +0200

    ALSA: usb-audio: Add a sample rate quirk for Phoenix Audio TMX320
    
    commit f03b24a851d32ca85dacab01785b24a7ee717d37 upstream.
    
    Phoenix Audio TMX320 gives the similar error when the sample rate is
    asked:
      usb 2-1.3: 2:1: cannot get freq at ep 0x85
      usb 2-1.3: 1:1: cannot get freq at ep 0x2
      ....
    
    Add the corresponding USB-device ID (1de7:0014) to
    snd_usb_get_sample_rate_quirk() list.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e3d5c4d31b00aa130220b3ced2d505163ef6b74
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Apr 11 16:55:26 2016 +0200

    ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T460s
    
    commit c636b95ec5980345674ad7960a3c67135a84b687 upstream.
    
    The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in
    order to get working sound output on the docking stations headphone jack.
    
    Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock
    on kernel 4.4.6.
    
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 285947f387fb300bc4c7feb8ac67f409e44fc452
Author: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
Date:   Wed Apr 13 09:27:39 2016 +0900

    ALSA: hda - Fix regression of monitor_present flag in eld proc file
    
    commit 023d8218ec0dfc30e11d4ec54f640e8f127d1fbe upstream.
    
    The commit [bd48128539ab: ALSA: hda - Fix forgotten HDMI
    monitor_present update] covered the missing update of monitor_present
    flag, but this caused a regression for devices without the i915 eld
    notifier.  Since the old code supposed that pin_eld->monitor_present
    was updated by the caller side, the hdmi_present_sense_via_verbs()
    doesn't update the temporary eld->monitor_present but only
    pin_eld->monitor_present, which is now overridden in update_eld().
    
    The fix is to update pin_eld->monitor_present as well before calling
    update_eld().
    
    Note that this may still leave monitor_present flag in an inconsistent
    state when the driver repolls, but this is at least the old behavior.
    More proper fix will follow in the later patch.
    
    Fixes: bd48128539ab ('ALSA: hda - Fix forgotten HDMI monitor_present update')
    Signed-off-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e91bf335767d83368fb0e1dbfa4342bffaa0b0f
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Apr 4 12:40:37 2016 +0300

    mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers
    
    commit 01d6b2a40a0fa73c90e05b1033f181a51fec9292 upstream.
    
    Add support and PCI IDs for more Broxton host controllers
    
    Other BXT IDs were added in v4.4 so cc'ing stable. This patch
    is dependent on commit 163cbe31e516 ("mmc: sdhci-pci: Fix card
    detect race for Intel BXT/APL") but that is already in stable
    since v4.4.4.
    
    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>

commit 46d75c0b7432a53014055044fa06c0c77bf0a5b2
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Mar 29 12:45:43 2016 +0300

    mmc: sdhci: Fix regression setting power on Trats2 board
    
    commit 1dceb0415aa0c6bc11dacdab47c9ef83a3604166 upstream.
    
    Several commits relating to setting power have been introducing
    problems by putting driver-specific rules into generic SDHCI code.
    
    Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
    sdhci: restore behavior when setting VDD via external regulator")
    on Trats2 board there are warnings for invalid VDD  value (2.8V):
    
    [    3.119656] ------------[ cut here ]------------
    [    3.119666] WARNING: CPU: 3 PID: 90 at
    ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
    [    3.119669] mmc0: Invalid vdd 0x10
    [    3.119673] Modules linked in:
    [    3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G        W
       4.5.0-next-20160324 #23
    [    3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
    [    3.119690] Workqueue: events_freezable mmc_rescan
    [    3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
    (show_stack+0x10/0x14)
    [    3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
    (dump_stack+0x88/0x9c)
    [    3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
    [    3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
    (warn_slowpath_fmt+0x38/0x48)
    [    3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
    (sdhci_do_set_ios+0x4cc/0x5e0)
    [    3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
    (sdhci_runtime_resume_host+0x60/0x114)
    [    3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
    [<c0402570>] (__rpm_callback+0x2c/0x60)
    [    3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
    (rpm_callback+0x20/0x80)
    [    3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
    (rpm_resume+0x36c/0x558)
    [    3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
    (__pm_runtime_resume+0x4c/0x64)
    [    3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
    (__mmc_claim_host+0x170/0x1b0)
    [    3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
    (mmc_rescan+0x54/0x348)
    [    3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
    (process_one_work+0x120/0x3f4)
    [    3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
    (worker_thread+0x38/0x554)
    [    3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
    (kthread+0xdc/0xf4)
    [    3.119831] [<c01365a4>] (kthread) from [<c0107878>]
    (ret_from_fork+0x14/0x3c)
    [    3.119834] ---[ end trace a22d652aa3276886 ]---
    
    Fix by adding a 'set_power' callback and restoring the default
    behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
    behavior when setting VDD via external regulator").  The desired
    behaviour of that commit is gotten by having sdhci-pxav3 provide
    its own set_power callback.
    
    Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
    Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
    Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
    Tested-by: Jisheng Zhang <jszhang@marvell.com>
    Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
    Tested-by: Anand Moon <linux.amoon@gmail.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8ed22517f6e7e0c2737c08220175d6e7ff564ed
Author: Yang Shi <yang.shi@linaro.org>
Date:   Mon Feb 8 14:49:24 2016 -0800

    arm64: replace read_lock to rcu lock in call_step_hook
    
    commit cf0a25436f05753aca5151891aea4fd130556e2a upstream.
    
    BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
    in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
    Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8
    
    CPU: 3 PID: 383 Comm: sh Tainted: G        W       4.1.13-rt13 #2
    Hardware name: Freescale Layerscape 2085a RDB Board (DT)
    Call trace:
    [<ffff8000000885e8>] dump_backtrace+0x0/0x128
    [<ffff800000088734>] show_stack+0x24/0x30
    [<ffff80000079a7c4>] dump_stack+0x80/0xa0
    [<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
    [<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
    [<ffff8000007a2268>] rt_read_lock+0x40/0x58
    [<ffff800000085328>] single_step_handler+0x38/0xd8
    [<ffff800000082368>] do_debug_exception+0x58/0xb8
    Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
    7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
    7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
    7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
    7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
    7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
    7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
    7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
    7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
    7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
    [<ffff8000000833f4>] el1_dbg+0x18/0x6c
    
    This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
    call_break_hook"), but comes to single_step_handler.
    
    This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.
    
    Signed-off-by: Yang Shi <yang.shi@linaro.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff440e9185e96cbb94481fc8b6192b944dcfc061
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Mar 30 23:37:21 2016 +0100

    Btrfs: fix file/data loss caused by fsync after rename and new inode
    
    commit 56f23fdbb600e6087db7b009775b95ce07cc3195 upstream.
    
    If we rename an inode A (be it a file or a directory), create a new
    inode B with the old name of inode A and under the same parent directory,
    fsync inode B and then power fail, at log tree replay time we end up
    removing inode A completely. If inode A is a directory then all its files
    are gone too.
    
    Example scenarios where this happens:
    This is reproducible with the following steps, taken from a couple of
    test cases written for fstests which are going to be submitted upstream
    soon:
    
       # Scenario 1
    
       mkfs.btrfs -f /dev/sdc
       mount /dev/sdc /mnt
       mkdir -p /mnt/a/x
       echo "hello" > /mnt/a/x/foo
       echo "world" > /mnt/a/x/bar
       sync
       mv /mnt/a/x /mnt/a/y
       mkdir /mnt/a/x
       xfs_io -c fsync /mnt/a/x
       <power failure happens>
    
       The next time the fs is mounted, log tree replay happens and
       the directory "y" does not exist nor do the files "foo" and
       "bar" exist anywhere (neither in "y" nor in "x", nor the root
       nor anywhere).
    
       # Scenario 2
    
       mkfs.btrfs -f /dev/sdc
       mount /dev/sdc /mnt
       mkdir /mnt/a
       echo "hello" > /mnt/a/foo
       sync
       mv /mnt/a/foo /mnt/a/bar
       echo "world" > /mnt/a/foo
       xfs_io -c fsync /mnt/a/foo
       <power failure happens>
    
       The next time the fs is mounted, log tree replay happens and the
       file "bar" does not exists anymore. A file with the name "foo"
       exists and it matches the second file we created.
    
    Another related problem that does not involve file/data loss is when a
    new inode is created with the name of a deleted snapshot and we fsync it:
    
       mkfs.btrfs -f /dev/sdc
       mount /dev/sdc /mnt
       mkdir /mnt/testdir
       btrfs subvolume snapshot /mnt /mnt/testdir/snap
       btrfs subvolume delete /mnt/testdir/snap
       rmdir /mnt/testdir
       mkdir /mnt/testdir
       xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
       <power failure>
    
       The next time the fs is mounted the log replay procedure fails because
       it attempts to delete the snapshot entry (which has dir item key type
       of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
       resulting in the following error that causes mount to fail:
    
       [52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
       [52174.512570] ------------[ cut here ]------------
       [52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
       [52174.514681] BTRFS: Transaction aborted (error -2)
       [52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
       [52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G        W       4.5.0-rc6-btrfs-next-27+ #1
       [52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
       [52174.524053]  0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
       [52174.524053]  0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
       [52174.524053]  00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
       [52174.524053] Call Trace:
       [52174.524053]  [<ffffffff81264e93>] dump_stack+0x67/0x90
       [52174.524053]  [<ffffffff81051618>] warn_slowpath_common+0x99/0xb2
       [52174.524053]  [<ffffffffa03591cd>] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
       [52174.524053]  [<ffffffff81051679>] warn_slowpath_fmt+0x48/0x50
       [52174.524053]  [<ffffffffa03591cd>] __btrfs_unlink_inode+0x178/0x351 [btrfs]
       [52174.524053]  [<ffffffff8118f5e9>] ? iput+0xb0/0x284
       [52174.524053]  [<ffffffffa0359fe8>] btrfs_unlink_inode+0x1c/0x3d [btrfs]
       [52174.524053]  [<ffffffffa038631e>] check_item_in_log+0x1fe/0x29b [btrfs]
       [52174.524053]  [<ffffffffa0386522>] replay_dir_deletes+0x167/0x1cf [btrfs]
       [52174.524053]  [<ffffffffa038739e>] fixup_inode_link_count+0x289/0x2aa [btrfs]
       [52174.524053]  [<ffffffffa038748a>] fixup_inode_link_counts+0xcb/0x105 [btrfs]
       [52174.524053]  [<ffffffffa038a5ec>] btrfs_recover_log_trees+0x258/0x32c [btrfs]
       [52174.524053]  [<ffffffffa03885b2>] ? replay_one_extent+0x511/0x511 [btrfs]
       [52174.524053]  [<ffffffffa034f288>] open_ctree+0x1dd4/0x21b9 [btrfs]
       [52174.524053]  [<ffffffffa032b753>] btrfs_mount+0x97e/0xaed [btrfs]
       [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
       [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
       [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
       [52174.524053]  [<ffffffffa032af81>] btrfs_mount+0x1ac/0xaed [btrfs]
       [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
       [52174.524053]  [<ffffffff8108c262>] ? lockdep_init_map+0xb9/0x1b3
       [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
       [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
       [52174.524053]  [<ffffffff8119590f>] do_mount+0x8a6/0x9e8
       [52174.524053]  [<ffffffff811358dd>] ? strndup_user+0x3f/0x59
       [52174.524053]  [<ffffffff81195c65>] SyS_mount+0x77/0x9f
       [52174.524053]  [<ffffffff814935d7>] entry_SYSCALL_64_fastpath+0x12/0x6b
       [52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---
    
    Fix this by forcing a transaction commit when such cases happen.
    This means we check in the commit root of the subvolume tree if there
    was any other inode with the same reference when the inode we are
    fsync'ing is a new inode (created in the current transaction).
    
    Test cases for fstests, covering all the scenarios given above, were
    submitted upstream for fstests:
    
      * fstests: generic test for fsync after renaming directory
        https://patchwork.kernel.org/patch/8694281/
    
      * fstests: generic test for fsync after renaming file
        https://patchwork.kernel.org/patch/8694301/
    
      * fstests: add btrfs test for fsync after snapshot deletion
        https://patchwork.kernel.org/patch/8670671/
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dccfd02dae45e9a5afaff64f08975ab35fa82cec
Author: Joerg Roedel <jroedel@suse.de>
Date:   Mon Apr 4 15:47:48 2016 +0200

    iommu: Don't overwrite domain pointer when there is no default_domain
    
    commit eebb8034a5be8c2177cbf07ca2ecd2ff8a058958 upstream.
    
    IOMMU drivers that do not support default domains, but make
    use of the the group->domain pointer can get that pointer
    overwritten with NULL on device add/remove.
    
    Make sure this can't happen by only overwriting the domain
    pointer when it is NULL.
    
    Fixes: 1228236de5f9 ('iommu: Move default domain allocation to iommu_group_get_for_dev()')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b77d0df7362d4b109c452968711e18d7103ed81
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Apr 3 17:03:37 2016 -0400

    ext4: ignore quota mount options if the quota feature is enabled
    
    commit c325a67c72903e1cc30e990a15ce745bda0dbfde upstream.
    
    Previously, ext4 would fail the mount if the file system had the quota
    feature enabled and quota mount options (used for the older quota
    setups) were present.  This broke xfstests, since xfs silently ignores
    the usrquote and grpquota mount options if they are specified.  This
    commit changes things so that we are consistent with xfs; having the
    mount options specified is harmless, so no sense break users by
    forbidding them.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f1aafe300072b2d09e71ec5f18deca77f9b3463
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Apr 1 01:31:28 2016 -0400

    ext4: add lockdep annotations for i_data_sem
    
    commit daf647d2dd58cec59570d7698a45b98e580f2076 upstream.
    
    With the internal Quota feature, mke2fs creates empty quota inodes and
    quota usage tracking is enabled as soon as the file system is mounted.
    Since quotacheck is no longer preallocating all of the blocks in the
    quota inode that are likely needed to be written to, we are now seeing
    a lockdep false positive caused by needing to allocate a quota block
    from inside ext4_map_blocks(), while holding i_data_sem for a data
    inode.  This results in this complaint:
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(&ei->i_data_sem);
                                    lock(&s->s_dquot.dqio_mutex);
                                    lock(&ei->i_data_sem);
       lock(&s->s_dquot.dqio_mutex);
    
    Google-Bug-Id: 27907753
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcc6f2ddcbe6fb23a6e9a76d14b2862fffa6a127
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Mar 30 19:03:13 2016 -0400

    btrfs: fix crash/invalid memory access on fsync when using overlayfs
    
    commit de17e793b104d690e1d007dfc5cb6b4f649598ca upstream.
    
    If the lower or upper directory of an overlayfs mount belong to a btrfs
    file system and we fsync the file through the overlayfs' merged directory
    we ended up accessing an inode that didn't belong to btrfs as if it were
    a btrfs inode at btrfs_sync_file() resulting in a crash like the following:
    
    [ 7782.588845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000544
    [ 7782.590624] IP: [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
    [ 7782.591931] PGD 4d954067 PUD 1e878067 PMD 0
    [ 7782.592016] Oops: 0002 [#6] PREEMPT SMP DEBUG_PAGEALLOC
    [ 7782.592016] Modules linked in: btrfs overlay ppdev crc32c_generic evdev xor raid6_pq psmouse pcspkr sg serio_raw acpi_cpufreq parport_pc parport tpm_tis i2c_piix4 tpm i2c_core processor button loop autofs4 ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
    [ 7782.592016] CPU: 10 PID: 16437 Comm: xfs_io Tainted: G      D         4.5.0-rc6-btrfs-next-26+ #1
    [ 7782.592016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
    [ 7782.592016] task: ffff88001b8d40c0 ti: ffff880137488000 task.ti: ffff880137488000
    [ 7782.592016] RIP: 0010:[<ffffffffa030b7ab>]  [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
    [ 7782.592016] RSP: 0018:ffff88013748be40  EFLAGS: 00010286
    [ 7782.592016] RAX: 0000000080000000 RBX: ffff880133b30c88 RCX: 0000000000000001
    [ 7782.592016] RDX: 0000000000000001 RSI: ffffffff8148fec0 RDI: 00000000ffffffff
    [ 7782.592016] RBP: ffff88013748bec0 R08: 0000000000000001 R09: 0000000000000000
    [ 7782.624248] R10: ffff88013748be40 R11: 0000000000000246 R12: 0000000000000000
    [ 7782.624248] R13: 0000000000000000 R14: 00000000009305a0 R15: ffff880015e3be40
    [ 7782.624248] FS:  00007fa83b9cb700(0000) GS:ffff88023ed40000(0000) knlGS:0000000000000000
    [ 7782.624248] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 7782.624248] CR2: 0000000000000544 CR3: 00000001fa652000 CR4: 00000000000006e0
    [ 7782.624248] Stack:
    [ 7782.624248]  ffffffff8108b5cc ffff88013748bec0 0000000000000246 ffff8800b005ded0
    [ 7782.624248]  ffff880133b30d60 8000000000000000 7fffffffffffffff 0000000000000246
    [ 7782.624248]  0000000000000246 ffffffff81074f9b ffffffff8104357c ffff880015e3be40
    [ 7782.624248] Call Trace:
    [ 7782.624248]  [<ffffffff8108b5cc>] ? arch_local_irq_save+0x9/0xc
    [ 7782.624248]  [<ffffffff81074f9b>] ? ___might_sleep+0xce/0x217
    [ 7782.624248]  [<ffffffff8104357c>] ? __do_page_fault+0x3c0/0x43a
    [ 7782.624248]  [<ffffffff811a2351>] vfs_fsync_range+0x8c/0x9e
    [ 7782.624248]  [<ffffffff811a237f>] vfs_fsync+0x1c/0x1e
    [ 7782.624248]  [<ffffffff811a24d6>] do_fsync+0x31/0x4a
    [ 7782.624248]  [<ffffffff811a2700>] SyS_fsync+0x10/0x14
    [ 7782.624248]  [<ffffffff81493617>] entry_SYSCALL_64_fastpath+0x12/0x6b
    [ 7782.624248] Code: 85 c0 0f 85 e2 02 00 00 48 8b 45 b0 31 f6 4c 29 e8 48 ff c0 48 89 45 a8 48 8d 83 d8 00 00 00 48 89 c7 48 89 45 a0 e8 fc 43 18 e1 <f0> 41 ff 84 24 44 05 00 00 48 8b 83 58 ff ff ff 48 c1 e8 07 83
    [ 7782.624248] RIP  [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
    [ 7782.624248]  RSP <ffff88013748be40>
    [ 7782.624248] CR2: 0000000000000544
    [ 7782.661994] ---[ end trace 721e14960eb939bc ]---
    
    This started happening since commit 4bacc9c9234 (overlayfs: Make f_path
    always point to the overlay and f_inode to the underlay) and even though
    after this change we could still access the btrfs inode through
    struct file->f_mapping->host or struct file->f_inode, we would end up
    resulting in more similar issues later on at check_parent_dirs_for_sync()
    because the dentry we got (from struct file->f_path.dentry) was from
    overlayfs and not from btrfs, that is, we had no way of getting the dentry
    that belonged to btrfs (we always got the dentry that belonged to
    overlayfs).
    
    The new patch from Miklos Szeredi, titled "vfs: add file_dentry()" and
    recently submitted to linux-fsdevel, adds a file_dentry() API that allows
    us to get the btrfs dentry from the input file and therefore being able
    to fsync when the upper and lower directories belong to btrfs filesystems.
    
    This issue has been reported several times by users in the mailing list
    and bugzilla. A test case for xfstests is being submitted as well.
    
    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101951
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109791
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 846b2696a9ac0fd189714a1ca2ccfa5a38613439
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Sat Mar 26 16:14:42 2016 -0400

    ext4: use file_dentry()
    
    commit c0a37d48788475d0a2cf4fbfaa28559a9de612fc upstream.
    
    EXT4 may be used as lower layer of overlayfs and accessing f_path.dentry
    can lead to a crash.
    
    Fix by replacing direct access of file->f_path.dentry with the
    file_dentry() accessor, which will always return a native object.
    
    Reported-by: Daniel Axtens <dja@axtens.net>
    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
    Fixes: ff978b09f973 ("ext4 crypto: move context consistency check to ext4_file_open()")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7222d93072f178e5e5c40a6b1fef8946f35bb4ee
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Sat Mar 26 16:14:41 2016 -0400

    ext4: use dget_parent() in ext4_file_open()
    
    commit 9dd78d8c9a7bd4bc341f5864db32d4331b8eae4c upstream.
    
    In f_op->open() lock on parent is not held, so there's no guarantee that
    parent dentry won't go away at any time.
    
    Even after this patch there's no guarantee that 'dir' will stay the parent
    of 'inode', but at least it won't be freed while being used.
    
    Fixes: ff978b09f973 ("ext4 crypto: move context consistency check to ext4_file_open()")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 022cb9388d1cad67f97d18e4e79047aa402aa6bb
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Mar 26 16:15:42 2016 -0400

    ext4 crypto: use dget_parent() in ext4_d_revalidate()
    
    commit 3d43bcfef5f0548845a425365011c499875491b0 upstream.
    
    This avoids potential problems caused by a race where the inode gets
    renamed out from its parent directory and the parent directory is
    deleted while ext4_d_revalidate() is running.
    
    Fixes: 28b4c263961c
    Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 385e5edc295f7feeef00c64f2f5c14b3530940ef
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Sat Mar 26 16:14:39 2016 -0400

    nfs: use file_dentry()
    
    commit be62a1a8fd116f5cd9e53726601f970e16e17558 upstream.
    
    NFS may be used as lower layer of overlayfs and accessing f_path.dentry can
    lead to a crash.
    
    Fix by replacing direct access of file->f_path.dentry with the
    file_dentry() accessor, which will always return a native object.
    
    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Tested-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Acked-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a20aeaa907f53bbb9cc881c6e4f8b3bb601bb27
Author: Miklos Szeredi <miklos@szeredi.hu>
Date:   Sat Mar 26 16:14:37 2016 -0400

    fs: add file_dentry()
    
    commit d101a125954eae1d397adda94ca6319485a50493 upstream.
    
    This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
    Make f_path always point to the overlay and f_inode to the underlay").
    
    Regular files opened on overlayfs will result in the file being opened on
    the underlying filesystem, while f_path points to the overlayfs
    mount/dentry.
    
    This confuses filesystems which get the dentry from struct file and assume
    it's theirs.
    
    Add a new helper, file_dentry() [*], to get the filesystem's own dentry
    from the file.  This checks file->f_path.dentry->d_flags against
    DCACHE_OP_REAL, and returns file->f_path.dentry if DCACHE_OP_REAL is not
    set (this is the common, non-overlayfs case).
    
    In the uncommon case it will call into overlayfs's ->d_real() to get the
    underlying dentry, matching file_inode(file).
    
    The reason we need to check against the inode is that if the file is copied
    up while being open, d_real() would return the upper dentry, while the open
    file comes from the lower dentry.
    
    [*] If possible, it's better simply to use file_inode() instead.
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Tested-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Reviewed-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cfb108d055a9c4ee9fffdcfa3481db9dc995d1c
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Mon Mar 28 21:18:56 2016 -0400

    sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes
    
    commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream.
    
    During revalidate we check whether device capacity has changed before we
    decide whether to output disk information or not.
    
    The check for old capacity failed to take into account that we scaled
    sdkp->capacity based on the reported logical block size. And therefore
    the capacity test would always fail for devices with sectors bigger than
    512 bytes and we would print several copies of the same discovery
    information.
    
    Avoid scaling sdkp->capacity and instead adjust the value on the fly
    when setting the block device capacity and generating fake C/H/S
    geometry.
    
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reported-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Hannes Reinicke <hare@suse.de>
    Reviewed-by: Ewan Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91b7796426a2e79040d9b05d62a0bda04e90cab4
Author: Irina Tirdea <irina.tirdea@intel.com>
Date:   Tue Mar 29 15:37:30 2016 +0300

    iio: gyro: bmg160: fix endianness when reading axes
    
    commit 95e7ff034175db7d8aefabe7716c4d42bea24fde upstream.
    
    For big endian platforms, reading the axes will return
    invalid values.
    
    The device stores each axis value in a 16 bit little
    endian register. The driver uses regmap_read_bulk to get
    the axis value, resulting in a 16 bit little endian value.
    This needs to be converted to cpu endianness to work
    on big endian platforms.
    
    Fix endianness for big endian platforms by converting
    the values for the axes read from little endian to
    cpu.
    
    This is also partially fixed in commit 82d8e5da1a33 ("iio:
    accel: bmg160: optimize transfers in trigger handler").
    
    Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a18addccce07241b3ba6b5ef6cd3a3d77d8c03d8
Author: Irina Tirdea <irina.tirdea@intel.com>
Date:   Mon Mar 28 20:15:46 2016 +0300

    iio: gyro: bmg160: fix buffer read values
    
    commit b475c59b113db1e66eb9527ffdec3c5241c847e5 upstream.
    
    When reading gyroscope axes using iio buffers, the values
    returned are always 0. In the interrupt handler, the return
    value of the read operation is returned to the user instead
    of the value read. Return the value read to the user.
    
    This is also fixed in commit 82d8e5da1a33 ("iio:
    accel: bmg160: optimize transfers in trigger handler").
    
    Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fad138bac5255f2eea9c05703506ea2cf7ad039
Author: Irina Tirdea <irina.tirdea@intel.com>
Date:   Tue Mar 29 15:35:45 2016 +0300

    iio: accel: bmc150: fix endianness when reading axes
    
    commit 2215f31dc6f88634c1916362e922b1ecdce0a6b3 upstream.
    
    For big endian platforms, reading the axes will return
    invalid values.
    
    The device stores each axis value in a 16 bit little
    endian register. The driver uses regmap_read_bulk to get
    the axis value, resulting in a 16 bit little endian value.
    This needs to be converted to cpu endianness to work
    on big endian platforms.
    
    Fix endianness for big endian platforms by converting
    the values for the axes read from little endian to
    cpu.
    
    This is also partially fixed in commit b6fb9b6d6552 ("iio:
    accel: bmc150: optimize transfers in trigger handler").
    
    Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f241a3bf956e4e059076ad3008fa2247c2a14f6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 29 22:27:27 2016 +0200

    iio: st_magn: always define ST_MAGN_TRIGGER_SET_STATE
    
    commit 9b090a98e95c2530ef0ce474e3b6218621b8ae25 upstream.
    
    When CONFIG_IIO_TRIGGER is enabled but CONFIG_IIO_BUFFER is
    not, we get a build error in the st_magn driver:
    
    drivers/iio/magnetometer/st_magn_core.c:573:23: error: 'ST_MAGN_TRIGGER_SET_STATE' undeclared here (not in a function)
      .set_trigger_state = ST_MAGN_TRIGGER_SET_STATE,
                           ^~~~~~~~~~~~~~~~~~~~~~~~~
    
    Apparently, this ST_MAGN_TRIGGER_SET_STATE macro was meant to
    be set to NULL when the definition is not available because
    st_magn_buffer.c is not compiled, but the alternative definition
    was not included in the original patch. This adds it.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: 74f5683f35fe ("iio: st_magn: Add irq trigger handling")
    Acked-by: Denis Ciocca <denis.ciocca@st.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f1aedb42713661b6e0376a5ccc7c9daaf77a901
Author: Irina Tirdea <irina.tirdea@intel.com>
Date:   Thu Mar 24 11:09:45 2016 +0200

    iio: fix config watermark initial value
    
    commit 1bef2c1d4e4fd92bdf8219b13ba97ba861618254 upstream.
    
    config structure is set to 0 when updating the buffers, so by
    default config->watermark will be 0. When computing the minimum
    between config->watermark and the buffer->watermark or
    insert_buffer-watermark, this will always be 0 regardless of the
    value set by the user for the buffer.
    
    Set as initial value for config->watermark the maximum allowed
    value so that the minimum value will always be set from one of the
    buffers.
    
    Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
    Fixes: f0566c0c405d ("iio: Set device watermark based on watermark of all
    attached buffers")
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdc0a7733accb6bddf5c636afafeb5feb0a748ab
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Mon Mar 14 02:55:45 2016 +0100

    ARM: 8550/1: protect idiv patching against undefined gcc behavior
    
    commit 208fae5c3b9431013ad7bcea07cbcee114e7d163 upstream.
    
    It was reported that a kernel with CONFIG_ARM_PATCH_IDIV=y stopped
    booting when compiled with the upcoming gcc 6.  Turns out that turning
    a function address into a writable array is undefined and gcc 6 decided
    it was OK to omit the store to the first word of the function while
    still preserving the store to the second word.
    
    Even though gcc 6 is now fixed to behave more coherently, it is a
    mystery that gcc 4 and gcc 5 actually produce wanted code in the kernel.
    And in fact the reduced test case to illustrate the issue does indeed
    break with gcc < 6 as well.
    
    In any case, let's guard the kernel against undefined compiler behavior
    by hiding the nature of the array location as suggested by gcc
    developers.
    
    Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70128
    
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Reported-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a41afe473be4f03c87b0797d3259aa3e62a6791
Author: Hannes Reinecke <hare@suse.de>
Date:   Fri Apr 1 08:57:36 2016 +0200

    scsi: Do not attach VPD to devices that don't support it
    
    commit 5ddfe0858ea7848c5d4efe3f4319e7543522e0ee upstream.
    
    The patch "scsi: rescan VPD attributes" introduced a regression in which
    devices that don't support VPD were being scanned for VPD attributes
    anyway.  This could cause issues for some devices and should be avoided
    so the check for scsi_level has been moved out of scsi_add_lun and into
    scsi_attach_vpd so that all callers will not scan VPD for devices that
    don't support it.
    
    [mkp: Merge fix]
    
    Fixes: 09e2b0b14690 ("scsi: rescan VPD attributes")
    Suggested-by: Alexander Duyck <aduyck@mirantis.com>
    Signed-off-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 558d9542f5f0bb893672fb2a8e57e8d8e4011ea4
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Apr 4 20:40:20 2016 +0900

    usb: renesas_usbhs: fix to avoid using a disabled ep in usbhsg_queue_done()
    
    commit 4fccb0767fdbdb781a9c5b5c15ee7b219443c89d upstream.
    
    This patch fixes an issue that usbhsg_queue_done() may cause kernel
    panic when dma callback is running and usb_ep_disable() is called
    by interrupt handler. (Especially, we can reproduce this issue using
    g_audio with usb-dmac driver.)
    
    For example of a flow:
     usbhsf_dma_complete (on tasklet)
      --> usbhsf_pkt_handler (on tasklet)
       --> usbhsg_queue_done (on tasklet)
        *** interrupt happened and usb_ep_disable() is called ***
        --> usbhsg_queue_pop (on tasklet)
         Then, oops happened.
    
    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5ad7e6fa53c454a646dd0e21044eee7de4ba5bb
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Mar 10 11:30:15 2016 +0900

    usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer
    
    commit 6490865c67825277b29638e839850882600b48ec upstream.
    
    This patch adds a code to surely disable TX IRQ of the pipe before
    starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
    may happen in rare cases when DMAC is used.
    
    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7628778a9cb06a7ec78d18a0ece64d195289376
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Mar 10 11:30:14 2016 +0900

    usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()
    
    commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 upstream.
    
    When unexpected situation happened (e.g. tx/rx irq happened while
    DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
    pointer dereference like the followings:
    
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c0004000
    [00000000] *pgd=00000000
    Internal error: Oops: 80000007 [#1] SMP ARM
    Modules linked in: usb_f_acm u_serial g_serial libcomposite
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
    Hardware name: Generic R8A7790 (Flattened Device Tree)
    task: c0729c00 ti: c0724000 task.ti: c0724000
    PC is at 0x0
    LR is at usbhsf_pkt_handler+0xac/0x118
    pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
    sp : c0725db8  ip : 00000000  fp : c0725df4
    r10: 00000001  r9 : 00000193  r8 : ef3ccab4
    r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
    r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4
    
    This patch adds a condition to avoid the dereference.
    
    Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08f056a7137716887e4059edc55d9e0abf414906
Author: Yong Li <sdliyong@gmail.com>
Date:   Wed Mar 30 14:49:14 2016 +0800

    gpio: pca953x: Use correct u16 value for register word write
    
    commit 9b8e3ec34318663affced3c14d960e78d760dd9a upstream.
    
    The current implementation only uses the first byte in val,
    the second byte is always 0. Change it to use cpu_to_le16
    to write the two bytes into the register
    
    Signed-off-by: Yong Li <sdliyong@gmail.com>
    Reviewed-by: Phil Reid <preid@electromag.com.au>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe4ed37cd9f8b0c065a6fc72e6005af5bebddb68
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Thu Jan 21 14:23:07 2016 +0100

    mac80211: fix txq queue related crashes
    
    commit 2a58d42c1e018ad514d4e23fd33fb2ded95d3ee6 upstream.
    
    The driver can access the queue simultanously
    while mac80211 tears down the interface. Without
    spinlock protection this could lead to corrupting
    sk_buff_head and subsequently to an invalid
    pointer dereference.
    
    Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation")
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76968881158ef16865bcbd0b8433fb4636e10779
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Mon Jan 25 14:43:24 2016 +0100

    mac80211: fix unnecessary frame drops in mesh fwding
    
    commit cf44012810ccdd8fd947518e965cb04b7b8498be upstream.
    
    The ieee80211_queue_stopped() expects hw queue
    number but it was given raw WMM AC number instead.
    
    This could cause frame drops and problems with
    traffic in some cases - most notably if driver
    doesn't map AC numbers to queue numbers 1:1 and
    uses ieee80211_stop_queues() and
    ieee80211_wake_queue() only without ever calling
    ieee80211_wake_queues().
    
    On ath10k it was possible to hit this problem in
    the following case:
    
      1. wlan0 uses queue 0
         (ath10k maps queues per vif)
      2. offchannel uses queue 15
      3. queues 1-14 are unused
      4. ieee80211_stop_queues()
      5. ieee80211_wake_queue(q=0)
      6. ieee80211_wake_queue(q=15)
         (other queues are not woken up because both
          driver and mac80211 know other queues are
          unused)
      7. ieee80211_rx_h_mesh_fwding()
      8. ieee80211_select_queue_80211() returns 2
      9. ieee80211_queue_stopped(q=2) returns true
     10. frame is dropped (oops!)
    
    Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping")
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ade3fb8e9dd8341b82abf29ed64919055ecabb04
Author: Sara Sharon <sara.sharon@intel.com>
Date:   Mon Jan 25 15:46:35 2016 +0200

    mac80211: fix ibss scan parameters
    
    commit d321cd014e51baab475efbdec468255b9e0ec822 upstream.
    
    When joining IBSS a full scan should be initiated in order to search
    for existing cell, unless the fixed_channel parameter was set.
    A default channel to create the IBSS on if no cell was found is
    provided as well.
    However - a scan is initiated only on the default channel provided
    regardless of whether ifibss->fixed_channel is set or not, with the
    obvious result of the cell not joining existing IBSS cell that is
    on another channel.
    
    Fixes: 76bed0f43b27 ("mac80211: IBSS fix scan request")
    Signed-off-by: Sara Sharon <sara.sharon@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea7cd6ee57fb6a176d666da6ec9e4a50a56dc6d5
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 26 23:05:31 2016 +0100

    mac80211: avoid excessive stack usage in sta_info
    
    commit 0ef049dc1167fe834d0ad5d63f89eddc5c70f6e4 upstream.
    
    When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
    function consumes more stack than normally, exceeding the
    1024 byte limit on ARM:
    
    net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
    net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    
    It turns out that there are two functions that put a 'struct station_info'
    on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and
    this structure alone requires up to 792 bytes.
    
    Hoping that both are called rarely enough, this replaces the
    on-stack structure with a dynamic allocation, which unfortunately
    requires some suboptimal error handling for out-of-memory.
    
    The __sta_info_destroy_part2 function is actually affected by the
    stack usage twice because it calls cfg80211_del_sta_sinfo(), which
    has another instance of struct station_info on its stack.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events")
    Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14361b4d6f74175e645c0872dea96ef1118716ea
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Mar 31 17:22:45 2016 +0200

    mac80211: properly deal with station hashtable insert errors
    
    commit 62b14b241ca6f790a17ccd9dd9f62ce1b006d406 upstream.
    
    The original hand-implemented hash-table in mac80211 couldn't result
    in insertion errors, and while converting to rhashtable I evidently
    forgot to check the errors.
    
    This surfaced now only because Ben is adding many identical keys and
    that resulted in hidden insertion errors.
    
    Fixes: 7bedd0cfad4e1 ("mac80211: use rhashtable for station table")
    Reported-by: Ben Greear <greearb@candelatech.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9657718bfdac29a5bdd4f3d3815979beda5b6e15
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Apr 3 15:23:37 2016 +0300

    virtio: virtio 1.0 cs04 spec compliance for reset
    
    commit 05dbcb430795b2e1fb1d5c757f8619d3dbed0a1c upstream.
    
    The spec says: after writing 0 to device_status, the driver MUST wait
    for a read of device_status to return 0 before reinitializing the
    device.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3913fd14951ffd515c391e75763ae38d88b46fc
Author: David Disseldorp <ddiss@suse.de>
Date:   Tue Apr 5 11:13:39 2016 +0200

    rbd: use GFP_NOIO consistently for request allocations
    
    commit 2224d879c7c0f85c14183ef82eb48bd875ceb599 upstream.
    
    As of 5a60e87603c4c533492c515b7f62578189b03c9c, RBD object request
    allocations are made via rbd_obj_request_create() with GFP_NOIO.
    However, subsequent OSD request allocations in rbd_osd_req_create*()
    use GFP_ATOMIC.
    
    With heavy page cache usage (e.g. OSDs running on same host as krbd
    client), rbd_osd_req_create() order-1 GFP_ATOMIC allocations have been
    observed to fail, where direct reclaim would have allowed GFP_NOIO
    allocations to succeed.
    
    Suggested-by: Vlastimil Babka <vbabka@suse.cz>
    Suggested-by: Neil Brown <neilb@suse.com>
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f1b1ba81ea124e4ba1d00644d1425da78336a5a
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Wed Mar 2 10:34:43 2016 +0100

    pcmcia: db1xxx_ss: fix last irq_to_gpio user
    
    commit e34b6fcf9b09ec9d93503edd5f81489791ffd602 upstream.
    
    remove the usage of removed irq_to_gpio() function.  On pre-DB1200
    boards, pass the actual carddetect GPIO number instead of the IRQ,
    because we need the gpio to actually test card status (inserted or
    not) and can get the irq number with gpio_to_irq() instead.
    
    Tested on DB1300 and DB1500, this patch fixes PCMCIA on the DB1500,
    which used irq_to_gpio().
    
    Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
    Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: linux-pcmcia@lists.infradead.org
    Cc: Linux-MIPS <linux-mips@linux-mips.org>
    Patchwork: https://patchwork.linux-mips.org/patch/12747/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d8f22445c494bcf49a5ff57eda4b8ac34818a2a
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Wed Sep 9 11:38:56 2015 -0300

    v4l: vsp1: Set the SRU CTRL0 register when starting the stream
    
    commit f6acfcdc5b8cdc9ddd53a459361820b9efe958c4 upstream.
    
    Commit 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity
    controllable during streaming") refactored the stream start code and
    removed the SRU CTRL0 register write by mistake. Add it back.
    
    Fixes: 58f896d859ce ("[media] v4l: vsp1: sru: Make the intensity controllable during streaming")
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ae078af8cbeacf66194b7b3bdd31911f11bde4e
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Fri Feb 26 08:21:35 2016 -0300

    coda: fix error path in case of missing pdata on non-DT platform
    
    commit bc717d5e92c8c079280eb4acbe335c6f25041aa2 upstream.
    
    If we bail out this early, v4l2_device_register() has not been called
    yet, so no need to call v4l2_device_unregister().
    
    Fixes: b7bd660a51f0 ("[media] coda: Call v4l2_device_unregister() from a single location")
    
    Reported-by: Michael Olbrich <m.olbrich@pengutronix.de>
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87a952d621b2597314220ba5a90db86aae8a6a11
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Tue Mar 22 09:21:57 2016 -0300

    au0828: Fix dev_state handling
    
    commit e8e3039f5b941f7825d335f8ca11c12a8104db11 upstream.
    
    The au0828 dev_state is actually a bit mask. It should not be
    checking with "==" but, instead, with a logic and. There are some
    places where it was doing it wrong.
    
    Fix that by replacing the dev_state set/clear/test with the
    bitops.
    
    As reviewed by Shuah:
    	"Looks good. Tested running bind/unbind au0828 loop for 1000 times.
    	Didn't see any problems and the v4l2_querycap() problem has been
    	fixed with this patch.
    
    	After the above test, ran bind/unbind snd_usb_audio 1000 times.
    	Didn't see any problems. Generated media graph and the graph
    	looks good."
    
    Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
    Tested-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3778578c59a727273ea14c9f01b8b123589f7329
Author: Shuah Khan <shuahkh@osg.samsung.com>
Date:   Tue Mar 22 01:04:05 2016 -0300

    au0828: fix au0828_v4l2_close() dev_state race condition
    
    commit ed940cd27416f9887864b95e1f8f8845aa9d6391 upstream.
    
    au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to
    detect the device disconnected state correctly, if au0828_v4l2_open() runs
    to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug
    by increasing the likelihood of au0828_v4l2_open() occurring while unbind
    is in progress. When au0828_v4l2_close() fails to detect that the device
    is in disconnect state, it attempts to power down the device and fails with
    the following general protection fault:
    
    [  260.992962] Call Trace:
    [  260.993008]  [<ffffffffa0f80f0f>] ? xc5000_sleep+0x8f/0xd0 [xc5000]
    [  260.993095]  [<ffffffffa0f6803c>] ? fe_standby+0x3c/0x50 [tuner]
    [  260.993186]  [<ffffffffa0ef541c>] au0828_v4l2_close+0x53c/0x620 [au0828]
    [  260.993298]  [<ffffffffa0d08ec0>] v4l2_release+0xf0/0x210 [videodev]
    [  260.993382]  [<ffffffff81570f9c>] __fput+0x1fc/0x6c0
    [  260.993449]  [<ffffffff815714ce>] ____fput+0xe/0x10
    [  260.993519]  [<ffffffff8116eb83>] task_work_run+0x133/0x1f0
    [  260.993602]  [<ffffffff810035d0>] exit_to_usermode_loop+0x140/0x170
    [  260.993681]  [<ffffffff810061ca>] syscall_return_slowpath+0x16a/0x1a0
    [  260.993754]  [<ffffffff82835fb3>] entry_SYSCALL_64_fastpath+0xa6/0xa8
    
    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 378219c76f7d9fe4cded8382b955cb8e82963705
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Tue Mar 29 10:04:00 2016 +0200

    gpio: pxa: fix legacy non pinctrl aware builds
    
    commit c4e5ffb6f224c1a4a9eaad82b19645ec22d1b24f upstream.
    
    In legacy pxa builds, ie. non device-tree and platform-data only builds,
    pinctrl is not yet available. As a consequence, the pinctrl gpio
    direction change function is a stub, returning always success.
    
    In the current state, the gpio driver direction function believes the
    pinctrl direction change was successful, and exits without actually
    changing the gpio direction.
    
    This patch changes the logic :
     - if the pinctrl direction function fails, gpio direction will report
       that failure
     - if the pinctrl direction function succeeds, gpio direction is changed
       by the gpio driver anyway.
       This is sub optimal in the pinctrl aware case, as the gpio direction
       will be changed twice: once by pinctrl function and another time by
       the gpio direction function.
    
    Yet it should be acceptable in this form, as this is functional for all
    pxa platforms (device-tree and platform-data), and moreover changing a
    gpio direction is very very seldom, usually in machine initialization,
    seldom in drivers probe, and an exception for ac97 reset bug.
    
    Fixes: a770d946371e ("gpio: pxa: add pin control gpio direction and request")
    Reported-by: Guenter Roeck <guenter@roeck-us.net>
    Tested-by: Guenter Roeck <guenter@roeck-us.net>
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a83977c7662d4410f6da7ffd1ff0d7725d7d2759
Author: Vladimir Zapolskiy <vz@mleia.com>
Date:   Wed Mar 9 02:45:36 2016 +0200

    pinctrl: freescale: imx: fix bogus check of of_iomap() return value
    
    commit 9a4f424531dabd877259ae0071b8bcc4dede9eb5 upstream.
    
    On error path of_iomap() returns NULL, hence IS_ERR() check is invalid
    and may cause a NULL pointer dereference, the change fixes this
    problem.
    
    While we are here invert a device node check to simplify the code.
    
    Fixes: 26d8cde5260b ("pinctrl: freescale: imx: add shared input select reg support")
    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
    Acked-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c6acf4f5107bfea3777dac54e743dc446fe8b88
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu Mar 24 13:15:45 2016 +0100

    pinctrl: nomadik: fix pull debug print inversion
    
    commit 6ee334559324a55725e22463de633b99ad99fcad upstream.
    
    Pull up was reported as pull down and vice versa. Fix this.
    
    Fixes: 8f1774a2a971 "pinctrl: nomadik: improve GPIO debug prints"
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e58d48e2822b4238d42edb993add4881cdd9d9d5
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Mar 12 19:44:57 2016 +0100

    pinctrl: sunxi: Fix A33 external interrupts not working
    
    commit 5e7515ba78fff2f5407eaa2f97c1d5c07801ac3d upstream.
    
    pinctrl-sun8i-a33.c (and the dts) declare only 2 interrupt banks,
    where as the closely related a23 has 3 banks. This matches with the
    datasheet for the A33 where only interrupt banks B and G are specified
    where as the A23 has banks A, B and G.
    
    However the A33 being the A23 derative it is means that the interrupt
    configure/status io-addresses for the 2 banks it has are not changed
    from the A23, iow they have the same address as if bank A was still
    present. Where as the sunxi pinctrl currently tries to use the A23 bank
    A addresses for bank B, since the pinctrl code does not know about the
    removed bank A.
    
    Add a irq_bank_base parameter and use this where appropriate to take
    the missing bank A into account.
    
    This fixes external interrupts not working on the A33 (tested with
    an i2c touchscreen controller which uses an external interrupt).
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25198da237ff51d0189f8fa07462700ad2eb2c67
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Mon Mar 7 19:40:57 2016 +0100

    pinctrl: sh-pfc: only use dummy states for non-DT platforms
    
    commit 0129801be4b87226bf502f18f5a9eabd356d1058 upstream.
    
    If pinctrl_provide_dummies() is used unconditionally, then the dummy
    state will be used even on DT platforms when the "init" state was
    intentionally left out. Instead of "default", the dummy "init" state
    will then be used during probe. Thus, when probing an I2C controller on
    cold boot, communication triggered by bus notifiers broke because the
    pins were not initialized.
    
    Do it like OMAP2: use the dummy state only for non-DT platforms.
    
    Fixes: ef0eebc05130 ("drivers/pinctrl: Add the concept of an "init" state")
    Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84f588689e208793627ada9bdf9419dbfcd9a63a
Author: Govindraj Raja <Govindraj.Raja@imgtec.com>
Date:   Fri Mar 4 15:28:22 2016 +0000

    pinctrl: pistachio: fix mfio84-89 function description and pinmux.
    
    commit e9adb336d0bf391be23e820975ca5cd12c31d781 upstream.
    
    mfio 84 to 89 are described wrongly, fix it to describe
    the right pin and add them to right pin-mux group.
    
    The correct order is:
    	pll1_lock => mips_pll	-- MFIO_83
    	pll2_lock => audio_pll	-- MFIO_84
    	pll3_lock => rpu_v_pll	-- MFIO_85
    	pll4_lock => rpu_l_pll	-- MFIO_86
    	pll5_lock => sys_pll	-- MFIO_87
    	pll6_lock => wifi_pll	-- MFIO_88
    	pll7_lock => bt_pll	-- MFIO_89
    
    Cc: linux-gpio@vger.kernel.org
    Cc: devicetree@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: James Hartley <James.Hartley@imgtec.com>
    Fixes: cefc03e5995e("pinctrl: Add Pistachio SoC pin control driver")
    Signed-off-by: Govindraj Raja <Govindraj.Raja@imgtec.com>
    Acked-by: Andrew Bresticker <abrestic@chromium.org>
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 255ad7b0fbd66ee34437d550bac5c4554315fad6
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Wed Feb 3 03:35:49 2016 +0000

    MIPS: Fix MSA ld unaligned failure cases
    
    commit fa8ff601d72bad3078ddf5ef17a5547700d06908 upstream.
    
    Copying the content of an MSA vector from user memory may involve TLB
    faults & mapping in pages. This will fail when preemption is disabled
    due to an inability to acquire mmap_sem from do_page_fault, which meant
    such vector loads to unmapped pages would always fail to be emulated.
    Fix this by disabling preemption later only around the updating of
    vector register state.
    
    This change does however introduce a race between performing the load
    into thread context & the thread being preempted, saving its current
    live context & clobbering the loaded value. This should be a rare
    occureence, so optimise for the fast path by simply repeating the load if
    we are preempted.
    
    Additionally if the copy failed then the failure path was taken with
    preemption left disabled, leading to the kernel typically encountering
    further issues around sleeping whilst atomic. The change to where
    preemption is disabled avoids this issue.
    
    Fixes: e4aa1f153add "MIPS: MSA unaligned memory access support"
    Reported-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
    Cc: Maciej W. Rozycki <macro@linux-mips.org>
    Cc: James Cowgill <James.Cowgill@imgtec.com>
    Cc: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/12345/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62f6c6ff167df2da0b15012707602233eb22e8ef
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Mar 29 17:56:57 2016 +0200

    KVM: x86: reduce default value of halt_poll_ns parameter
    
    commit 14ebda3394fd3e5388747e742e510b0802a65d24 upstream.
    
    Windows lets applications choose the frequency of the timer tick,
    and in Windows 10 the maximum rate was changed from 1024 Hz to
    2048 Hz.  Unfortunately, because of the way the Windows API
    works, most applications who need a higher rate than the default
    64 Hz will just do
    
       timeGetDevCaps(&tc, sizeof(tc));
       timeBeginPeriod(tc.wPeriodMin);
    
    and pick the maximum rate.  This causes very high CPU usage when
    playing media or games on Windows 10, even if the guest does not
    actually use the CPU very much, because the frequent timer tick
    causes halt_poll_ns to kick in.
    
    There is no really good solution, especially because Microsoft
    could sooner or later bump the limit to 4096 Hz, but for now
    the best we can do is lower a bit the upper limit for
    halt_poll_ns. :-(
    
    Reported-by: Jon Panozzo <jonp@lime-technology.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4680eb3978ba46bdf3be74d85b9a736468ad1c70
Author: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
Date:   Thu Mar 24 05:17:03 2016 +0000

    KVM: x86: Inject pending interrupt even if pending nmi exist
    
    commit 321c5658c5e9192dea0d58ab67cf1791e45b2b26 upstream.
    
    Non maskable interrupts (NMI) are preferred to interrupts in current
    implementation. If a NMI is pending and NMI is blocked by the result
    of nmi_allowed(), pending interrupt is not injected and
    enable_irq_window() is not executed, even if interrupts injection is
    allowed.
    
    In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
    In this case, interrupts are needed to execute iret that intends end
    of NMI. The flag of blocking new NMI is not cleared until the guest
    execute the iret, and interrupts are blocked by pending NMI. Due to
    this, iret can't be invoked in the guest, and the guest is starved
    until block is cleared by some events (e.g. canceling injection).
    
    This patch injects pending interrupts, when it's allowed, even if NMI
    is blocked. And, If an interrupts is pending after executing
    inject_pending_event(), enable_irq_window() is executed regardless of
    NMI pending counter.
    
    Signed-off-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0838ed602d46fc4778020cd7a6ba073652b72cb
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Apr 12 12:27:09 2016 +0200

    USB: uas: Add a new NO_REPORT_LUNS quirk
    
    commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa upstream.
    
    Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
    an usb-id of: 0bc2:331a, as these will fail to respond to a
    REPORT_LUNS command.
    
    Reported-and-tested-by: David Webb <djw@noc.ac.uk>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39f0cd2c3f4fced06b50f1451250c3b38c16b0ed
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Apr 12 12:27:08 2016 +0200

    USB: uas: Limit qdepth at the scsi-host level
    
    commit 198de51dbc3454d95b015ca0a055b673f85f01bb upstream.
    
    Commit 64d513ac31bd ("scsi: use host wide tags by default") causes
    the SCSI core to queue more commands then we can handle on devices with
    multiple LUNs, limit the queue depth at the scsi-host level instead of
    per slave to fix this.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1315013
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa4dae941ecaf5ccab2ca282909ac30dfc2df477
Author: Roopa Prabhu <roopa@cumulusnetworks.com>
Date:   Thu Apr 7 21:28:38 2016 -0700

    mpls: find_outdev: check for err ptr in addition to NULL check
    
    [ Upstream commit 94a57f1f8a9de90ab4b0f8748361ff8be706c80c ]
    
    find_outdev calls inet{,6}_fib_lookup_dev() or dev_get_by_index() to
    find the output device. In case of an error, inet{,6}_fib_lookup_dev()
    returns error pointer and dev_get_by_index() returns NULL. But the function
    only checks for NULL and thus can end up calling dev_put on an ERR_PTR.
    This patch adds an additional check for err ptr after the NULL check.
    
    Before: Trying to add an mpls route with no oif from user, no available
    path to 10.1.1.8 and no default route:
    $ip -f mpls route add 100 as 200 via inet 10.1.1.8
    [  822.337195] BUG: unable to handle kernel NULL pointer dereference at
    00000000000003a3
    [  822.340033] IP: [<ffffffff8148781e>] mpls_nh_assign_dev+0x10b/0x182
    [  822.340033] PGD 1db38067 PUD 1de9e067 PMD 0
    [  822.340033] Oops: 0000 [#1] SMP
    [  822.340033] Modules linked in:
    [  822.340033] CPU: 0 PID: 11148 Comm: ip Not tainted 4.5.0-rc7+ #54
    [  822.340033] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org
    04/01/2014
    [  822.340033] task: ffff88001db82580 ti: ffff88001dad4000 task.ti:
    ffff88001dad4000
    [  822.340033] RIP: 0010:[<ffffffff8148781e>]  [<ffffffff8148781e>]
    mpls_nh_assign_dev+0x10b/0x182
    [  822.340033] RSP: 0018:ffff88001dad7a88  EFLAGS: 00010282
    [  822.340033] RAX: ffffffffffffff9b RBX: ffffffffffffff9b RCX:
    0000000000000002
    [  822.340033] RDX: 00000000ffffff9b RSI: 0000000000000008 RDI:
    0000000000000000
    [  822.340033] RBP: ffff88001ddc9ea0 R08: ffff88001e9f1768 R09:
    0000000000000000
    [  822.340033] R10: ffff88001d9c1100 R11: ffff88001e3c89f0 R12:
    ffffffff8187e0c0
    [  822.340033] R13: ffffffff8187e0c0 R14: ffff88001ddc9e80 R15:
    0000000000000004
    [  822.340033] FS:  00007ff9ed798700(0000) GS:ffff88001fc00000(0000)
    knlGS:0000000000000000
    [  822.340033] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  822.340033] CR2: 00000000000003a3 CR3: 000000001de89000 CR4:
    00000000000006f0
    [  822.340033] Stack:
    [  822.340033]  0000000000000000 0000000100000000 0000000000000000
    0000000000000000
    [  822.340033]  0000000000000000 0801010a00000000 0000000000000000
    0000000000000000
    [  822.340033]  0000000000000004 ffffffff8148749b ffffffff8187e0c0
    000000000000001c
    [  822.340033] Call Trace:
    [  822.340033]  [<ffffffff8148749b>] ? mpls_rt_alloc+0x2b/0x3e
    [  822.340033]  [<ffffffff81488e66>] ? mpls_rtm_newroute+0x358/0x3e2
    [  822.340033]  [<ffffffff810e7bbc>] ? get_page+0x5/0xa
    [  822.340033]  [<ffffffff813b7d94>] ? rtnetlink_rcv_msg+0x17e/0x191
    [  822.340033]  [<ffffffff8111794e>] ? __kmalloc_track_caller+0x8c/0x9e
    [  822.340033]  [<ffffffff813c9393>] ?
    rht_key_hashfn.isra.20.constprop.57+0x14/0x1f
    [  822.340033]  [<ffffffff813b7c16>] ? __rtnl_unlock+0xc/0xc
    [  822.340033]  [<ffffffff813cb794>] ? netlink_rcv_skb+0x36/0x82
    [  822.340033]  [<ffffffff813b4507>] ? rtnetlink_rcv+0x1f/0x28
    [  822.340033]  [<ffffffff813cb2b1>] ? netlink_unicast+0x106/0x189
    [  822.340033]  [<ffffffff813cb5b3>] ? netlink_sendmsg+0x27f/0x2c8
    [  822.340033]  [<ffffffff81392ede>] ? sock_sendmsg_nosec+0x10/0x1b
    [  822.340033]  [<ffffffff81393df1>] ? ___sys_sendmsg+0x182/0x1e3
    [  822.340033]  [<ffffffff810e4f35>] ?
    __alloc_pages_nodemask+0x11c/0x1e4
    [  822.340033]  [<ffffffff8110619c>] ? PageAnon+0x5/0xd
    [  822.340033]  [<ffffffff811062fe>] ? __page_set_anon_rmap+0x45/0x52
    [  822.340033]  [<ffffffff810e7bbc>] ? get_page+0x5/0xa
    [  822.340033]  [<ffffffff810e85ab>] ? __lru_cache_add+0x1a/0x3a
    [  822.340033]  [<ffffffff81087ea9>] ? current_kernel_time64+0x9/0x30
    [  822.340033]  [<ffffffff813940c4>] ? __sys_sendmsg+0x3c/0x5a
    [  822.340033]  [<ffffffff8148f597>] ?
    entry_SYSCALL_64_fastpath+0x12/0x6a
    [  822.340033] Code: 83 08 04 00 00 65 ff 00 48 8b 3c 24 e8 40 7c f2 ff
    eb 13 48 c7 c3 9f ff ff ff eb 0f 89 ce e8 f1 ae f1 ff 48 89 c3 48 85 db
    74 15 <48> 8b 83 08 04 00 00 65 ff 08 48 81 fb 00 f0 ff ff 76 0d eb 07
    [  822.340033] RIP  [<ffffffff8148781e>] mpls_nh_assign_dev+0x10b/0x182
    [  822.340033]  RSP <ffff88001dad7a88>
    [  822.340033] CR2: 00000000000003a3
    [  822.435363] ---[ end trace 98cc65e6f6b8bf11 ]---
    
    After patch:
    $ip -f mpls route add 100 as 200 via inet 10.1.1.8
    RTNETLINK answers: Network is unreachable
    
    Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
    Reported-by: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24acc7bc681a667f5ce4d5629c435de62503cdf0
Author: Jakub Sitnicki <jkbs@redhat.com>
Date:   Tue Apr 5 18:41:08 2016 +0200

    ipv6: Count in extension headers in skb->network_header
    
    [ Upstream commit 3ba3458fb9c050718b95275a3310b74415e767e2 ]
    
    When sending a UDPv6 message longer than MTU, account for the length
    of fragmentable IPv6 extension headers in skb->network_header offset.
    Same as we do in alloc_new_skb path in __ip6_append_data().
    
    This ensures that later on __ip6_make_skb() will make space in
    headroom for fragmentable extension headers:
    
    	/* move skb->data to ip header from ext header */
    	if (skb->data < skb_network_header(skb))
    		__skb_pull(skb, skb_network_offset(skb));
    
    Prevents a splat due to skb_under_panic:
    
    skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \
    head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo
    ------------[ cut here ]------------
    kernel BUG at net/core/skbuff.c:104!
    invalid opcode: 0000 [#1] KASAN
    CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65
    [...]
    Call Trace:
     [<ffffffff813eb7b9>] skb_push+0x79/0x80
     [<ffffffff8143397b>] eth_header+0x2b/0x100
     [<ffffffff8141e0d0>] neigh_resolve_output+0x210/0x310
     [<ffffffff814eab77>] ip6_finish_output2+0x4a7/0x7c0
     [<ffffffff814efe3a>] ip6_output+0x16a/0x280
     [<ffffffff815440c1>] ip6_local_out+0xb1/0xf0
     [<ffffffff814f1115>] ip6_send_skb+0x45/0xd0
     [<ffffffff81518836>] udp_v6_send_skb+0x246/0x5d0
     [<ffffffff8151985e>] udpv6_sendmsg+0xa6e/0x1090
    [...]
    
    Reported-by: Ji Jianwen <jiji@redhat.com>
    Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 671e3ae22e9bbde7d5f999bde211f4e44c26ad5c
Author: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Date:   Fri Apr 1 17:17:50 2016 -0300

    ip6_tunnel: set rtnl_link_ops before calling register_netdevice
    
    [ Upstream commit b6ee376cb0b7fb4e7e07d6cd248bd40436fb9ba6 ]
    
    When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
    before ip6_tnl_create2 is called. When register_netdevice is called, there
    is no linkinfo attribute in the NEWLINK message because of that.
    
    Setting rtnl_link_ops before calling register_netdevice fixes that.
    
    Fixes: 0b112457229d ("ip6tnl: add support of link creation via rtnl")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 896fff1039fdb00daa4b1db45339236144504ee7
Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date:   Sun Apr 3 22:09:24 2016 +0800

    ipv6: l2tp: fix a potential issue in l2tp_ip6_recv
    
    [ Upstream commit be447f305494e019dfc37ea4cdf3b0e4200b4eba ]
    
    pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
    right place.
    
    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 169af15e93de7974ca3a5ff9b7149034fae96bfc
Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date:   Sun Apr 3 22:09:23 2016 +0800

    ipv4: l2tp: fix a potential issue in l2tp_ip_recv
    
    [ Upstream commit 5745b8232e942abd5e16e85fa9b27cc21324acf0 ]
    
    pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
    right place.
    
    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 502ef3a17da463efe3ab31646db5cf5f52b120be
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri Apr 8 13:26:48 2016 +0800

    tuntap: restore default qdisc
    
    [ Upstream commit 016adb7260f481168c03e09f785184d6d5278894 ]
    
    After commit f84bb1eac027 ("net: fix IFF_NO_QUEUE for drivers using
    alloc_netdev"), default qdisc was changed to noqueue because
    tuntap does not set tx_queue_len during .setup(). This patch restores
    default qdisc by setting tx_queue_len in tun_setup().
    
    Fixes: f84bb1eac027 ("net: fix IFF_NO_QUEUE for drivers using alloc_netdev")
    Cc: Phil Sutter <phil@nwl.cc>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e5fcb436d81a8a85aca0e3e4f33f145df92654f
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Mar 31 02:13:18 2016 +0200

    tun, bpf: fix suspicious RCU usage in tun_{attach, detach}_filter
    
    [ Upstream commit 5a5abb1fa3b05dd6aa821525832644c1e7d2905f ]
    
    Sasha Levin reported a suspicious rcu_dereference_protected() warning
    found while fuzzing with trinity that is similar to this one:
    
      [   52.765684] net/core/filter.c:2262 suspicious rcu_dereference_protected() usage!
      [   52.765688] other info that might help us debug this:
      [   52.765695] rcu_scheduler_active = 1, debug_locks = 1
      [   52.765701] 1 lock held by a.out/1525:
      [   52.765704]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff816a64b7>] rtnl_lock+0x17/0x20
      [   52.765721] stack backtrace:
      [   52.765728] CPU: 1 PID: 1525 Comm: a.out Not tainted 4.5.0+ #264
      [...]
      [   52.765768] Call Trace:
      [   52.765775]  [<ffffffff813e488d>] dump_stack+0x85/0xc8
      [   52.765784]  [<ffffffff810f2fa5>] lockdep_rcu_suspicious+0xd5/0x110
      [   52.765792]  [<ffffffff816afdc2>] sk_detach_filter+0x82/0x90
      [   52.765801]  [<ffffffffa0883425>] tun_detach_filter+0x35/0x90 [tun]
      [   52.765810]  [<ffffffffa0884ed4>] __tun_chr_ioctl+0x354/0x1130 [tun]
      [   52.765818]  [<ffffffff8136fed0>] ? selinux_file_ioctl+0x130/0x210
      [   52.765827]  [<ffffffffa0885ce3>] tun_chr_ioctl+0x13/0x20 [tun]
      [   52.765834]  [<ffffffff81260ea6>] do_vfs_ioctl+0x96/0x690
      [   52.765843]  [<ffffffff81364af3>] ? security_file_ioctl+0x43/0x60
      [   52.765850]  [<ffffffff81261519>] SyS_ioctl+0x79/0x90
      [   52.765858]  [<ffffffff81003ba2>] do_syscall_64+0x62/0x140
      [   52.765866]  [<ffffffff817d563f>] entry_SYSCALL64_slow_path+0x25/0x25
    
    Same can be triggered with PROVE_RCU (+ PROVE_RCU_REPEATEDLY) enabled
    from tun_attach_filter() when user space calls ioctl(tun_fd, TUN{ATTACH,
    DETACH}FILTER, ...) for adding/removing a BPF filter on tap devices.
    
    Since the fix in f91ff5b9ff52 ("net: sk_{detach|attach}_filter() rcu
    fixes") sk_attach_filter()/sk_detach_filter() now dereferences the
    filter with rcu_dereference_protected(), checking whether socket lock
    is held in control path.
    
    Since its introduction in 994051625981 ("tun: socket filter support"),
    tap filters are managed under RTNL lock from __tun_chr_ioctl(). Thus the
    sock_owned_by_user(sk) doesn't apply in this specific case and therefore
    triggers the false positive.
    
    Extend the BPF API with __sk_attach_filter()/__sk_detach_filter() pair
    that is used by tap filters and pass in lockdep_rtnl_is_held() for the
    rcu_dereference_protected() checks instead.
    
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcdf4d30bf48b1cf93611053d09bde9579cb67ee
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Thu Mar 31 18:10:31 2016 +0200

    rtnl: fix msg size calculation in if_nlmsg_size()
    
    [ Upstream commit c57c7a95da842807b475b823ed2e5435c42cb3b0 ]
    
    Size of the attribute IFLA_PHYS_PORT_NAME was missing.
    
    Fixes: db24a9044ee1 ("net: add support for phys_port_name")
    CC: David Ahern <dsahern@gmail.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Acked-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d69e91bb7693e14aea7bd2974baf908f6c61dbf
Author: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date:   Tue Mar 29 18:48:08 2016 +0800

    bridge: Allow set bridge ageing time when switchdev disabled
    
    [ Upstream commit 5e263f712691615fb802f06c98d7638c378f5d11 ]
    
    When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP,
    we should ignore this error code and continue to set the ageing time.
    
    Fixes: c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev")
    Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
    Acked-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0527ab3c6fd97a8c69b0613a140710efd4b94f16
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 29 08:43:41 2016 -0700

    ipv6: udp: fix UDP_MIB_IGNOREDMULTI updates
    
    [ Upstream commit 2d4212261fdf13e29728ddb5ea9d60c342cc92b5 ]
    
    IPv6 counters updates use a different macro than IPv4.
    
    Fixes: 36cbb2452cbaf ("udp: Increment UDP_MIB_IGNOREDMULTI for arriving unmatched multicasts")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Rick Jones <rick.jones2@hp.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 007f94a9f21fd22b1e95ce3b3a50f3b1360b38cd
Author: Bjørn Mork <bjorn@mork.no>
Date:   Mon Mar 28 22:38:16 2016 +0200

    qmi_wwan: add "D-Link DWM-221 B1" device id
    
    [ Upstream commit e84810c7b85a2d7897797b3ad3e879168a8e032a ]
    
    Thomas reports:
    "Windows:
    
    00 diagnostics
    01 modem
    02 at-port
    03 nmea
    04 nic
    
    Linux:
    
    T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2001 ProdID=7e19 Rev=02.32
    S:  Manufacturer=Mobile Connect
    S:  Product=Mobile Connect
    S:  SerialNumber=0123456789ABCDEF
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
    
    Reported-by: Thomas Schäfer <tschaefer@t-online.de>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a4981d58f5ba007292fca970c3621e66d39b0850
Author: subashab@codeaurora.org <subashab@codeaurora.org>
Date:   Wed Mar 23 22:39:50 2016 -0600

    xfrm: Fix crash observed during device unregistration and decryption
    
    [ Upstream commit 071d36bf21bcc837be00cea55bcef8d129e7f609 ]
    
    A crash is observed when a decrypted packet is processed in receive
    path. get_rps_cpus() tries to dereference the skb->dev fields but it
    appears that the device is freed from the poison pattern.
    
    [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
    [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
    [<ffffffc000af6094>] netif_rx+0x74/0x94
    [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
    [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
    [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
    [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
    [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
    [<ffffffc0000bb40c>] kthread+0xe0/0xec
    
    -013|get_rps_cpu(
         |    dev = 0xFFFFFFC08B688000,
         |    skb = 0xFFFFFFC0C76AAC00 -> (
         |      dev = 0xFFFFFFC08B688000 -> (
         |        name =
    "......................................................
         |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
    0xAAAAAAAAAAA
    
    Following are the sequence of events observed -
    
    - Encrypted packet in receive path from netdevice is queued
    - Encrypted packet queued for decryption (asynchronous)
    - Netdevice brought down and freed
    - Packet is decrypted and returned through callback in esp_input_done
    - Packet is queued again for process in network stack using netif_rx
    
    Since the device appears to have been freed, the dereference of
    skb->dev in get_rps_cpus() leads to an unhandled page fault
    exception.
    
    Fix this by holding on to device reference when queueing packets
    asynchronously and releasing the reference on call back return.
    
    v2: Make the change generic to xfrm as mentioned by Steffen and
    update the title to xfrm
    
    Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Jerome Stanislaus <jeromes@codeaurora.org>
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1d87a48fa9731247424675f6abc5daba74ec3f8
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Mar 23 16:38:55 2016 +0100

    ppp: take reference on channels netns
    
    [ Upstream commit 1f461dcdd296eecedaffffc6bae2bfa90bd7eb89 ]
    
    Let channels hold a reference on their network namespace.
    Some channel types, like ppp_async and ppp_synctty, can have their
    userspace controller running in a different namespace. Therefore they
    can't rely on them to preclude their netns from being removed from
    under them.
    
    ==================================================================
    BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
    addr ffff880064e217e0
    Read of size 8 by task syz-executor/11581
    =============================================================================
    BUG net_namespace (Not tainted): kasan: bad access detected
    -----------------------------------------------------------------------------
    
    Disabling lock debugging due to kernel taint
    INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
    [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
    [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
    [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
    [<     inline     >] slab_alloc kernel/mm/slub.c:2574
    [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
    [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
    [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
    [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
    [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
    [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
    [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
    [<     inline     >] copy_process kernel/kernel/fork.c:1274
    [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
    [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
    [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
    [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
    
    INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
    [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
    [<     inline     >] slab_free kernel/mm/slub.c:2805
    [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
    [<     inline     >] net_free kernel/net/core/net_namespace.c:341
    [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
    [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
    [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
    [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
    [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
    [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
    INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
    flags=0x5fffc0000004080
    INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
    
    CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
     00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
     ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
     ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
    Call Trace:
     [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
     [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
     [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
     [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
     [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
     [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
     [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
     [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
     [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
     [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
     [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
     [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
     [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
     [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
     [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
     [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
     [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
     [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
     [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
     [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
     [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
     [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
     [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
     [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
     [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
     [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
     [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
     [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
     [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
     [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
     [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
     [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
     [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
     [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
     [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
     [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
     [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
     [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
     [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
     [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
     [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
     [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
     [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
     [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
     [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
     [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
    Memory state around the buggy address:
     ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                           ^
     ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2")
    Reported-by: Baozeng Ding <sploving1@gmail.com>
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e577c96d333c15236ad84c9a5f646c340f8511a
Author: Lance Richardson <lrichard@redhat.com>
Date:   Tue Mar 22 14:56:57 2016 -0400

    ipv4: initialize flowi4_flags before calling fib_lookup()
    
    [ Upstream commit 4cfc86f3dae6ca38ed49cdd78f458a03d4d87992 ]
    
    Field fl4.flowi4_flags is not initialized in fib_compute_spec_dst()
    before calling fib_lookup(), which means fib_table_lookup() is
    using non-deterministic data at this line:
    
    	if (!(flp->flowi4_flags & FLOWI_FLAG_SKIP_NH_OIF)) {
    
    Fix by initializing the entire fl4 structure, which will prevent
    similar issues as fields are added in the future by ensuring that
    all fields are initialized to zero unless explicitly initialized
    to another value.
    
    Fixes: 58189ca7b2741 ("net: Fix vti use case with oif in dst lookups")
    Suggested-by: David Ahern <dsa@cumulusnetworks.com>
    Signed-off-by: Lance Richardson <lrichard@redhat.com>
    Acked-by: David Ahern <dsa@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80c8349309b96570655c08e6f82a42e89b59a3e8
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Mar 22 09:19:38 2016 +0100

    ipv4: fix broadcast packets reception
    
    [ Upstream commit ad0ea1989cc4d5905941d0a9e62c63ad6d859cef ]
    
    Currently, ingress ipv4 broadcast datagrams are dropped since,
    in udp_v4_early_demux(), ip_check_mc_rcu() is invoked even on
    bcast packets.
    
    This patch addresses the issue, invoking ip_check_mc_rcu()
    only for mcast packets.
    
    Fixes: 6e5403093261 ("ipv4/udp: Verify multicast group is ours in upd_v4_early_demux()")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfc733f2e3814819da23114fef3d6afe11dca889
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 17 17:23:36 2016 -0700

    bonding: fix bond_get_stats()
    
    [ Upstream commit fe30937b65354c7fec244caebbdaae68e28ca797 ]
    
    bond_get_stats() can be called from rtnetlink (with RTNL held)
    or from /proc/net/dev seq handler (with RCU held)
    
    The logic added in commit 5f0c5f73e5ef ("bonding: make global bonding
    stats more reliable") kind of assumed only one cpu could run there.
    
    If multiple threads are reading /proc/net/dev, stats can be really
    messed up after a while.
    
    A second problem is that some fields are 32bit, so we need to properly
    handle the wrap around problem.
    
    Given that RTNL is not always held, we need to use
    bond_for_each_slave_rcu().
    
    Fixes: 5f0c5f73e5ef ("bonding: make global bonding stats more reliable")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
    Cc: Jay Vosburgh <j.vosburgh@gmail.com>
    Cc: Veaceslav Falico <vfalico@gmail.com>
    Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e6466976f61fa492bc89adbea6ab02adff38655
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 17 11:57:06 2016 -0700

    net: bcmgenet: fix dma api length mismatch
    
    [ Upstream commit eee577232203842b4dcadb7ab477a298479633ed ]
    
    When un-mapping skb->data in __bcmgenet_tx_reclaim(),
    we must use the length that was used in original dma_map_single(),
    instead of skb->len that might be bigger (includes the frags)
    
    We simply can store skb_len into tx_cb_ptr->dma_len and use it
    at unmap time.
    
    Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4a69bcc051851d52e1fddc65698187d5a99aabd
Author: Manish Chopra <manish.chopra@qlogic.com>
Date:   Tue Mar 15 07:13:45 2016 -0400

    qlge: Fix receive packets drop.
    
    [ Upstream commit 2c9a266afefe137bff06bbe0fc48b4d3b3cb348c ]
    
    When running small packets [length < 256 bytes] traffic, packets were
    being dropped due to invalid data in those packets which were
    delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
    ensures copying latest and updated data into skb from the receive buffer.
    
    Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
    Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21603edb087fcc2ed53e9000fb4aa1fa072cbe32
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 16 22:52:15 2016 -0700

    tcp/dccp: remove obsolete WARN_ON() in icmp handlers
    
    [ Upstream commit e316ea62e3203d524ff0239a40c56d3a39ad1b5c ]
    
    Now SYN_RECV request sockets are installed in ehash table, an ICMP
    handler can find a request socket while another cpu handles an incoming
    packet transforming this SYN_RECV request socket into an ESTABLISHED
    socket.
    
    We need to remove the now obsolete WARN_ON(req->sk), since req->sk
    is set when a new child is created and added into listener accept queue.
    
    If this race happens, the ICMP will do nothing special.
    
    Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Ben Lazarus <blazarus@google.com>
    Reported-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85bd3c9ed95df9535f02510005daf839c9ee1323
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Mon Mar 14 21:17:16 2016 +0100

    ppp: ensure file->private_data can't be overridden
    
    [ Upstream commit e8e56ffd9d2973398b60ece1f1bebb8d67b4d032 ]
    
    Locking ppp_mutex must be done before dereferencing file->private_data,
    otherwise it could be modified before ppp_unattached_ioctl() takes the
    lock. This could lead ppp_unattached_ioctl() to override ->private_data,
    thus leaking reference to the ppp_file previously pointed to.
    
    v2: lock all ppp_ioctl() instead of just checking private_data in
        ppp_unattached_ioctl(), to avoid ambiguous behaviour.
    
    Fixes: f3ff8a4d80e8 ("ppp: push BKL down into the driver")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51775f3da4437095675329fe9bd23ca579197ff2
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date:   Sat Mar 12 18:44:17 2016 +0100

    net: mvneta: Fix spinlock usage
    
    [ Upstream commit 1c2722a975fdb8c90bc6ba8570b7fb62db4e2e9c ]
    
    In the previous patch, the spinlock was not initialized. While it didn't
    cause any trouble yet it could be a problem to use it uninitialized.
    
    The most annoying part was the critical section protected by the spinlock
    in mvneta_stop(). Some of the functions could sleep as pointed when
    activated CONFIG_DEBUG_ATOMIC_SLEEP. Actually, in mvneta_stop() we only
    need to protect the is_stopped flagged, indeed the code of the notifier
    for CPU online is protected by the same spinlock, so when we get the
    lock, the notifer work is done.
    
    Reported-by: Patrick Uiterwijk <patrick@puiterwijk.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03cbd08593beff8d7d3e51c68079e4414e50fcca
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 14 15:18:36 2016 +0100

    ath9k: fix buffer overrun for ar9287
    
    [ Upstream commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 ]
    
    Code that was added back in 2.6.38 has an obvious overflow
    when accessing a static array, and at the time it was added
    only a code comment was put in front of it as a reminder
    to have it reviewed properly.
    
    This has not happened, but gcc-6 now points to the specific
    overflow:
    
    drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
    drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
         maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
                       ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
    
    It turns out that the correct array length exists in the local
    'intercepts' variable of this function, so we can just use that
    instead of hardcoding '4', so this patch changes all three
    instances to use that variable. The other two instances were
    already correct, but it's more consistent this way.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa92212be81f8fa97285bc1525cfde4e2dd25d5f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 14 15:18:35 2016 +0100

    farsync: fix off-by-one bug in fst_add_one
    
    [ Upstream commit e725a66c0202b5f36c2f9d59d26a65c53bbf21f7 ]
    
    gcc-6 finds an out of bounds access in the fst_add_one function
    when calculating the end of the mmio area:
    
    drivers/net/wan/farsync.c: In function 'fst_add_one':
    drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds]
     #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                                         ^
    include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof'
      __builtin_offsetof(a, b)
                         ^
    drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof'
     #define BUF_OFFSET(X)   (BFM_BASE + offsetof(struct buf_window, X))
                                         ^~~~~~~~
    drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET'
                                      + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]);
                                        ^~~~~~~~~~
    
    The warning is correct, but not critical because this appears
    to be a write-only variable that is set by each WAN driver but
    never accessed afterwards.
    
    I'm taking the minimal fix here, using the correct pointer by
    pointing 'mem_end' to the last byte inside of the register area
    as all other WAN drivers do, rather than the first byte outside of
    it. An alternative would be to just remove the mem_end member
    entirely.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21a38de78a7ea440a6ffcb574fc9cc0b6ca4e7d4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 14 15:18:34 2016 +0100

    mlx4: add missing braces in verify_qp_parameters
    
    [ Upstream commit baefd7015cdb304ce6c94f9679d0486c71954766 ]
    
    The implementation of QP paravirtualization back in linux-3.7 included
    some code that looks very dubious, and gcc-6 has grown smart enough
    to warn about it:
    
    drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters':
    drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation]
         if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) {
         ^~
    drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not
        if (slave != mlx4_master_func_num(dev))
    
    >From looking at the context, I'm reasonably sure that the indentation
    is correct but that it should have contained curly braces from the
    start, as the update_gid() function in the same patch correctly does.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Fixes: 54679e148287 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86de5ca8bb61875d92ee8d5c5531839fe8f47199
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Mar 14 09:56:35 2016 -0300

    net: Fix use after free in the recvmmsg exit path
    
    [ Upstream commit 34b88a68f26a75e4fded796f1a49c40f82234b7d ]
    
    The syzkaller fuzzer hit the following use-after-free:
    
      Call Trace:
       [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
       [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
       [<     inline     >] SYSC_recvmmsg net/socket.c:2281
       [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
       [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
      arch/x86/entry/entry_64.S:185
    
    And, as Dmitry rightly assessed, that is because we can drop the
    reference and then touch it when the underlying recvmsg calls return
    some packets and then hit an error, which will make recvmmsg to set
    sock->sk->sk_err, oops, fix it.
    
    Reported-and-Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall")
    http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e52e21995ae66be8ce5c97bf715e2a66f622af1
Author: David S. Miller <davem@davemloft.net>
Date:   Sun Mar 13 23:28:00 2016 -0400

    ipv4: Don't do expensive useless work during inetdev destroy.
    
    [ Upstream commit fbd40ea0180a2d328c5adc61414dc8bab9335ce2 ]
    
    When an inetdev is destroyed, every address assigned to the interface
    is removed.  And in this scenerio we do two pointless things which can
    be very expensive if the number of assigned interfaces is large:
    
    1) Address promotion.  We are deleting all addresses, so there is no
       point in doing this.
    
    2) A full nf conntrack table purge for every address.  We only need to
       do this once, as is already caught by the existing
       masq_dev_notifier so masq_inet_event() can skip this.
    
    Reported-by: Solar Designer <solar@openwall.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eee4e8dbed78e7727856bcb7797344e22c0304cc
Author: Stephen Hemminger <shemming@brocade.com>
Date:   Tue Mar 8 12:59:35 2016 -0800

    bridge: allow zero ageing time
    
    [ Upstream commit 4c656c13b254d598e83e586b7b4d36a2043dad85 ]
    
    This fixes a regression in the bridge ageing time caused by:
    commit c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev")
    
    There are users of Linux bridge which use the feature that if ageing time
    is set to 0 it causes entries to never expire. See:
      https://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
    
    For a pure software bridge, it is unnecessary for the code to have
    arbitrary restrictions on what values are allowable.
    
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f48c2d6d84113193a63182a7907c843dc877917f
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Tue Mar 8 12:59:34 2016 -0800

    rocker: set FDB cleanup timer according to lowest ageing time
    
    [ Upstream commit 88de1cd457e5cb664d6d437e2ea4750d089165f5 ]
    
    In rocker, ageing time is a per-port attribute, so the next time the FDB
    cleanup timer fires should be set according to the lowest ageing time.
    
    This will later allow us to delete the BR_MIN_AGEING_TIME macro, which was
    added to guarantee minimum ageing time in the bridge layer, thereby breaking
    existing behavior.
    
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca8f5ad64b68646d4739772736a8be59bf636b10
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Tue Mar 8 12:59:33 2016 -0800

    mlxsw: spectrum: Check requested ageing time is valid
    
    [ Upstream commit 869f63a4d28144c03c8f4a4c0d1e8f31f8c11a10 ]
    
    Commit c62987bbd8a1 ("bridge: push bridge setting ageing_time down to
    switchdev") added a check for minimum and maximum ageing time, but this
    breaks existing behaviour where one can set ageing time to 0 for a
    non-learning bridge.
    
    Push this check down to the driver and allow the check in the bridge
    layer to be removed. Currently ageing time 0 is refused by the driver,
    but we can later add support for this functionality.
    
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 866fdf66d246e453072a7e004c60f6c9c6c0f4bc
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Mar 8 15:18:54 2016 -0500

    macvtap: always pass ethernet header in linear
    
    [ Upstream commit 8e2ad4113ce4671686740f808ff2795395c39eef ]
    
    The stack expects link layer headers in the skb linear section.
    Macvtap can create skbs with llheader in frags in edge cases:
    when (IFF_VNET_HDR is off or vnet_hdr.hdr_len < ETH_HLEN) and
    prepad + len > PAGE_SIZE and vnet_hdr.flags has no or bad csum.
    
    Add checks to ensure linear is always at least ETH_HLEN.
    At this point, len is already ensured to be >= ETH_HLEN.
    
    For backwards compatiblity, rounds up short vnet_hdr.hdr_len.
    This differs from tap and packet, which return an error.
    
    Fixes b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79ad48ee3ce1c3ab186465a6e741cb38a1f0d748
Author: Rajesh Borundia <rajesh.borundia@qlogic.com>
Date:   Tue Mar 8 02:39:58 2016 -0500

    qlcnic: Fix mailbox completion handling during spurious interrupt
    
    [ Upstream commit 819bfe764dceec2f6b4551768453f374b4c60443 ]
    
    o While the driver is in the middle of a MB completion processing
    and it receives a spurious MB interrupt, it is mistaken as a good MB
    completion interrupt leading to premature completion of the next MB
    request. Fix the driver to guard against this by checking the current
    state of MB processing and ignore the spurious interrupt.
    Also added a stats counter to record this condition.
    
    Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c452fb448228962ec81c0ef5b61c48b26d6072b2
Author: Rajesh Borundia <rajesh.borundia@qlogic.com>
Date:   Tue Mar 8 02:39:57 2016 -0500

    qlcnic: Remove unnecessary usage of atomic_t
    
    [ Upstream commit 5bf93251cee1fb66141d1d2eaff86e04a9397bdf ]
    
    o atomic_t usage is incorrect as we are not implementing
    any atomicity.
    
    Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c8425b16eff3d572fd74e5b9a1835846e34fbf8
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Tue Mar 8 01:37:09 2016 +0300

    sh_eth: advance 'rxdesc' later in sh_eth_ring_format()
    
    [ Upstream commit d0ba913488dc8c55d1880f5ed34f096dc45fb05d ]
    
    Iff dma_map_single() fails, 'rxdesc'  should point  to the last filled RX
    descriptor, so  that it can be marked as the last one, however the driver
    would have  already  advanced it by that time. In order to fix that, only
    fill  an RX descriptor  once all the data for it is ready.
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07d90b9ccc3e1dffe9aeaeb959b53fc19f3a3144
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Tue Mar 8 01:36:28 2016 +0300

    sh_eth: fix NULL pointer dereference in sh_eth_ring_format()
    
    [ Upstream commit c1b7fca65070bfadca94dd53a4e6b71cd4f69715 ]
    
    In a low memory situation, if netdev_alloc_skb() fails on a first RX ring
    loop iteration  in sh_eth_ring_format(), 'rxdesc' is still NULL.  Avoid
    kernel oops by adding the 'rxdesc' check after the loop.
    
    Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56c06e33284eb012a33c9f5b81fc639373a3177b
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Tue Mar 8 10:36:20 2016 +0100

    net: dsa: Fix cleanup resources upon module removal
    
    [ Upstream commit 04761890a7cec6a1ff9aafd909004da4fe8059db ]
    
    The initial commit badly merged into the dsa_resume method instead
    of the dsa_remove_dst method.
    As consequence, the dst->master_netdev->dsa_ptr is not set to NULL on
    removal and re-bind of the dsa device fails with error -17.
    
    Fixes: b0dc635d923c ("net: dsa: cleanup resources upon module removal ")
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Acked-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e39dbc400134aa7b44bff859b222801f3d16a2a
Author: Alexei Starovoitov <ast@fb.com>
Date:   Wed Mar 9 20:02:33 2016 -0800

    bpf: avoid copying junk bytes in bpf_get_current_comm()
    
    [ Upstream commit cdc4e47da8f4c32eeb6b2061a8a834f4362a12b7 ]
    
    Lots of places in the kernel use memcpy(buf, comm, TASK_COMM_LEN); but
    the result is typically passed to print("%s", buf) and extra bytes
    after zero don't cause any harm.
    In bpf the result of bpf_get_current_comm() is used as the part of
    map key and was causing spurious hash map mismatches.
    Use strlcpy() to guarantee zero-terminated string.
    bpf verifier checks that output buffer is zero-initialized,
    so even for short task names the output buffer don't have junk bytes.
    Note it's not a security concern, since kprobe+bpf is root only.
    
    Fixes: ffeedafbf023 ("bpf: introduce current->pid, tgid, uid, gid, comm accessors")
    Reported-by: Tobias Waldekranz <tobias@waldekranz.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3d511df0c233a975579ca6cbb930e518b770adb
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Mar 9 21:58:34 2016 -0500

    packet: validate variable length ll headers
    
    [ Upstream commit 9ed988cd591500c040b2a6257bc68543e08ceeef ]
    
    Replace link layer header validation check ll_header_truncate with
    more generic dev_validate_header.
    
    Validation based on hard_header_len incorrectly drops valid packets
    in variable length protocols, such as AX25. dev_validate_header
    calls header_ops.validate for such protocols to ensure correctness
    below hard_header_len.
    
    See also http://comments.gmane.org/gmane.linux.network/401064
    
    Fixes 9c7077622dd9 ("packet: make packet_snd fail on len smaller than l2 header")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4d1bf367516520e863ab170f24ed6ba3da8b7ba
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Mar 9 21:58:33 2016 -0500

    ax25: add link layer header validation function
    
    [ Upstream commit ea47781c26510e5d97f80f9aceafe9065bd5e3aa ]
    
    As variable length protocol, AX25 fails link layer header validation
    tests based on a minimum length. header_ops.validate allows protocols
    to validate headers that are shorter than hard_header_len. Implement
    this callback for AX25.
    
    See also http://comments.gmane.org/gmane.linux.network/401064
    
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6804052fa9d86e9a512c88b24a5debbfc1a490fc
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Mar 9 21:58:32 2016 -0500

    net: validate variable length ll headers
    
    [ Upstream commit 2793a23aacbd754dbbb5cb75093deb7e4103bace ]
    
    Netdevice parameter hard_header_len is variously interpreted both as
    an upper and lower bound on link layer header length. The field is
    used as upper bound when reserving room at allocation, as lower bound
    when validating user input in PF_PACKET.
    
    Clarify the definition to be maximum header length. For validation
    of untrusted headers, add an optional validate member to header_ops.
    
    Allow bypassing of validation by passing CAP_SYS_RAWIO, for instance
    for deliberate testing of corrupt input. In this case, pad trailing
    bytes, as some device drivers expect completely initialized headers.
    
    See also http://comments.gmane.org/gmane.linux.network/401064
    
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 696512cdec221077cab289f95d437a5237e780fe
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Fri Mar 18 10:11:07 2016 -0400

    xen/events: Mask a moving irq
    
    commit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 upstream.
    
    Moving an unmasked irq may result in irq handler being invoked on both
    source and target CPUs.
    
    With 2-level this can happen as follows:
    
    On source CPU:
            evtchn_2l_handle_events() ->
                generic_handle_irq() ->
                    handle_edge_irq() ->
                       eoi_pirq():
                           irq_move_irq(data);
    
                           /***** WE ARE HERE *****/
    
                           if (VALID_EVTCHN(evtchn))
                               clear_evtchn(evtchn);
    
    If at this moment target processor is handling an unrelated event in
    evtchn_2l_handle_events()'s loop it may pick up our event since target's
    cpu_evtchn_mask claims that this event belongs to it *and* the event is
    unmasked and still pending. At the same time, source CPU will continue
    executing its own handle_edge_irq().
    
    With FIFO interrupt the scenario is similar: irq_move_irq() may result
    in a EVTCHNOP_unmask hypercall which, in turn, may make the event
    pending on the target CPU.
    
    We can avoid this situation by moving and clearing the event while
    keeping event masked.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a59228baec2fdf0988b055fab5bf30947c9cfa0
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Mar 31 16:41:32 2016 -0400

    drm/amdgpu/gmc: use proper register for vram type on Fiji
    
    commit b634de4f446c062a0c95ec4d150b4cf7c85e3526 upstream.
    
    The offset changed on Fiji.
    
    Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab1fd9c1cc47e0b63abb374a3b9ab1151d705848
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Mar 31 16:07:38 2016 -0400

    drm/amdgpu/gmc: move vram type fetching into sw_init
    
    commit d1518a1db31a25682ea09c4b135fa72d9883be42 upstream.
    
    early_init gets called before atom asic init so on non-posted
    cards, the vram type is not initialized.
    
    Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b5fc48897a995d4ef6ccd17a7e56e793d74c5a5
Author: Rex Zhu <Rex.Zhu@amd.com>
Date:   Tue Mar 29 13:21:59 2016 +0800

    drm/amd/powerplay: fix segment fault issue in multi-display case.
    
    commit f9e9c08e20d71cabef7d5c2a7eb75e1d953dad16 upstream.
    
    Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
    Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a788dd0289d871ebd244ebba37beae357a90cba
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 28 10:21:20 2016 -0400

    drm/radeon: add a dpm quirk for all R7 370 parts
    
    commit 0e5585dc870af947fab2af96a88c2d8b4270247c upstream.
    
    Higher mclk values are not stable due to a bug somewhere.
    Limit them for now.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7538f068735b408d9ba30ff20f0d0221c871ce5
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 28 10:16:40 2016 -0400

    drm/radeon: add another R7 370 quirk
    
    commit a64663d9870364bd2a2df62bf0d3a9fbe5ea62a8 upstream.
    
    bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=115291
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d365f023049753c2104371dc685f0cf7f9fb866
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Mar 25 10:31:04 2016 -0400

    drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5
    
    commit f971f2263deaa4a441e377b385c11aee0f3b3f9a upstream.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=94692
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dc33f4d0e677259432655a706eccaa7e31db5db
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 30 11:40:43 2016 +0200

    drm/udl: Use unlocked gem unreferencing
    
    commit 72b9ff0612ad8fc969b910cd00ac16b57a1a9ba4 upstream.
    
    For drm_gem_object_unreference callers are required to hold
    dev->struct_mutex, which these paths don't. Enforcing this requirement
    has become a bit more strict with
    
    commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Thu Oct 15 09:36:25 2015 +0200
    
        drm/gem: Check locking in drm_gem_object_unreference
    
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1890e72bf7b89584c48ab0ebdf1cfd57dab8b6e7
Author: Rob Clark <robdclark@gmail.com>
Date:   Thu Feb 25 16:15:05 2016 -0500

    drm/dp: move hw_mutex up the call stack
    
    commit 7779c5e23c5132c22a219f1f5554ef81dd15ee91 upstream.
    
    1) don't let other threads trying to bang on aux channel interrupt the
    defer timeout/logic
    2) don't let other threads interrupt the i2c over aux logic
    
    Technically, according to people who actually have the DP spec, this
    should not be required.  In practice, it makes some troublesome Dell
    monitor (and perhaps others) work, so probably a case of "It's compliant
    if it works with windows" on the hw vendor's part..
    
    v2: rebased to come before DPCD/AUX logging patch for easier backport
    to stable branches.
    
    Reported-by: Dave Wysochanski <dwysocha@redhat.com>
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274157
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37c536c3ee72b847426034d6619bb12f173c5e23
Author: James Morse <james.morse@arm.com>
Date:   Thu Mar 24 16:54:34 2016 +0000

    arm64: opcodes.h: Add arm big-endian config options before including arm header
    
    commit a6002ec5a8c68e69706b2efd6db6d682d0ab672c upstream.
    
    arm and arm64 use different config options to specify big endian. This
    needs taking into account when including code/headers between the two
    architectures.
    
    A case in point is PAN, which uses the __instr_arm() macro to output
    instructions. The macro comes from opcodes.h, which lives under arch/arm.
    On a big-endian build the mismatched config options mean the instruction
    isn't byte swapped correctly, resulting in undefined instruction exceptions
    during boot:
    
    | alternatives: patching kernel code
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc0004505b4
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | kdevtmpfs[87]: undefined instruction: pc=ffffffc00076231c
    | Internal error: Oops - undefined instruction: 0 [#1] SMP
    | Modules linked in:
    | CPU: 0 PID: 87 Comm: kdevtmpfs Not tainted 4.1.16+ #5
    | Hardware name: Hisilicon PhosphorHi1382 EVB (DT)
    | task: ffffffc336591700 ti: ffffffc3365a4000 task.ti: ffffffc3365a4000
    | PC is at dump_instr+0x68/0x100
    | LR is at do_undefinstr+0x1d4/0x2a4
    | pc : [<ffffffc00076231c>] lr : [<ffffffc0000811d4>] pstate: 604001c5
    | sp : ffffffc3365a6450
    
    Reported-by: Hanjun Guo <guohanjun@huawei.com>
    Tested-by: Xuefeng Wang <wxf.wang@hisilicon.com>
    Signed-off-by: James Morse <james.morse@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ae608d6abb98390ba34854821d3d10e23640a6a
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Mar 31 09:38:51 2016 +0200

    compiler-gcc: disable -ftracer for __noclone functions
    
    commit 95272c29378ee7dc15f43fa2758cb28a5913a06d upstream.
    
    -ftracer can duplicate asm blocks causing compilation to fail in
    noclone functions.  For example, KVM declares a global variable
    in an asm like
    
        asm("2: ... \n
             .pushsection data \n
             .global vmx_return \n
             vmx_return: .long 2b");
    
    and -ftracer causes a double declaration.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Michal Marek <mmarek@suse.cz>
    Cc: kvm@vger.kernel.org
    Reported-by: Linda Walsh <lkml@tlinx.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c4d3fbe16cb7241cc18bc4b8a121d5c5ea6d4b6
Author: Oliver O'Halloran <oohall@gmail.com>
Date:   Tue Mar 8 09:08:47 2016 +1100

    powerpc/process: Fix altivec SPR not being saved
    
    commit 01d7c2a2de47890934faba91a71d183795e4348d upstream.
    
    In save_sprs() in process.c contains the following test:
    
    	if (cpu_has_feature(cpu_has_feature(CPU_FTR_ALTIVEC)))
    		t->vrsave = mfspr(SPRN_VRSAVE);
    
    CPU feature with the mask 0x1 is CPU_FTR_COHERENT_ICACHE so the test
    is equivilent to:
    
    	if (cpu_has_feature(CPU_FTR_ALTIVEC) &&
    		cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
    
    On CPUs without support for both (i.e G5) this results in vrsave not
    being saved between context switches. The vector register save/restore
    code doesn't use VRSAVE to determine which registers to save/restore,
    but the value of VRSAVE is used to determine if altivec is being used
    in several code paths.
    
    Fixes: 152d523e6307 ("powerpc: Create context switch helpers save_sprs() and restore_sprs()")
    Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90ad05df5acc44fda7c8c315fdf9d758791ed376
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Apr 7 19:59:27 2016 -0700

    libnvdimm, pfn: fix uuid validation
    
    commit e5670563f588ed1c0603819350c0f02cec23f5c5 upstream.
    
    If we detect a namespace has a stale info block in the init path, we
    should overwrite with the latest configuration.  In fact, we already
    return -ENODEV when the parent uuid is invalid, the same should be done
    for the 'self' uuid.  Otherwise we can get into a condition where
    userspace is unable to reconfigure the pfn-device without directly /
    manually invalidating the info block.
    
    Reported-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 333b72e9252332c72ed5c5dbcf1dd8145c1856c6
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Apr 7 19:58:44 2016 -0700

    libnvdimm: fix smart data retrieval
    
    commit 211291126698c8f047617565b2e2e7f822f86354 upstream.
    
    It appears that smart data retrieval has been broken the since the
    initial implementation.  Fix the payload size to be 128-bytes per the
    specification.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37828ff8b8d1437a0165c6373608d7715bb63fc9
Author: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Date:   Thu Mar 17 15:00:04 2016 +0100

    s390/mm: handle PTE-mapped tail pages in fast gup
    
    commit fc897c95e91451271cd707ee0f71022b9b201ce9 upstream.
    
    With the THP refcounting rework it is possible to see THP compound tail
    pages mapped with PTEs during a THP split. This needs to be considered
    when using page_cache_get_speculative(), which will always fail on tail
    pages because ->_count is always zero. commit 7aef4172 "mm: handle
    PTE-mapped tail pages in gerneric fast gup implementaiton" fixed it for
    the generic fast gup code by using compound_head(page) instead of page,
    but not for s390.
    
    This patch is a 1:1 adaption of commit 7aef4172 for the s390 fast gup
    code. Without this fix, gup will fall back to the slow path or fail
    in the unlikely scenario that we hit a THP under splitting in-between
    the page table split and the compound page split.
    
    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>

commit 0e345ced4b17c379dc91f8117e920fd40fa9f06f
Author: Sebastian Siewior <bigeasy@linutronix.de>
Date:   Tue Mar 8 10:03:56 2016 +0100

    powerpc/mm: Fixup preempt underflow with huge pages
    
    commit 08a5bb2921e490939f78f38fd0d02858bb709942 upstream.
    
    hugepd_free() used __get_cpu_var() once. Nothing ensured that the code
    accessing the variable did not migrate from one CPU to another and soon
    this was noticed by Tiejun Chen in 94b09d755462 ("powerpc/hugetlb:
    Replace __get_cpu_var with get_cpu_var"). So we had it fixed.
    
    Christoph Lameter was doing his __get_cpu_var() replaces and forgot
    PowerPC. Then he noticed this and sent his fixed up batch again which
    got applied as 69111bac42f5 ("powerpc: Replace __get_cpu_var uses").
    
    The careful reader will noticed one little detail: get_cpu_var() got
    replaced with this_cpu_ptr(). So now we have a put_cpu_var() which does
    a preempt_enable() and nothing that does preempt_disable() so we
    underflow the preempt counter.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Christoph Lameter <cl@linux.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16808319c000657dc8236b25f1ef0f1847cb6872
Author: Xishi Qiu <qiuxishi@huawei.com>
Date:   Fri Apr 1 14:31:20 2016 -0700

    mm: fix invalid node in alloc_migrate_target()
    
    commit 6f25a14a7053b69917e2ebea0d31dd444cd31fd5 upstream.
    
    It is incorrect to use next_node to find a target node, it will return
    MAX_NUMNODES or invalid node.  This will lead to crash in buddy system
    allocation.
    
    Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
    Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Joonsoo Kim <js1304@gmail.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: "Laura Abbott" <lauraa@codeaurora.org>
    Cc: Hui Zhu <zhuhui@xiaomi.com>
    Cc: Wang Xiaoqiang <wangxq10@lzu.edu.cn>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a748f8431f4e5de8eba1a4bf9f014025c80c3d76
Author: Hui Wang <hui.wang@canonical.com>
Date:   Fri Apr 1 11:00:15 2016 +0800

    ALSA: hda - fix front mic problem for a HP desktop
    
    commit e549d190f7b5f94e9ab36bd965028112914d010d upstream.
    
    The front mic jack (pink color) can't detect any plug or unplug. After
    applying this fix, both detecting function and recording function
    work well.
    
    BugLink: https://bugs.launchpad.net/bugs/1564712
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56fdf25fb02188e0137705ee2f477e36b82c677e
Author: Bobi Mihalca <bobbymihalca@touchtech.ro>
Date:   Wed Mar 23 13:32:33 2016 +0200

    ALSA: hda - Apply fix for white noise on Asus N550JV, too
    
    commit 83a9efb5b8170b7cffef4f62656656e1d8ad2ccd upstream.
    
    Apply the new fixup that is used for ASUS N750JV to another similar
    model, N500JV, too, for reducing the headphone noise.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181
    Signed-off-by: Bobi Mihalca <bobbymihalca@touchtech.ro>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdad3cd93d7ad3013f961e7c6d3bafbced4ecd64
Author: Bobi Mihalca <bobbymihalca@touchtech.ro>
Date:   Wed Mar 23 13:26:11 2016 +0200

    ALSA: hda - Fix white noise on Asus N750JV headphone
    
    commit 9d4dc5840f93bcb002fa311693349deae7702bc5 upstream.
    
    For reducing the noise from the headphone output on ASUS N750JV,
    call the existing fixup, alc_fixup_auto_mute_via_amp(), additionally.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181
    Signed-off-by: Bobi Mihalca <bobbymihalca@touchtech.ro>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ef546876d4a84a6d39a8f4a55e440df975990b9
Author: Bobi Mihalca <bobbymihalca@touchtech.ro>
Date:   Wed Mar 23 13:23:55 2016 +0200

    ALSA: hda - Asus N750JV external subwoofer fixup
    
    commit 70cf2cbd685e218c3ffd105d9fb6cf0f8d767481 upstream.
    
    ASUS N750JV needs the same fixup as N550 for enabling its subwoofer.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=115181
    Signed-off-by: Bobi Mihalca <bobbymihalca@touchtech.ro>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 304fd1f0dbee6cc9c0afc31455dcb51bd463f136
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Apr 1 12:28:16 2016 +0200

    ALSA: timer: Use mod_timer() for rearming the system timer
    
    commit 4a07083ed613644c96c34a7dd2853dc5d7c70902 upstream.
    
    ALSA system timer backend stops the timer via del_timer() without sync
    and leaves del_timer_sync() at the close instead.  This is because of
    the restriction by the design of ALSA timer: namely, the stop callback
    may be called from the timer handler, and calling the sync shall lead
    to a hangup.  However, this also triggers a kernel BUG() when the
    timer is rearmed immediately after stopping without sync:
     kernel BUG at kernel/time/timer.c:966!
     Call Trace:
      <IRQ>
      [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
      [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
      [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
      [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
      [<ffffffff81296b72>] call_timer_fn+0x162/0x520
      [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
      [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
      ....
    
    It's the place where add_timer() checks the pending timer.  It's clear
    that this may happen after the immediate restart without sync in our
    cases.
    
    So, the workaround here is just to use mod_timer() instead of
    add_timer().  This looks like a band-aid fix, but it's a right move,
    as snd_timer_interrupt() takes care of the continuous rearm of timer.
    
    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23e52d58f376cfed2d4d5b8b4789d3bf7ce5360a
Author: Helge Deller <deller@gmx.de>
Date:   Fri Apr 8 18:32:52 2016 +0200

    parisc: Unbreak handling exceptions from kernel modules
    
    commit 2ef4dfd9d9f288943e249b78365a69e3ea3ec072 upstream.
    
    Handling exceptions from modules never worked on parisc.
    It was just masked by the fact that exceptions from modules
    don't happen during normal use.
    
    When a module triggers an exception in get_user() we need to load the
    main kernel dp value before accessing the exception_data structure, and
    afterwards restore the original dp value of the module on exit.
    
    Noticed-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1abe5c5fa89d2730a6f4d4b1aaa3f847e5adeaa7
Author: Helge Deller <deller@gmx.de>
Date:   Fri Apr 8 18:18:48 2016 +0200

    parisc: Fix kernel crash with reversed copy_from_user()
    
    commit ef72f3110d8b19f4c098a0bff7ed7d11945e70c6 upstream.
    
    The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
    crash on parisc if the parameters for copy_from_user were reversed
    ("illegal reversed copy_to_user" testcase).
    
    Fix this potential crash by checking the fault handler if the faulting
    address is in the exception table.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2279582391ad6202b596f67f3e4beafed8546cea
Author: Helge Deller <deller@gmx.de>
Date:   Fri Apr 8 18:11:33 2016 +0200

    parisc: Avoid function pointers for kernel exception routines
    
    commit e3893027a300927049efc1572f852201eb785142 upstream.
    
    We want to avoid the kernel module loader to create function pointers
    for the kernel fixup routines of get_user() and put_user(). Changing
    the external reference from function type to int type fixes this.
    
    This unbreaks exception handling for get_user() and put_user() when
    called from a kernel module.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab1a2a3a655519c535771c6571ddb04093a289f5
Author: Helge Deller <deller@gmx.de>
Date:   Wed Mar 30 14:14:31 2016 +0200

    parisc: Fix and enable seccomp filter support
    
    commit 910cd32e552ea09caa89cdbe328e468979b030dd upstream.
    
    The seccomp filter support requires careful handling of task registers.  This
    includes reloading of the return value (%r28) and proper syscall exit if
    secure_computing() returned -1.
    
    Additionally we need to sign-extend the syscall number from signed 32bit to
    signed 64bit in do_syscall_trace_enter() since the ptrace interface only allows
    storing 32bit values in compat mode.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ec5ff2af50260b82a4db7ae9caf0a47d52f6e9c
Author: Helge Deller <deller@gmx.de>
Date:   Wed Mar 30 14:11:50 2016 +0200

    parisc: Fix SIGSYS signals in compat case
    
    commit 4f4acc9472e54ce702f1d85fc9e6d57767dec91f upstream.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79fa1ebcc06c4c7a9ef6a0c57a4dcaa2c9c6de4b
Author: Nicolai Stange <nicstange@gmail.com>
Date:   Sun Mar 20 23:23:46 2016 +0100

    PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument
    
    commit e54358915d0a00399c11c2c23ae1be674cba188a upstream.
    
    Despite what the DocBook comment to pkcs7_validate_trust() says, the
    *_trusted argument is never set to false.
    
    pkcs7_validate_trust() only positively sets *_trusted upon encountering
    a trusted PKCS#7 SignedInfo block.
    
    This is quite unfortunate since its callers, system_verify_data() for
    example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust.
    
    Indeed, UBSAN splats when attempting to load the uninitialized local
    variable 'trusted' from system_verify_data() in pkcs7_validate_trust():
    
      UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14
      load of value 82 is not a valid value for type '_Bool'
      [...]
      Call Trace:
        [<ffffffff818c4d35>] dump_stack+0xbc/0x117
        [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
        [<ffffffff8194113b>] ubsan_epilogue+0xd/0x4e
        [<ffffffff819419fa>] __ubsan_handle_load_invalid_value+0x111/0x158
        [<ffffffff819418e9>] ? val_to_string.constprop.12+0xcf/0xcf
        [<ffffffff818334a4>] ? x509_request_asymmetric_key+0x114/0x370
        [<ffffffff814b83f0>] ? kfree+0x220/0x370
        [<ffffffff818312c2>] ? public_key_verify_signature_2+0x32/0x50
        [<ffffffff81835e04>] pkcs7_validate_trust+0x524/0x5f0
        [<ffffffff813c391a>] system_verify_data+0xca/0x170
        [<ffffffff813c3850>] ? top_trace_array+0x9b/0x9b
        [<ffffffff81510b29>] ? __vfs_read+0x279/0x3d0
        [<ffffffff8129372f>] mod_verify_sig+0x1ff/0x290
        [...]
    
    The implication is that pkcs7_validate_trust() effectively grants trust
    when it really shouldn't have.
    
    Fix this by explicitly setting *_trusted to false at the very beginning
    of pkcs7_validate_trust().
    
    Signed-off-by: Nicolai Stange <nicstange@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c341f99281451c18771f9d32f5be740aa425b689
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Mar 26 12:28:05 2016 -0700

    hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated
    
    commit 3c2e2266a5bd2d1cef258e6e54dca1d99946379f upstream.
    
    arm:pxa_defconfig can result in the following crash if the max1111 driver
    is not instantiated.
    
    Unhandled fault: page domain fault (0x01b) at 0x00000000
    pgd = c0004000
    [00000000] *pgd=00000000
    Internal error: : 1b [#1] PREEMPT ARM
    Modules linked in:
    CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680407c #10
    Hardware name: SHARP Akita
    Workqueue: events sharpsl_charge_toggle
    task: c390a000 ti: c391e000 task.ti: c391e000
    PC is at max1111_read_channel+0x20/0x30
    LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
    pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
    ...
    [<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
    					(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)
    [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
    					(spitzpm_read_devdata+0x5c/0xc4)
    [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
    					(sharpsl_check_battery_temp+0x78/0x110)
    [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
    					(sharpsl_charge_toggle+0x48/0x110)
    [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
    					(process_one_work+0x14c/0x48c)
    [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
    [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
    [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)
    
    This can occur because the SPI controller driver (SPI_PXA2XX) is built as
    module and thus not necessarily loaded. While building SPI_PXA2XX into the
    kernel would make the problem disappear, it appears prudent to ensure that
    the driver is instantiated before accessing its data structures.
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>