commit c40a7b3592b3b7519eadc130c5583db2aaf70f68
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 15 09:40:42 2018 +0200

    Linux 4.4.156

commit a632d2d1849f9370d87e397319304f3787b5d05b
Author: Ethan Lien <ethanlien@synology.com>
Date:   Mon Jul 2 15:44:58 2018 +0800

    btrfs: use correct compare function of dirty_metadata_bytes
    
    commit d814a49198eafa6163698bdd93961302f3a877a4 upstream.
    
    We use customized, nodesize batch value to update dirty_metadata_bytes.
    We should also use batch version of compare function or we will easily
    goto fast path and get false result from percpu_counter_compare().
    
    Fixes: e2d845211eda ("Btrfs: use percpu counter for dirty metadata count")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Ethan Lien <ethanlien@synology.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    nb: Rebased on 4.4.y ]
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 116a6ad749e5acb59ba478663bb0de395edc4d26
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Mon Aug 6 07:14:51 2018 -0500

    ASoC: wm8994: Fix missing break in switch
    
    commit ad0eaee6195db1db1749dd46b9e6f4466793d178 upstream.
    
    Add missing break statement in order to prevent the code from falling
    through to the default case.
    
    Addresses-Coverity-ID: 115050 ("Missing break in switch")
    Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    [Gustavo: Backported to 3.16..4.18 - Remove code comment removal]
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 280880cebc339fea7e92fcb7c16914c593d176c9
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Aug 6 13:49:47 2018 +0200

    s390/lib: use expoline for all bcr instructions
    
    commit 5eda25b10297684c1f46a14199ec00210f3c346e upstream.
    
    The memove, memset, memcpy, __memset16, __memset32 and __memset64
    function have an additional indirect return branch in form of a
    "bzr" instruction. These need to use expolines as well.
    
    Cc: <stable@vger.kernel.org> # v4.17+
    Fixes: 97489e0663 ("s390/lib: use expoline for indirect branches")
    Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5597719733b819bea7cc919188c39726382b1e05
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Tue Jan 2 12:01:41 2018 +0200

    mei: me: allow runtime pm for platform with D0i3
    
    commit cc365dcf0e56271bedf3de95f88922abe248e951 upstream.
    
    >From the pci power documentation:
    "The driver itself should not call pm_runtime_allow(), though. Instead,
    it should let user space or some platform-specific code do that (user space
    can do it via sysfs as stated above)..."
    
    However, the S0ix residency cannot be reached without MEI device getting
    into low power state. Hence, for mei devices that support D0i3, it's better
    to make runtime power management mandatory and not rely on the system
    integration such as udev rules.
    This policy cannot be applied globally as some older platforms
    were found to have broken power management.
    
    Cc: <stable@vger.kernel.org> v4.13+
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Reviewed-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa5d14953152307414b3039b02b3b5acf26d03bc
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Wed Aug 30 12:49:05 2017 +0300

    sch_tbf: fix two null pointer dereferences on init failure
    
    commit c2d6511e6a4f1f3673d711569c00c3849549e9b0 upstream.
    
    sch_tbf calls qdisc_watchdog_cancel() in both its ->reset and ->destroy
    callbacks but it may fail before the timer is initialized due to missing
    options (either not supplied by user-space or set as a default qdisc),
    also q->qdisc is used by ->reset and ->destroy so we need it initialized.
    
    Reproduce:
    $ sysctl net.core.default_qdisc=tbf
    $ ip l set ethX up
    
    Crash log:
    [  959.160172] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
    [  959.160323] IP: qdisc_reset+0xa/0x5c
    [  959.160400] PGD 59cdb067
    [  959.160401] P4D 59cdb067
    [  959.160466] PUD 59ccb067
    [  959.160532] PMD 0
    [  959.160597]
    [  959.160706] Oops: 0000 [#1] SMP
    [  959.160778] Modules linked in: sch_tbf sch_sfb sch_prio sch_netem
    [  959.160891] CPU: 2 PID: 1562 Comm: ip Not tainted 4.13.0-rc6+ #62
    [  959.160998] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
    [  959.161157] task: ffff880059c9a700 task.stack: ffff8800376d0000
    [  959.161263] RIP: 0010:qdisc_reset+0xa/0x5c
    [  959.161347] RSP: 0018:ffff8800376d3610 EFLAGS: 00010286
    [  959.161531] RAX: ffffffffa001b1dd RBX: ffff8800373a2800 RCX: 0000000000000000
    [  959.161733] RDX: ffffffff8215f160 RSI: ffffffff8215f160 RDI: 0000000000000000
    [  959.161939] RBP: ffff8800376d3618 R08: 00000000014080c0 R09: 00000000ffffffff
    [  959.162141] R10: ffff8800376d3578 R11: 0000000000000020 R12: ffffffffa001d2c0
    [  959.162343] R13: ffff880037538000 R14: 00000000ffffffff R15: 0000000000000001
    [  959.162546] FS:  00007fcc5126b740(0000) GS:ffff88005d900000(0000) knlGS:0000000000000000
    [  959.162844] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  959.163030] CR2: 0000000000000018 CR3: 000000005abc4000 CR4: 00000000000406e0
    [  959.163233] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  959.163436] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  959.163638] Call Trace:
    [  959.163788]  tbf_reset+0x19/0x64 [sch_tbf]
    [  959.163957]  qdisc_destroy+0x8b/0xe5
    [  959.164119]  qdisc_create_dflt+0x86/0x94
    [  959.164284]  ? dev_activate+0x129/0x129
    [  959.164449]  attach_one_default_qdisc+0x36/0x63
    [  959.164623]  netdev_for_each_tx_queue+0x3d/0x48
    [  959.164795]  dev_activate+0x4b/0x129
    [  959.164957]  __dev_open+0xe7/0x104
    [  959.165118]  __dev_change_flags+0xc6/0x15c
    [  959.165287]  dev_change_flags+0x25/0x59
    [  959.165451]  do_setlink+0x30c/0xb3f
    [  959.165613]  ? check_chain_key+0xb0/0xfd
    [  959.165782]  rtnl_newlink+0x3a4/0x729
    [  959.165947]  ? rtnl_newlink+0x117/0x729
    [  959.166121]  ? ns_capable_common+0xd/0xb1
    [  959.166288]  ? ns_capable+0x13/0x15
    [  959.166450]  rtnetlink_rcv_msg+0x188/0x197
    [  959.166617]  ? rcu_read_unlock+0x3e/0x5f
    [  959.166783]  ? rtnl_newlink+0x729/0x729
    [  959.166948]  netlink_rcv_skb+0x6c/0xce
    [  959.167113]  rtnetlink_rcv+0x23/0x2a
    [  959.167273]  netlink_unicast+0x103/0x181
    [  959.167439]  netlink_sendmsg+0x326/0x337
    [  959.167607]  sock_sendmsg_nosec+0x14/0x3f
    [  959.167772]  sock_sendmsg+0x29/0x2e
    [  959.167932]  ___sys_sendmsg+0x209/0x28b
    [  959.168098]  ? do_raw_spin_unlock+0xcd/0xf8
    [  959.168267]  ? _raw_spin_unlock+0x27/0x31
    [  959.168432]  ? __handle_mm_fault+0x651/0xdb1
    [  959.168602]  ? check_chain_key+0xb0/0xfd
    [  959.168773]  __sys_sendmsg+0x45/0x63
    [  959.168934]  ? __sys_sendmsg+0x45/0x63
    [  959.169100]  SyS_sendmsg+0x19/0x1b
    [  959.169260]  entry_SYSCALL_64_fastpath+0x23/0xc2
    [  959.169432] RIP: 0033:0x7fcc5097e690
    [  959.169592] RSP: 002b:00007ffd0d5c7b48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [  959.169887] RAX: ffffffffffffffda RBX: ffffffff810d278c RCX: 00007fcc5097e690
    [  959.170089] RDX: 0000000000000000 RSI: 00007ffd0d5c7b90 RDI: 0000000000000003
    [  959.170292] RBP: ffff8800376d3f98 R08: 0000000000000001 R09: 0000000000000003
    [  959.170494] R10: 00007ffd0d5c7910 R11: 0000000000000246 R12: 0000000000000006
    [  959.170697] R13: 000000000066f1a0 R14: 00007ffd0d5cfc40 R15: 0000000000000000
    [  959.170900]  ? trace_hardirqs_off_caller+0xa7/0xcf
    [  959.171076] Code: 00 41 c7 84 24 14 01 00 00 00 00 00 00 41 c7 84 24
    98 00 00 00 00 00 00 00 41 5c 41 5d 41 5e 5d c3 66 66 66 66 90 55 48 89
    e5 53 <48> 8b 47 18 48 89 fb 48 8b 40 48 48 85 c0 74 02 ff d0 48 8b bb
    [  959.171637] RIP: qdisc_reset+0xa/0x5c RSP: ffff8800376d3610
    [  959.171821] CR2: 0000000000000018
    
    Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
    Fixes: 0fbbeb1ba43b ("[PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt()")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a4eae7ae6f47f23aba15eca83f3798a6bc1b855
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Wed Aug 30 12:49:03 2017 +0300

    sch_netem: avoid null pointer deref on init failure
    
    commit 634576a1844dba15bc5e6fc61d72f37e13a21615 upstream.
    
    netem can fail in ->init due to missing options (either not supplied by
    user-space or used as a default qdisc) causing a timer->base null
    pointer deref in its ->destroy() and ->reset() callbacks.
    
    Reproduce:
    $ sysctl net.core.default_qdisc=netem
    $ ip l set ethX up
    
    Crash log:
    [ 1814.846943] BUG: unable to handle kernel NULL pointer dereference at (null)
    [ 1814.847181] IP: hrtimer_active+0x17/0x8a
    [ 1814.847270] PGD 59c34067
    [ 1814.847271] P4D 59c34067
    [ 1814.847337] PUD 37374067
    [ 1814.847403] PMD 0
    [ 1814.847468]
    [ 1814.847582] Oops: 0000 [#1] SMP
    [ 1814.847655] Modules linked in: sch_netem(O) sch_fq_codel(O)
    [ 1814.847761] CPU: 3 PID: 1573 Comm: ip Tainted: G           O 4.13.0-rc6+ #62
    [ 1814.847884] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
    [ 1814.848043] task: ffff88003723a700 task.stack: ffff88005adc8000
    [ 1814.848235] RIP: 0010:hrtimer_active+0x17/0x8a
    [ 1814.848407] RSP: 0018:ffff88005adcb590 EFLAGS: 00010246
    [ 1814.848590] RAX: 0000000000000000 RBX: ffff880058e359d8 RCX: 0000000000000000
    [ 1814.848793] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880058e359d8
    [ 1814.848998] RBP: ffff88005adcb5b0 R08: 00000000014080c0 R09: 00000000ffffffff
    [ 1814.849204] R10: ffff88005adcb660 R11: 0000000000000020 R12: 0000000000000000
    [ 1814.849410] R13: ffff880058e359d8 R14: 00000000ffffffff R15: 0000000000000001
    [ 1814.849616] FS:  00007f733bbca740(0000) GS:ffff88005d980000(0000) knlGS:0000000000000000
    [ 1814.849919] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1814.850107] CR2: 0000000000000000 CR3: 0000000059f0d000 CR4: 00000000000406e0
    [ 1814.850313] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1814.850518] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 1814.850723] Call Trace:
    [ 1814.850875]  hrtimer_try_to_cancel+0x1a/0x93
    [ 1814.851047]  hrtimer_cancel+0x15/0x20
    [ 1814.851211]  qdisc_watchdog_cancel+0x12/0x14
    [ 1814.851383]  netem_reset+0xe6/0xed [sch_netem]
    [ 1814.851561]  qdisc_destroy+0x8b/0xe5
    [ 1814.851723]  qdisc_create_dflt+0x86/0x94
    [ 1814.851890]  ? dev_activate+0x129/0x129
    [ 1814.852057]  attach_one_default_qdisc+0x36/0x63
    [ 1814.852232]  netdev_for_each_tx_queue+0x3d/0x48
    [ 1814.852406]  dev_activate+0x4b/0x129
    [ 1814.852569]  __dev_open+0xe7/0x104
    [ 1814.852730]  __dev_change_flags+0xc6/0x15c
    [ 1814.852899]  dev_change_flags+0x25/0x59
    [ 1814.853064]  do_setlink+0x30c/0xb3f
    [ 1814.853228]  ? check_chain_key+0xb0/0xfd
    [ 1814.853396]  ? check_chain_key+0xb0/0xfd
    [ 1814.853565]  rtnl_newlink+0x3a4/0x729
    [ 1814.853728]  ? rtnl_newlink+0x117/0x729
    [ 1814.853905]  ? ns_capable_common+0xd/0xb1
    [ 1814.854072]  ? ns_capable+0x13/0x15
    [ 1814.854234]  rtnetlink_rcv_msg+0x188/0x197
    [ 1814.854404]  ? rcu_read_unlock+0x3e/0x5f
    [ 1814.854572]  ? rtnl_newlink+0x729/0x729
    [ 1814.854737]  netlink_rcv_skb+0x6c/0xce
    [ 1814.854902]  rtnetlink_rcv+0x23/0x2a
    [ 1814.855064]  netlink_unicast+0x103/0x181
    [ 1814.855230]  netlink_sendmsg+0x326/0x337
    [ 1814.855398]  sock_sendmsg_nosec+0x14/0x3f
    [ 1814.855584]  sock_sendmsg+0x29/0x2e
    [ 1814.855747]  ___sys_sendmsg+0x209/0x28b
    [ 1814.855912]  ? do_raw_spin_unlock+0xcd/0xf8
    [ 1814.856082]  ? _raw_spin_unlock+0x27/0x31
    [ 1814.856251]  ? __handle_mm_fault+0x651/0xdb1
    [ 1814.856421]  ? check_chain_key+0xb0/0xfd
    [ 1814.856592]  __sys_sendmsg+0x45/0x63
    [ 1814.856755]  ? __sys_sendmsg+0x45/0x63
    [ 1814.856923]  SyS_sendmsg+0x19/0x1b
    [ 1814.857083]  entry_SYSCALL_64_fastpath+0x23/0xc2
    [ 1814.857256] RIP: 0033:0x7f733b2dd690
    [ 1814.857419] RSP: 002b:00007ffe1d3387d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [ 1814.858238] RAX: ffffffffffffffda RBX: ffffffff810d278c RCX: 00007f733b2dd690
    [ 1814.858445] RDX: 0000000000000000 RSI: 00007ffe1d338820 RDI: 0000000000000003
    [ 1814.858651] RBP: ffff88005adcbf98 R08: 0000000000000001 R09: 0000000000000003
    [ 1814.858856] R10: 00007ffe1d3385a0 R11: 0000000000000246 R12: 0000000000000002
    [ 1814.859060] R13: 000000000066f1a0 R14: 00007ffe1d3408d0 R15: 0000000000000000
    [ 1814.859267]  ? trace_hardirqs_off_caller+0xa7/0xcf
    [ 1814.859446] Code: 10 55 48 89 c7 48 89 e5 e8 45 a1 fb ff 31 c0 5d c3
    31 c0 c3 66 66 66 66 90 55 48 89 e5 41 56 41 55 41 54 53 49 89 fd 49 8b
    45 30 <4c> 8b 20 41 8b 5c 24 38 31 c9 31 d2 48 c7 c7 50 8e 1d 82 41 89
    [ 1814.860022] RIP: hrtimer_active+0x17/0x8a RSP: ffff88005adcb590
    [ 1814.860214] CR2: 0000000000000000
    
    Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
    Fixes: 0fbbeb1ba43b ("[PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt()")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dafa62c875599b077445866d2bd903afdc7e60e
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Wed Aug 30 12:48:59 2017 +0300

    sch_hhf: fix null pointer dereference on init failure
    
    commit 32db864d33c21fd70a217ba53cb7224889354ffb upstream.
    
    If sch_hhf fails in its ->init() function (either due to wrong
    user-space arguments as below or memory alloc failure of hh_flows) it
    will do a null pointer deref of q->hh_flows in its ->destroy() function.
    
    To reproduce the crash:
    $ tc qdisc add dev eth0 root hhf quantum 2000000 non_hh_weight 10000000
    
    Crash log:
    [  690.654882] BUG: unable to handle kernel NULL pointer dereference at (null)
    [  690.655565] IP: hhf_destroy+0x48/0xbc
    [  690.655944] PGD 37345067
    [  690.655948] P4D 37345067
    [  690.656252] PUD 58402067
    [  690.656554] PMD 0
    [  690.656857]
    [  690.657362] Oops: 0000 [#1] SMP
    [  690.657696] Modules linked in:
    [  690.658032] CPU: 3 PID: 920 Comm: tc Not tainted 4.13.0-rc6+ #57
    [  690.658525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
    [  690.659255] task: ffff880058578000 task.stack: ffff88005acbc000
    [  690.659747] RIP: 0010:hhf_destroy+0x48/0xbc
    [  690.660146] RSP: 0018:ffff88005acbf9e0 EFLAGS: 00010246
    [  690.660601] RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000
    [  690.661155] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff821f63f0
    [  690.661710] RBP: ffff88005acbfa08 R08: ffffffff81b10a90 R09: 0000000000000000
    [  690.662267] R10: 00000000f42b7019 R11: ffff880058578000 R12: 00000000ffffffea
    [  690.662820] R13: ffff8800372f6400 R14: 0000000000000000 R15: 0000000000000000
    [  690.663769] FS:  00007f8ae5e8b740(0000) GS:ffff88005d980000(0000) knlGS:0000000000000000
    [  690.667069] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  690.667965] CR2: 0000000000000000 CR3: 0000000058523000 CR4: 00000000000406e0
    [  690.668918] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  690.669945] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  690.671003] Call Trace:
    [  690.671743]  qdisc_create+0x377/0x3fd
    [  690.672534]  tc_modify_qdisc+0x4d2/0x4fd
    [  690.673324]  rtnetlink_rcv_msg+0x188/0x197
    [  690.674204]  ? rcu_read_unlock+0x3e/0x5f
    [  690.675091]  ? rtnl_newlink+0x729/0x729
    [  690.675877]  netlink_rcv_skb+0x6c/0xce
    [  690.676648]  rtnetlink_rcv+0x23/0x2a
    [  690.677405]  netlink_unicast+0x103/0x181
    [  690.678179]  netlink_sendmsg+0x326/0x337
    [  690.678958]  sock_sendmsg_nosec+0x14/0x3f
    [  690.679743]  sock_sendmsg+0x29/0x2e
    [  690.680506]  ___sys_sendmsg+0x209/0x28b
    [  690.681283]  ? __handle_mm_fault+0xc7d/0xdb1
    [  690.681915]  ? check_chain_key+0xb0/0xfd
    [  690.682449]  __sys_sendmsg+0x45/0x63
    [  690.682954]  ? __sys_sendmsg+0x45/0x63
    [  690.683471]  SyS_sendmsg+0x19/0x1b
    [  690.683974]  entry_SYSCALL_64_fastpath+0x23/0xc2
    [  690.684516] RIP: 0033:0x7f8ae529d690
    [  690.685016] RSP: 002b:00007fff26d2d6b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [  690.685931] RAX: ffffffffffffffda RBX: ffffffff810d278c RCX: 00007f8ae529d690
    [  690.686573] RDX: 0000000000000000 RSI: 00007fff26d2d700 RDI: 0000000000000003
    [  690.687047] RBP: ffff88005acbff98 R08: 0000000000000001 R09: 0000000000000000
    [  690.687519] R10: 00007fff26d2d480 R11: 0000000000000246 R12: 0000000000000002
    [  690.687996] R13: 0000000001258070 R14: 0000000000000001 R15: 0000000000000000
    [  690.688475]  ? trace_hardirqs_off_caller+0xa7/0xcf
    [  690.688887] Code: 00 00 e8 2a 02 ae ff 49 8b bc 1d 60 02 00 00 48 83
    c3 08 e8 19 02 ae ff 48 83 fb 20 75 dc 45 31 f6 4d 89 f7 4d 03 bd 20 02
    00 00 <49> 8b 07 49 39 c7 75 24 49 83 c6 10 49 81 fe 00 40 00 00 75 e1
    [  690.690200] RIP: hhf_destroy+0x48/0xbc RSP: ffff88005acbf9e0
    [  690.690636] CR2: 0000000000000000
    
    Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
    Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68858be0c1b5a2387c93f5bd4de8efddac149cbb
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Wed Aug 30 12:48:58 2017 +0300

    sch_multiq: fix double free on init failure
    
    commit e89d469e3be3ed3d7124a803211a463ff83d0964 upstream.
    
    The below commit added a call to ->destroy() on init failure, but multiq
    still frees ->queues on error in init, but ->queues is also freed by
    ->destroy() thus we get double free and corrupted memory.
    
    Very easy to reproduce (eth0 not multiqueue):
    $ tc qdisc add dev eth0 root multiq
    RTNETLINK answers: Operation not supported
    $ ip l add dumdum type dummy
    (crash)
    
    Trace log:
    [ 3929.467747] general protection fault: 0000 [#1] SMP
    [ 3929.468083] Modules linked in:
    [ 3929.468302] CPU: 3 PID: 967 Comm: ip Not tainted 4.13.0-rc6+ #56
    [ 3929.468625] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
    [ 3929.469124] task: ffff88003716a700 task.stack: ffff88005872c000
    [ 3929.469449] RIP: 0010:__kmalloc_track_caller+0x117/0x1be
    [ 3929.469746] RSP: 0018:ffff88005872f6a0 EFLAGS: 00010246
    [ 3929.470042] RAX: 00000000000002de RBX: 0000000058a59000 RCX: 00000000000002df
    [ 3929.470406] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff821f7020
    [ 3929.470770] RBP: ffff88005872f6e8 R08: 000000000001f010 R09: 0000000000000000
    [ 3929.471133] R10: ffff88005872f730 R11: 0000000000008cdd R12: ff006d75646d7564
    [ 3929.471496] R13: 00000000014000c0 R14: ffff88005b403c00 R15: ffff88005b403c00
    [ 3929.471869] FS:  00007f0b70480740(0000) GS:ffff88005d980000(0000) knlGS:0000000000000000
    [ 3929.472286] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 3929.472677] CR2: 00007ffcee4f3000 CR3: 0000000059d45000 CR4: 00000000000406e0
    [ 3929.473209] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 3929.474109] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 3929.474873] Call Trace:
    [ 3929.475337]  ? kstrdup_const+0x23/0x25
    [ 3929.475863]  kstrdup+0x2e/0x4b
    [ 3929.476338]  kstrdup_const+0x23/0x25
    [ 3929.478084]  __kernfs_new_node+0x28/0xbc
    [ 3929.478478]  kernfs_new_node+0x35/0x55
    [ 3929.478929]  kernfs_create_link+0x23/0x76
    [ 3929.479478]  sysfs_do_create_link_sd.isra.2+0x85/0xd7
    [ 3929.480096]  sysfs_create_link+0x33/0x35
    [ 3929.480649]  device_add+0x200/0x589
    [ 3929.481184]  netdev_register_kobject+0x7c/0x12f
    [ 3929.481711]  register_netdevice+0x373/0x471
    [ 3929.482174]  rtnl_newlink+0x614/0x729
    [ 3929.482610]  ? rtnl_newlink+0x17f/0x729
    [ 3929.483080]  rtnetlink_rcv_msg+0x188/0x197
    [ 3929.483533]  ? rcu_read_unlock+0x3e/0x5f
    [ 3929.483984]  ? rtnl_newlink+0x729/0x729
    [ 3929.484420]  netlink_rcv_skb+0x6c/0xce
    [ 3929.484858]  rtnetlink_rcv+0x23/0x2a
    [ 3929.485291]  netlink_unicast+0x103/0x181
    [ 3929.485735]  netlink_sendmsg+0x326/0x337
    [ 3929.486181]  sock_sendmsg_nosec+0x14/0x3f
    [ 3929.486614]  sock_sendmsg+0x29/0x2e
    [ 3929.486973]  ___sys_sendmsg+0x209/0x28b
    [ 3929.487340]  ? do_raw_spin_unlock+0xcd/0xf8
    [ 3929.487719]  ? _raw_spin_unlock+0x27/0x31
    [ 3929.488092]  ? __handle_mm_fault+0x651/0xdb1
    [ 3929.488471]  ? check_chain_key+0xb0/0xfd
    [ 3929.488847]  __sys_sendmsg+0x45/0x63
    [ 3929.489206]  ? __sys_sendmsg+0x45/0x63
    [ 3929.489576]  SyS_sendmsg+0x19/0x1b
    [ 3929.489901]  entry_SYSCALL_64_fastpath+0x23/0xc2
    [ 3929.490172] RIP: 0033:0x7f0b6fb93690
    [ 3929.490423] RSP: 002b:00007ffcee4ed588 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    [ 3929.490881] RAX: ffffffffffffffda RBX: ffffffff810d278c RCX: 00007f0b6fb93690
    [ 3929.491198] RDX: 0000000000000000 RSI: 00007ffcee4ed5d0 RDI: 0000000000000003
    [ 3929.491521] RBP: ffff88005872ff98 R08: 0000000000000001 R09: 0000000000000000
    [ 3929.491801] R10: 00007ffcee4ed350 R11: 0000000000000246 R12: 0000000000000002
    [ 3929.492075] R13: 000000000066f1a0 R14: 00007ffcee4f5680 R15: 0000000000000000
    [ 3929.492352]  ? trace_hardirqs_off_caller+0xa7/0xcf
    [ 3929.492590] Code: 8b 45 c0 48 8b 45 b8 74 17 48 8b 4d c8 83 ca ff 44
    89 ee 4c 89 f7 e8 83 ca ff ff 49 89 c4 eb 49 49 63 56 20 48 8d 48 01 4d
    8b 06 <49> 8b 1c 14 48 89 c2 4c 89 e0 65 49 0f c7 08 0f 94 c0 83 f0 01
    [ 3929.493335] RIP: __kmalloc_track_caller+0x117/0x1be RSP: ffff88005872f6a0
    
    Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
    Fixes: f07d1501292b ("multiq: Further multiqueue cleanup")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [AmitP: Removed unused variable 'err' in multiq_init()]
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7edd04ddb3f37d8bdecae07f05aae5bb48416211
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date:   Wed Aug 30 12:48:57 2017 +0300

    sch_htb: fix crash on init failure
    
    commit 88c2ace69dbef696edba77712882af03879abc9c upstream.
    
    The commit below added a call to the ->destroy() callback for all qdiscs
    which failed in their ->init(), but some were not prepared for such
    change and can't handle partially initialized qdisc. HTB is one of them
    and if any error occurs before the qdisc watchdog timer and qdisc work are
    initialized then we can hit either a null ptr deref (timer->base) when
    canceling in ->destroy or lockdep error info about trying to register
    a non-static key and a stack dump. So to fix these two move the watchdog
    timer and workqueue init before anything that can err out.
    To reproduce userspace needs to send broken htb qdisc create request,
    tested with a modified tc (q_htb.c).
    
    Trace log:
    [ 2710.897602] BUG: unable to handle kernel NULL pointer dereference at (null)
    [ 2710.897977] IP: hrtimer_active+0x17/0x8a
    [ 2710.898174] PGD 58fab067
    [ 2710.898175] P4D 58fab067
    [ 2710.898353] PUD 586c0067
    [ 2710.898531] PMD 0
    [ 2710.898710]
    [ 2710.899045] Oops: 0000 [#1] SMP
    [ 2710.899232] Modules linked in:
    [ 2710.899419] CPU: 1 PID: 950 Comm: tc Not tainted 4.13.0-rc6+ #54
    [ 2710.899646] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
    [ 2710.900035] task: ffff880059ed2700 task.stack: ffff88005ad4c000
    [ 2710.900262] RIP: 0010:hrtimer_active+0x17/0x8a
    [ 2710.900467] RSP: 0018:ffff88005ad4f960 EFLAGS: 00010246
    [ 2710.900684] RAX: 0000000000000000 RBX: ffff88003701e298 RCX: 0000000000000000
    [ 2710.900933] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003701e298
    [ 2710.901177] RBP: ffff88005ad4f980 R08: 0000000000000001 R09: 0000000000000001
    [ 2710.901419] R10: ffff88005ad4f800 R11: 0000000000000400 R12: 0000000000000000
    [ 2710.901663] R13: ffff88003701e298 R14: ffffffff822a4540 R15: ffff88005ad4fac0
    [ 2710.901907] FS:  00007f2f5e90f740(0000) GS:ffff88005d880000(0000) knlGS:0000000000000000
    [ 2710.902277] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 2710.902500] CR2: 0000000000000000 CR3: 0000000058ca3000 CR4: 00000000000406e0
    [ 2710.902744] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 2710.902977] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 2710.903180] Call Trace:
    [ 2710.903332]  hrtimer_try_to_cancel+0x1a/0x93
    [ 2710.903504]  hrtimer_cancel+0x15/0x20
    [ 2710.903667]  qdisc_watchdog_cancel+0x12/0x14
    [ 2710.903866]  htb_destroy+0x2e/0xf7
    [ 2710.904097]  qdisc_create+0x377/0x3fd
    [ 2710.904330]  tc_modify_qdisc+0x4d2/0x4fd
    [ 2710.904511]  rtnetlink_rcv_msg+0x188/0x197
    [ 2710.904682]  ? rcu_read_unlock+0x3e/0x5f
    [ 2710.904849]  ? rtnl_newlink+0x729/0x729
    [ 2710.905017]  netlink_rcv_skb+0x6c/0xce
    [ 2710.905183]  rtnetlink_rcv+0x23/0x2a
    [ 2710.905345]  netlink_unicast+0x103/0x181
    [ 2710.905511]  netlink_sendmsg+0x326/0x337
    [ 2710.905679]  sock_sendmsg_nosec+0x14/0x3f
    [ 2710.905847]  sock_sendmsg+0x29/0x2e
    [ 2710.906010]  ___sys_sendmsg+0x209/0x28b
    [ 2710.906176]  ? do_raw_spin_unlock+0xcd/0xf8
    [ 2710.906346]  ? _raw_spin_unlock+0x27/0x31
    [ 2710.906514]  ? __handle_mm_fault+0x651/0xdb1
    [ 2710.906685]  ? check_chain_key+0xb0/0xfd
    [ 2710.906855]  __sys_sendmsg+0x45/0x63
    [ 2710.907018]  ? __sys_sendmsg+0x45/0x63
    [ 2710.907185]  SyS_sendmsg+0x19/0x1b
    [ 2710.907344]  entry_SYSCALL_64_fastpath+0x23/0xc2
    
    Note that probably this bug goes further back because the default qdisc
    handling always calls ->destroy on init failure too.
    
    Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation")
    Fixes: 0fbbeb1ba43b ("[PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt()")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [AmitP: Rebased for linux-4.4.y]
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89f15c6e8212ab97dbdcaf561709357cd0b398f5
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Sep 1 11:11:59 2016 +0200

    ovl: proper cleanup of workdir
    
    commit eea2fb4851e9dcbab6b991aaf47e2e024f1f55a0 upstream.
    
    When mounting overlayfs it needs a clean "work" directory under the
    supplied workdir.
    
    Previously the mount code removed this directory if it already existed and
    created a new one.  If the removal failed (e.g. directory was not empty)
    then it fell back to a read-only mount not using the workdir.
    
    While this has never been reported, it is possible to get a non-empty
    "work" dir from a previous mount of overlayfs in case of crash in the
    middle of an operation using the work directory.
    
    In this case the left over state should be discarded and the overlay
    filesystem will be consistent, guaranteed by the atomicity of operations on
    moving to/from the workdir to the upper layer.
    
    This patch implements cleaning out any files left in workdir.  It is
    implemented using real recursion for simplicity, but the depth is limited
    to 2, because the worst case is that of a directory containing whiteouts
    under "work".
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 121b09d30d48a59a0ae621b130f3b4e42e724e68
Author: Antonio Murdaca <amurdaca@redhat.com>
Date:   Thu Apr 7 15:48:25 2016 +0200

    ovl: override creds with the ones from the superblock mounter
    
    commit 3fe6e52f062643676eb4518d68cee3bc1272091b upstream.
    
    In user namespace the whiteout creation fails with -EPERM because the
    current process isn't capable(CAP_SYS_ADMIN) when setting xattr.
    
    A simple reproducer:
    
    $ mkdir upper lower work merged lower/dir
    $ sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged
    $ unshare -m -p -f -U -r bash
    
    Now as root in the user namespace:
    
    \# touch merged/dir/{1,2,3} # this will force a copy up of lower/dir
    \# rm -fR merged/*
    
    This ends up failing with -EPERM after the files in dir has been
    correctly deleted:
    
    unlinkat(4, "2", 0)                     = 0
    unlinkat(4, "1", 0)                     = 0
    unlinkat(4, "3", 0)                     = 0
    close(4)                                = 0
    unlinkat(AT_FDCWD, "merged/dir", AT_REMOVEDIR) = -1 EPERM (Operation not
    permitted)
    
    Interestingly, if you don't place files in merged/dir you can remove it,
    meaning if upper/dir does not exist, creating the char device file works
    properly in that same location.
    
    This patch uses ovl_sb_creator_cred() to get the cred struct from the
    superblock mounter and override the old cred with these new ones so that
    the whiteout creation is possible because overlay is wrong in assuming that
    the creds it will get with prepare_creds will be in the initial user
    namespace.  The old cap_raise game is removed in favor of just overriding
    the old cred struct.
    
    This patch also drops from ovl_copy_up_one() the following two lines:
    
    override_cred->fsuid = stat->uid;
    override_cred->fsgid = stat->gid;
    
    This is because the correct uid and gid are taken directly with the stat
    struct and correctly set with ovl_set_attr().
    
    Signed-off-by: Antonio Murdaca <runcom@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6586f61ab5bb8f216d79c40a9997920c1ed01544
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Mar 21 17:31:46 2016 +0100

    ovl: rename is_merge to is_lowest
    
    commit 56656e960b555cb98bc414382566dcb59aae99a2 upstream.
    
    The 'is_merge' is an historical naming from when only a single lower layer
    could exist.  With the introduction of multiple lower layers the meaning of
    this flag was changed to mean only the "lowest layer" (while all lower
    layers were being merged).
    
    So now 'is_merge' is inaccurate and hence renaming to 'is_lowest'
    
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eadbe44f3978fcb2ac7cd98e91ce2d986a7ae1b8
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Wed Dec 16 14:11:22 2015 +0000

    irqchip/gic: Make interrupt ID 1020 invalid
    
    commit 327ebe1f3a9b7e20e298b39d0cff627169a28012 upstream.
    
    The GIC has no such thing as interrupt 1020: the last valid ID is
    1019, and the range 1020-1023 is reserved - 1023 indicating that
    no interrupt is pending. So let's make sure we don't try to handle
    this ID.
    
    This bug has been in since the initial GIC code was introduced in
    8ad68bbf7a06 ("[ARM] Add support for ARM RealView board").
    
    Reported-by: Eric Auger <eric.auger@linaro.org>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3107eb31aba1367111d0243fa376536dd451c6d6
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Feb 18 19:15:45 2016 +0000

    irqchip/gic-v3: Add missing barrier to 32bit version of gic_read_iar()
    
    commit 8f318526a292c5e7cebb82f3f766b83c22343293 upstream.
    
    Commit 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is
    visible on redestributor") fixed the missing barrier on arm64, but
    forgot to update the 32bit counterpart, which has the same requirements.
    Let's fix it.
    
    Fixes: 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor")
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e56ddc78f0e3669205ca50acee64fc6c75887b0
Author: Shanker Donthineni <shankerd@codeaurora.org>
Date:   Tue Feb 16 18:00:36 2016 -0600

    irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn memory size
    
    commit 2eca0d6ceea1f108b2d3ac81fb34698c4fd41006 upstream.
    
    Function its_alloc_tables() maintains two local variables, "order" and
    and "alloc_size", to hold memory size that has been allocated to
    ITS_BASEn. We don't always refresh the variable alloc_size whenever
    value of the variable order changes, causing the following two
    problems.
    
      - Cache flush operation with size more than required.
      - Information reported by pr_info is not correct.
    
    Use a helper macro that converts page order to size in bytes instead of
    variable "alloc_size" to fix both the problems.
    
    Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a0c7f6afea7d76ce53ca1f9517c2f9ac9ea13ea
Author: Shanker Donthineni <shankerd@codeaurora.org>
Date:   Mon Feb 1 20:19:44 2016 -0600

    irqchip/gicv3-its: Fix memory leak in its_free_tables()
    
    commit 1a485f4d2e28efd77075b2952926683d6c245633 upstream.
    
    The current ITS driver has a memory leak in its_free_tables(). It
    happens on tear down path of the driver when its_probe() call fails.
    its_free_tables() should free the exact number of pages that have
    been allocated, not just a single page as current code does.
    
    This patch records the memory size for each ITS_BASERn at the time of
    page allocation and uses the same size information when freeing pages
    to fix the issue.
    
    Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Jason Cooper <jason@lakedaemon.net>
    Cc: Vikram Sethi <vikrams@codeaurora.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/1454379584-21772-1-git-send-email-shankerd@codeaurora.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad37cd79428ee7206be05edba64de6aa3397587e
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Jan 26 14:24:15 2016 +0000

    irqchip/gic-v3-its: Recompute the number of pages on page size change
    
    commit 18aa60ce2751c95d3412ed06a58b8b6cfb6f88f2 upstream.
    
    When the programming of a GITS_BASERn register fails because of
    an unsupported ITS page size, we retry it with a smaller page size.
    Unfortunately, we don't recompute the number of allocated ITS pages,
    indicating the wrong value computed in the original allocation.
    
    A convenient fix is to free the pages we allocated, update the
    page size, and restart the allocation. This will ensure that
    we always allocate the right amount in the case of a device
    table, specially if we have to reduce the allocation order
    to stay within the boundaries of the ITS maximum allocation.
    
    Reported-and-tested-by: Ma Jun <majun258@huawei.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Jason Cooper <jason@lakedaemon.net>
    Link: http://lkml.kernel.org/r/1453818255-1289-1-git-send-email-marc.zyngier@arm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27e83f7dd91dee0d7d4a8289db3de4c12f0436bd
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Wed Nov 4 18:32:37 2015 +0000

    genirq: Delay incrementing interrupt count if it's disabled/pending
    
    commit a946e8c717f9355d1abd5408ed0adc0002d1aed1 upstream.
    
    In case of a wakeup interrupt, irq_pm_check_wakeup disables the interrupt
    and marks it pending and suspended, disables it and notifies the pm core
    about the wake event. The interrupt gets handled later once the system
    is resumed.
    
    However the irq stats is updated twice: once when it's disabled waiting
    for the system to resume and later when it's handled, resulting in wrong
    counting of the wakeup interrupt when waking up the system.
    
    This patch updates the interrupt count so that it's updated only when
    the interrupt gets handled. It's already handled correctly in
    handle_edge_irq and handle_edge_eoi_irq.
    
    Reported-by: Manoil Claudiu <claudiu.manoil@freescale.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Link: http://lkml.kernel.org/r/1446661957-1019-1-git-send-email-sudeep.holla@arm.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e72977e87482759dba7181e0ec210c2db00c6124
Author: Chas Williams <chas3@att.com>
Date:   Thu Sep 6 11:11:27 2018 -0400

    Fixes: Commit cdbf92675fad ("mm: numa: avoid waiting on freed migrated pages")
    
    Commit cdbf92675fad ("mm: numa: avoid waiting on freed migrated pages")
    was an incomplete backport of the upstream commit.  It is necessary to
    always reset page_nid before attempting any early exit.
    
    The original commit conflicted due to lack of commit 82b0f8c39a38
    ("mm: join struct fault_env and vm_fault") in 4.9 so it wasn't a clean
    application, and the change must have just gotten lost in the noise.
    
    Signed-off-by: Chas Williams <chas3@att.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a50422747502a5f3b925a96f36f85e2412e798ec
Author: Govindarajulu Varadarajan <gvaradar@cisco.com>
Date:   Mon Jul 30 09:56:54 2018 -0700

    enic: do not call enic_change_mtu in enic_probe
    
    commit cb5c6568867325f9905e80c96531d963bec8e5ea upstream.
    
    In commit ab123fe071c9 ("enic: handle mtu change for vf properly")
    ASSERT_RTNL() is added to _enic_change_mtu() to prevent it from being
    called without rtnl held. enic_probe() calls enic_change_mtu()
    without rtnl held. At this point netdev is not registered yet.
    Remove call to enic_change_mtu and assign the mtu to netdev->mtu.
    
    Fixes: ab123fe071c9 ("enic: handle mtu change for vf properly")
    Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a37c70426caa22b59e82c598e9795bead06fd9a9
Author: Fabio Estevam <fabio.estevam@nxp.com>
Date:   Mon Sep 3 10:39:48 2018 -0300

    Revert "ARM: imx_v6_v7_defconfig: Select ULPI support"
    
    This reverts commit 0d0af17ae83d6feb29d676c72423461419df5110.
    
    This commit causes reboot to fail on imx6 wandboard, so let's
    revert it.
    
    Cc: <stable@vger.kernel.org> #4.4
    Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 131a3b82c853483b1809cad06f8997421dd49500
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Sep 4 15:24:05 2018 +0000

    irda: Only insert new objects into the global database via setsockopt
    
    The irda_setsockopt() function conditionally allocates memory for a new
    self->ias_object or, in some cases, reuses the existing
    self->ias_object. Existing objects were incorrectly reinserted into the
    LM_IAS database which corrupted the doubly linked list used for the
    hashbin implementation of the LM_IAS database. When combined with a
    memory leak in irda_bind(), this issue could be leveraged to create a
    use-after-free vulnerability in the hashbin list. This patch fixes the
    issue by only inserting newly allocated objects into the database.
    
    CVE-2018-6555
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Seth Arnold <seth.arnold@canonical.com>
    Reviewed-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a7811bb3ae10d76d9e76c2b0ce7b27bc02a9370
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Tue Sep 4 15:24:04 2018 +0000

    irda: Fix memory leak caused by repeated binds of irda socket
    
    The irda_bind() function allocates memory for self->ias_obj without
    checking to see if the socket is already bound. A userspace process
    could repeatedly bind the socket, have each new object added into the
    LM-IAS database, and lose the reference to the old object assigned to
    the socket to exhaust memory resources. This patch errors out of the
    bind operation when self->ias_obj is already assigned.
    
    CVE-2018-6554
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Reviewed-by: Seth Arnold <seth.arnold@canonical.com>
    Reviewed-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit accf294af41897950d1c83318c44a032d755188d
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Aug 28 12:59:10 2018 -0700

    kbuild: make missing $DEPMOD a Warning instead of an Error
    
    commit 914b087ff9e0e9a399a4927fa30793064afc0178 upstream.
    
    When $DEPMOD is not found, only print a warning instead of exiting
    with an error message and error status:
    
    Warning: 'make modules_install' requires /sbin/depmod. Please install it.
    This is probably in the kmod package.
    
    Change the Error to a Warning because "not all build hosts for cross
    compiling Linux are Linux systems and are able to provide a working
    port of depmod, especially at the file patch /sbin/depmod."
    
    I.e., "make modules_install" may be used to copy/install the
    loadable modules files to a target directory on a build system and
    then transferred to an embedded device where /sbin/depmod is run
    instead of it being run on the build system.
    
    Fixes: 934193a654c1 ("kbuild: verify that $DEPMOD is installed")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
    Cc: stable@vger.kernel.org
    Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
    Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>
    Cc: Michal Marek <michal.lkml@markovi.net>
    Cc: Jessica Yu <jeyu@kernel.org>
    Cc: Chih-Wei Huang <cwhuang@linux.org.tw>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Maxim Zhukov <mussitantesmortem@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f46d2b99a6acd87d56822c600fd2587a37e4d56c
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Aug 21 17:37:55 2018 +0200

    x86/pae: use 64 bit atomic xchg function in native_ptep_get_and_clear
    
    commit b2d7a075a1ccef2fb321d595802190c8e9b39004 upstream.
    
    Using only 32-bit writes for the pte will result in an intermediate
    L1TF vulnerable PTE. When running as a Xen PV guest this will at once
    switch the guest to shadow mode resulting in a loss of performance.
    
    Use arch_atomic64_xchg() instead which will perform the requested
    operation atomically with all 64 bits.
    
    Some performance considerations according to:
    
    https://software.intel.com/sites/default/files/managed/ad/dc/Intel-Xeon-Scalable-Processor-throughput-latency.pdf
    
    The main number should be the latency, as there is no tight loop around
    native_ptep_get_and_clear().
    
    "lock cmpxchg8b" has a latency of 20 cycles, while "lock xchg" (with a
    memory operand) isn't mentioned in that document. "lock xadd" (with xadd
    having 3 cycles less latency than xchg) has a latency of 11, so we can
    assume a latency of 14 for "lock xchg".
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Jason Andryuk <jandryuk@gmail.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    [ Atomic operations gained an arch_ prefix in 8bf705d13039
    ("locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h") so
    s/arch_atomic64_xchg/atomic64_xchg/ for backport.]
    Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98d122a4a74667ffc16d50baa086e9616fb44f28
Author: Joel Fernandes (Google) <joel@joelfernandes.org>
Date:   Mon Jul 23 14:25:31 2018 -0700

    debugobjects: Make stack check warning more informative
    
    commit fc91a3c4c27acdca0bc13af6fbb68c35cfd519f2 upstream.
    
    While debugging an issue debugobject tracking warned about an annotation
    issue of an object on stack. It turned out that the issue was due to the
    object in concern being on a different stack which was due to another
    issue.
    
    Thomas suggested to print the pointers and the location of the stack for
    the currently running task. This helped to figure out that the object was
    on the wrong stack.
    
    As this is general useful information for debugging similar issues, make
    the error message more informative by printing the pointers.
    
    [ tglx: Massaged changelog ]
    
    Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Waiman Long <longman@redhat.com>
    Acked-by: Yang Shi <yang.shi@linux.alibaba.com>
    Cc: kernel-team@android.com
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: astrachan@google.com
    Link: https://lkml.kernel.org/r/20180723212531.202328-1-joel@joelfernandes.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02e48c4d57ccaa89ad1d9fbf39ae6a4bb20aa4e5
Author: Qu Wenruo <wqu@suse.com>
Date:   Fri Jun 22 12:35:00 2018 +0800

    btrfs: Don't remove block group that still has pinned down bytes
    
    [ Upstream commit 43794446548730ac8461be30bbe47d5d027d1d16 ]
    
    [BUG]
    Under certain KVM load and LTP tests, it is possible to hit the
    following calltrace if quota is enabled:
    
    BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
    BTRFS critical (device vda2): unable to find logical 8820195328 length 4096
    
    WARNING: CPU: 0 PID: 49 at ../block/blk-core.c:172 blk_status_to_errno+0x1a/0x30
    CPU: 0 PID: 49 Comm: kworker/u2:1 Not tainted 4.12.14-15-default #1 SLE15 (unreleased)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
    Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
    task: ffff9f827b340bc0 task.stack: ffffb4f8c0304000
    RIP: 0010:blk_status_to_errno+0x1a/0x30
    Call Trace:
     submit_extent_page+0x191/0x270 [btrfs]
     ? btrfs_create_repair_bio+0x130/0x130 [btrfs]
     __do_readpage+0x2d2/0x810 [btrfs]
     ? btrfs_create_repair_bio+0x130/0x130 [btrfs]
     ? run_one_async_done+0xc0/0xc0 [btrfs]
     __extent_read_full_page+0xe7/0x100 [btrfs]
     ? run_one_async_done+0xc0/0xc0 [btrfs]
     read_extent_buffer_pages+0x1ab/0x2d0 [btrfs]
     ? run_one_async_done+0xc0/0xc0 [btrfs]
     btree_read_extent_buffer_pages+0x94/0xf0 [btrfs]
     read_tree_block+0x31/0x60 [btrfs]
     read_block_for_search.isra.35+0xf0/0x2e0 [btrfs]
     btrfs_search_slot+0x46b/0xa00 [btrfs]
     ? kmem_cache_alloc+0x1a8/0x510
     ? btrfs_get_token_32+0x5b/0x120 [btrfs]
     find_parent_nodes+0x11d/0xeb0 [btrfs]
     ? leaf_space_used+0xb8/0xd0 [btrfs]
     ? btrfs_leaf_free_space+0x49/0x90 [btrfs]
     ? btrfs_find_all_roots_safe+0x93/0x100 [btrfs]
     btrfs_find_all_roots_safe+0x93/0x100 [btrfs]
     btrfs_find_all_roots+0x45/0x60 [btrfs]
     btrfs_qgroup_trace_extent_post+0x20/0x40 [btrfs]
     btrfs_add_delayed_data_ref+0x1a3/0x1d0 [btrfs]
     btrfs_alloc_reserved_file_extent+0x38/0x40 [btrfs]
     insert_reserved_file_extent.constprop.71+0x289/0x2e0 [btrfs]
     btrfs_finish_ordered_io+0x2f4/0x7f0 [btrfs]
     ? pick_next_task_fair+0x2cd/0x530
     ? __switch_to+0x92/0x4b0
     btrfs_worker_helper+0x81/0x300 [btrfs]
     process_one_work+0x1da/0x3f0
     worker_thread+0x2b/0x3f0
     ? process_one_work+0x3f0/0x3f0
     kthread+0x11a/0x130
     ? kthread_create_on_node+0x40/0x40
     ret_from_fork+0x35/0x40
    
    BTRFS critical (device vda2): unable to find logical 8820195328 length 16384
    BTRFS: error (device vda2) in btrfs_finish_ordered_io:3023: errno=-5 IO failure
    BTRFS info (device vda2): forced readonly
    BTRFS error (device vda2): pending csums is 2887680
    
    [CAUSE]
    It's caused by race with block group auto removal:
    
    - There is a meta block group X, which has only one tree block
      The tree block belongs to fs tree 257.
    - In current transaction, some operation modified fs tree 257
      The tree block gets COWed, so the block group X is empty, and marked
      as unused, queued to be deleted.
    - Some workload (like fsync) wakes up cleaner_kthread()
      Which will call btrfs_delete_unused_bgs() to remove unused block
      groups.
      So block group X along its chunk map get removed.
    - Some delalloc work finished for fs tree 257
      Quota needs to get the original reference of the extent, which will
      read tree blocks of commit root of 257.
      Then since the chunk map gets removed, the above warning gets
      triggered.
    
    [FIX]
    Just let btrfs_delete_unused_bgs() skip block group which still has
    pinned bytes.
    
    However there is a minor side effect: currently we only queue empty
    blocks at update_block_group(), and such empty block group with pinned
    bytes won't go through update_block_group() again, such block group
    won't be removed, until it gets new extent allocated and removed.
    
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 510825b3f8c1f5dc29b81660e1eb68e7fb0b8d50
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jul 3 17:10:07 2018 +0800

    btrfs: relocation: Only remove reloc rb_trees if reloc control has been initialized
    
    [ Upstream commit 389305b2aa68723c754f88d9dbd268a400e10664 ]
    
    Invalid reloc tree can cause kernel NULL pointer dereference when btrfs
    does some cleanup of the reloc roots.
    
    It turns out that fs_info::reloc_ctl can be NULL in
    btrfs_recover_relocation() as we allocate relocation control after all
    reloc roots have been verified.
    So when we hit: note, we haven't called set_reloc_control() thus
    fs_info::reloc_ctl is still NULL.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199833
    Reported-by: Xu Wen <wen.xu@gatech.edu>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Tested-by: Gu Jinxiang <gujx@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit accb3e424b8b6b9fa51b77fcf7e6673f40d182a6
Author: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Date:   Tue Jul 31 16:20:21 2018 +0900

    btrfs: replace: Reset on-disk dev stats value after replace
    
    [ Upstream commit 1e7e1f9e3aba00c9b9c323bfeeddafe69ff21ff6 ]
    
    on-disk devs stats value is updated in btrfs_run_dev_stats(),
    which is called during commit transaction, if device->dev_stats_ccnt
    is not zero.
    
    Since current replace operation does not touch dev_stats_ccnt,
    on-disk dev stats value is not updated. Therefore "btrfs device stats"
    may return old device's value after umount/mount
    (Example: See "btrfs ins dump-t -t DEV $DEV" after btrfs/100 finish).
    
    Fix this by just incrementing dev_stats_ccnt in
    btrfs_dev_replace_finishing() when replace is succeeded and this will
    update the values.
    
    Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dc310f837540defcae83edde8bad940e12abcd1
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Date:   Wed Jul 4 23:27:02 2018 +0530

    powerpc/pseries: Avoid using the size greater than RTAS_ERROR_LOG_MAX.
    
    [ Upstream commit 74e96bf44f430cf7a01de19ba6cf49b361cdfd6e ]
    
    The global mce data buffer that used to copy rtas error log is of 2048
    (RTAS_ERROR_LOG_MAX) bytes in size. Before the copy we read
    extended_log_length from rtas error log header, then use max of
    extended_log_length and RTAS_ERROR_LOG_MAX as a size of data to be copied.
    Ideally the platform (phyp) will never send extended error log with
    size > 2048. But if that happens, then we have a risk of buffer overrun
    and corruption. Fix this by using min_t instead.
    
    Fixes: d368514c3097 ("powerpc: Fix corruption when grabbing FWNMI data")
    Reported-by: Michal Suchanek <msuchanek@suse.com>
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9997f8873511a1b50d1b1afdb645fe0f23e2b65
Author: Steve French <stfrench@microsoft.com>
Date:   Mon Jul 23 09:15:18 2018 -0500

    SMB3: Number of requests sent should be displayed for SMB3 not just CIFS
    
    [ Upstream commit 289131e1f1e6ad8c661ec05e176b8f0915672059 ]
    
    For SMB2/SMB3 the number of requests sent was not displayed
    in /proc/fs/cifs/Stats unless CONFIG_CIFS_STATS2 was
    enabled (only number of failed requests displayed). As
    with earlier dialects, we should be displaying these
    counters if CONFIG_CIFS_STATS is enabled. They
    are important for debugging.
    
    e.g. when you cat /proc/fs/cifs/Stats (before the patch)
    Resources in use
    CIFS Session: 1
    Share (unique mount targets): 2
    SMB Request/Response Buffer: 1 Pool size: 5
    SMB Small Req/Resp Buffer: 1 Pool size: 30
    Operations (MIDs): 0
    
    0 session 0 share reconnects
    Total vfs operations: 690 maximum at one time: 2
    
    1) \\localhost\test
    SMBs: 975
    Negotiates: 0 sent 0 failed
    SessionSetups: 0 sent 0 failed
    Logoffs: 0 sent 0 failed
    TreeConnects: 0 sent 0 failed
    TreeDisconnects: 0 sent 0 failed
    Creates: 0 sent 2 failed
    Closes: 0 sent 0 failed
    Flushes: 0 sent 0 failed
    Reads: 0 sent 0 failed
    Writes: 0 sent 0 failed
    Locks: 0 sent 0 failed
    IOCTLs: 0 sent 1 failed
    Cancels: 0 sent 0 failed
    Echos: 0 sent 0 failed
    QueryDirectories: 0 sent 63 failed
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6773f4061ceb8a4dbc655c386b2531b2db44b04
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Aug 1 00:56:12 2018 -0500

    smb3: fix reset of bytes read and written stats
    
    [ Upstream commit c281bc0c7412308c7ec0888904f7c99353da4796 ]
    
    echo 0 > /proc/fs/cifs/Stats is supposed to reset the stats
    but there were four (see example below) that were not reset
    (bytes read and witten, total vfs ops and max ops
    at one time).
    
    ...
    0 session 0 share reconnects
    Total vfs operations: 100 maximum at one time: 2
    
    1) \\localhost\test
    SMBs: 0
    Bytes read: 502092  Bytes written: 31457286
    TreeConnects: 0 total 0 failed
    TreeDisconnects: 0 total 0 failed
    ...
    
    This patch fixes cifs_stats_proc_write to properly reset
    those four.
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e676abeaf4b0c2dc46b5b47f78e72dcc66a9f9f
Author: Breno Leitao <leitao@debian.org>
Date:   Tue Aug 7 11:15:39 2018 -0300

    selftests/powerpc: Kill child processes on SIGINT
    
    [ Upstream commit 7c27a26e1ed5a7dd709aa19685d2c98f64e1cf0c ]
    
    There are some powerpc selftests, as tm/tm-unavailable, that run for a long
    period (>120 seconds), and if it is interrupted, as pressing CRTL-C
    (SIGINT), the foreground process (harness) dies but the child process and
    threads continue to execute (with PPID = 1 now) in background.
    
    In this case, you'd think the whole test exited, but there are remaining
    threads and processes being executed in background. Sometimes these
    zombies processes are doing annoying things, as consuming the whole CPU or
    dumping things to STDOUT.
    
    This patch fixes this problem by attaching an empty signal handler to
    SIGINT in the harness process. This handler will interrupt (EINTR) the
    parent process waitpid() call, letting the code to follow through the
    normal flow, which will kill all the processes in the child process group.
    
    This patch also fixes a typo.
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ad681c4ba53e507a11de6a5ee9af89d6c6de7e2
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Aug 6 11:05:13 2018 +0100

    staging: comedi: ni_mio_common: fix subdevice flags for PFI subdevice
    
    [ Upstream commit e083926b3e269d4064825dcf2ad50c636fddf8cf ]
    
    The PFI subdevice flags indicate that the subdevice is readable and
    writeable, but that is only true for the supported "M-series" boards,
    not the older "E-series" boards.  Only set the SDF_READABLE and
    SDF_WRITABLE subdevice flags for the M-series boards.  These two flags
    are mainly for informational purposes.
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66236f1b06f6d2564fa49247cb4d26612fd6c23f
Author: John Pittman <jpittman@redhat.com>
Date:   Mon Aug 6 15:53:12 2018 -0400

    dm kcopyd: avoid softlockup in run_complete_job
    
    [ Upstream commit 784c9a29e99eb40b842c29ecf1cc3a79e00fb629 ]
    
    It was reported that softlockups occur when using dm-snapshot ontop of
    slow (rbd) storage.  E.g.:
    
    [ 4047.990647] watchdog: BUG: soft lockup - CPU#10 stuck for 22s! [kworker/10:23:26177]
    ...
    [ 4048.034151] Workqueue: kcopyd do_work [dm_mod]
    [ 4048.034156] RIP: 0010:copy_callback+0x41/0x160 [dm_snapshot]
    ...
    [ 4048.034190] Call Trace:
    [ 4048.034196]  ? __chunk_is_tracked+0x70/0x70 [dm_snapshot]
    [ 4048.034200]  run_complete_job+0x5f/0xb0 [dm_mod]
    [ 4048.034205]  process_jobs+0x91/0x220 [dm_mod]
    [ 4048.034210]  ? kcopyd_put_pages+0x40/0x40 [dm_mod]
    [ 4048.034214]  do_work+0x46/0xa0 [dm_mod]
    [ 4048.034219]  process_one_work+0x171/0x370
    [ 4048.034221]  worker_thread+0x1fc/0x3f0
    [ 4048.034224]  kthread+0xf8/0x130
    [ 4048.034226]  ? max_active_store+0x80/0x80
    [ 4048.034227]  ? kthread_bind+0x10/0x10
    [ 4048.034231]  ret_from_fork+0x35/0x40
    [ 4048.034233] Kernel panic - not syncing: softlockup: hung tasks
    
    Fix this by calling cond_resched() after run_complete_job()'s callout to
    the dm_kcopyd_notify_fn (which is dm-snap.c:copy_callback in the above
    trace).
    
    Signed-off-by: John Pittman <jpittman@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d07bbe50d1b7e98fb1afeed62506c28dd1a21700
Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Fri Aug 3 16:38:44 2018 +0200

    PCI: mvebu: Fix I/O space end address calculation
    
    [ Upstream commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 ]
    
    pcie->realio.end should be the address of last byte of the area,
    therefore using resource_size() of another resource is not correct, we
    must substract 1 to get the address of the last byte.
    
    Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 242343ebf645ca5c89aac3ee9503484177c7bb6a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Aug 8 17:29:09 2018 +0300

    scsi: aic94xx: fix an error code in aic94xx_init()
    
    [ Upstream commit 0756c57bce3d26da2592d834d8910b6887021701 ]
    
    We accidentally return success instead of -ENOMEM on this error path.
    
    Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4057a20078fe3259f6e898ce41968928966f0116
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Wed Jul 25 14:00:47 2018 +0200

    s390/dasd: fix hanging offline processing due to canceled worker
    
    [ Upstream commit 669f3765b755fd8739ab46ce3a9c6292ce8b3d2a ]
    
    During offline processing two worker threads are canceled without
    freeing the device reference which leads to a hanging offline process.
    
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f675ab001e78e6bff87bfd0018175119c3a5796b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Aug 8 14:57:24 2018 +0300

    powerpc: Fix size calculation using resource_size()
    
    [ Upstream commit c42d3be0c06f0c1c416054022aa535c08a1f9b39 ]
    
    The problem is the the calculation should be "end - start + 1" but the
    plus one is missing in this calculation.
    
    Fixes: 8626816e905e ("powerpc: add support for MPIC message register API")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75c55cbd46b15113f74a31ddfc8fa0930826e371
Author: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Date:   Tue Jul 17 19:14:45 2018 -0700

    net/9p: fix error path of p9_virtio_probe
    
    [ Upstream commit 92aef4675d5b1b55404e1532379e343bed0e5cf2 ]
    
    Currently when virtio_find_single_vq fails, we go through del_vqs which
    throws a warning (Trying to free already-free IRQ).  Skip del_vqs if vq
    allocation failed.
    
    Link: http://lkml.kernel.org/r/20180524101021.49880-1-jean-philippe.brucker@arm.com
    Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
    Reviewed-by: Greg Kurz <groug@kaod.org>
    Cc: Eric Van Hensbergen <ericvh@gmail.com>
    Cc: Ron Minnich <rminnich@sandia.gov>
    Cc: Latchesar Ionkov <lucho@ionkov.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3537179891cae88b1f115af01b10c57594a31d71
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Thu Aug 9 10:59:01 2018 +0200

    irqchip/bcm7038-l1: Hide cpu offline callback when building for !SMP
    
    [ Upstream commit 0702bc4d2fe793018ad9aa0eb14bff7f526c4095 ]
    
    When compiling bmips with SMP disabled, the build fails with:
    
    drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline':
    drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to `irq_set_affinity_locked'
    make[5]: *** [vmlinux] Error 1
    
    Fix this by adding and setting bcm7038_l1_cpu_offline only when actually
    compiling for SMP. It wouldn't have been used anyway, as it requires
    CPU_HOTPLUG, which in turn requires SMP.
    
    Fixes: 34c535793bcb ("irqchip/bcm7038-l1: Implement irq_cpu_offline() callback")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad09041e9335398ab36fcaaf50fa3c4e7b8a29f7
Author: Aleh Filipovich <aleh@vaolix.com>
Date:   Fri Aug 10 22:07:25 2018 +0200

    platform/x86: asus-nb-wmi: Add keymap entry for lid flip action on UX360
    
    [ Upstream commit 880b29ac107d15644bf4da228376ba3cd6af6d71 ]
    
    Add entry to WMI keymap for lid flip event on Asus UX360.
    
    On Asus Zenbook ux360 flipping lid from/to tablet mode triggers
    keyscan code 0xfa which cannot be handled and results in kernel
    log message "Unknown key fa pressed".
    
    Signed-off-by: Aleh Filipovich<aleh@appnexus.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a429a299eb4836e03d40683d7cc723b07d3ad6bd
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Fri Aug 3 20:59:51 2018 -0700

    mfd: sm501: Set coherent_dma_mask when creating subdevices
    
    [ Upstream commit 2f606da78230f09cf1a71fde6ee91d0c710fa2b2 ]
    
    Instantiating the sm501 OHCI subdevice results in a kernel warning.
    
    sm501-usb sm501-usb: SM501 OHCI
    sm501-usb sm501-usb: new USB bus registered, assigned bus number 1
    WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
    ohci_init+0x194/0x2d8
    Modules linked in:
    
    CPU: 0 PID: 1 Comm: swapper Tainted: G        W
    4.18.0-rc7-00178-g0b5b1f9a78b5 #1
    PC is at ohci_init+0x194/0x2d8
    PR is at ohci_init+0x168/0x2d8
    PC  : 8c27844c SP  : 8f81dd94 SR  : 40008001
    TEA : 29613060
    R0  : 00000000 R1  : 00000000 R2  : 00000000 R3  : 00000202
    R4  : 8fa98b88 R5  : 8c277e68 R6  : 00000000 R7  : 00000000
    R8  : 8f965814 R9  : 8c388100 R10 : 8fa98800 R11 : 8fa98928
    R12 : 8c48302c R13 : 8fa98920 R14 : 8c48302c
    MACH: 00000096 MACL: 0000017c GBR : 00000000 PR  : 8c278420
    
    Call trace:
     [<(ptrval)>] usb_add_hcd+0x1e8/0x6ec
     [<(ptrval)>] _dev_info+0x0/0x54
     [<(ptrval)>] arch_local_save_flags+0x0/0x8
     [<(ptrval)>] arch_local_irq_restore+0x0/0x24
     [<(ptrval)>] ohci_hcd_sm501_drv_probe+0x114/0x2d8
    ...
    
    Initialize coherent_dma_mask when creating SM501 subdevices to fix
    the problem.
    
    Fixes: b6d6454fdb66f ("mfd: SM501 core driver")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ebf605de623c307db846463892267671db6b58b
Author: Tan Hu <tan.hu@zte.com.cn>
Date:   Wed Jul 25 15:23:07 2018 +0800

    ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest()
    
    [ Upstream commit a53b42c11815d2357e31a9403ae3950517525894 ]
    
    We came across infinite loop in ipvs when using ipvs in docker
    env.
    
    When ipvs receives new packets and cannot find an ipvs connection,
    it will create a new connection, then if the dest is unavailable
    (i.e. IP_VS_DEST_F_AVAILABLE), the packet will be dropped sliently.
    
    But if the dropped packet is the first packet of this connection,
    the connection control timer never has a chance to start and the
    ipvs connection cannot be released. This will lead to memory leak, or
    infinite loop in cleanup_net() when net namespace is released like
    this:
    
        ip_vs_conn_net_cleanup at ffffffffa0a9f31a [ip_vs]
        __ip_vs_cleanup at ffffffffa0a9f60a [ip_vs]
        ops_exit_list at ffffffff81567a49
        cleanup_net at ffffffff81568b40
        process_one_work at ffffffff810a851b
        worker_thread at ffffffff810a9356
        kthread at ffffffff810b0b6f
        ret_from_fork at ffffffff81697a18
    
    race condition:
        CPU1                           CPU2
        ip_vs_in()
          ip_vs_conn_new()
                                       ip_vs_del_dest()
                                         __ip_vs_unlink_dest()
                                           ~IP_VS_DEST_F_AVAILABLE
          cp->dest && !IP_VS_DEST_F_AVAILABLE
          __ip_vs_conn_put
        ...
        cleanup_net  ---> infinite looping
    
    Fix this by checking whether the timer already started.
    
    Signed-off-by: Tan Hu <tan.hu@zte.com.cn>
    Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Acked-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90d91af021986c31f14591e5e343fcf7293adda2
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri Aug 17 15:44:34 2018 -0700

    fs/dcache.c: fix kmemcheck splat at take_dentry_name_snapshot()
    
    [ Upstream commit 6cd00a01f0c1ae6a852b09c59b8dd55cc6c35d1d ]
    
    Since only dentry->d_name.len + 1 bytes out of DNAME_INLINE_LEN bytes
    are initialized at __d_alloc(), we can't copy the whole size
    unconditionally.
    
     WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff8fa27465ac50)
     636f6e66696766732e746d70000000000010000000000000020000000188ffff
      i i i i i i i i i i i i i u u u u u u u u u u i i i i i u u u u
                                      ^
     RIP: 0010:take_dentry_name_snapshot+0x28/0x50
     RSP: 0018:ffffa83000f5bdf8 EFLAGS: 00010246
     RAX: 0000000000000020 RBX: ffff8fa274b20550 RCX: 0000000000000002
     RDX: ffffa83000f5be40 RSI: ffff8fa27465ac50 RDI: ffffa83000f5be60
     RBP: ffffa83000f5bdf8 R08: ffffa83000f5be48 R09: 0000000000000001
     R10: ffff8fa27465ac00 R11: ffff8fa27465acc0 R12: ffff8fa27465ac00
     R13: ffff8fa27465acc0 R14: 0000000000000000 R15: 0000000000000000
     FS:  00007f79737ac8c0(0000) GS:ffffffff8fc30000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: ffff8fa274c0b000 CR3: 0000000134aa7002 CR4: 00000000000606f0
      take_dentry_name_snapshot+0x28/0x50
      vfs_rename+0x128/0x870
      SyS_rename+0x3b2/0x3d0
      entry_SYSCALL_64_fastpath+0x1a/0xa4
      0xffffffffffffffff
    
    Link: http://lkml.kernel.org/r/201709131912.GBG39012.QMJLOVFSFFOOtH@I-love.SAKURA.ne.jp
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Vegard Nossum <vegard.nossum@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ca3b3df6d52aff8b42271a23d7f2218672cfbf8
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Fri Aug 17 15:46:57 2018 -0700

    mm/fadvise.c: fix signed overflow UBSAN complaint
    
    [ Upstream commit a718e28f538441a3b6612da9ff226973376cdf0f ]
    
    Signed integer overflow is undefined according to the C standard.  The
    overflow in ksys_fadvise64_64() is deliberate, but since it is signed
    overflow, UBSAN complains:
    
            UBSAN: Undefined behaviour in mm/fadvise.c:76:10
            signed integer overflow:
            4 + 9223372036854775805 cannot be represented in type 'long long int'
    
    Use unsigned types to do math.  Unsigned overflow is defined so UBSAN
    will not complain about it.  This patch doesn't change generated code.
    
    [akpm@linux-foundation.org: add comment explaining the casts]
    Link: http://lkml.kernel.org/r/20180629184453.7614-1-aryabinin@virtuozzo.com
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Reported-by: <icytxw@gmail.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af25dc4cf354bee251a422c4c7ed1bb6b7dd1649
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Aug 15 12:30:38 2018 -0700

    scripts: modpost: check memory allocation results
    
    [ Upstream commit 1f3aa9002dc6a0d59a4b599b4fc8f01cf43ef014 ]
    
    Fix missing error check for memory allocation functions in
    scripts/mod/modpost.c.
    
    Fixes kernel bugzilla #200319:
    https://bugzilla.kernel.org/show_bug.cgi?id=200319
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Yuexing Wang <wangyxlandq@gmail.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 192710dab763194ca62d2169cf282a88888291a0
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Tue Aug 21 21:59:44 2018 -0700

    fat: validate ->i_start before using
    
    [ Upstream commit 0afa9626667c3659ef8bd82d42a11e39fedf235c ]
    
    On corrupted FATfs may have invalid ->i_start.  To handle it, this checks
    ->i_start before using, and return proper error code.
    
    Link: http://lkml.kernel.org/r/87o9f8y1t5.fsf_-_@mail.parknet.co.jp
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Tested-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fed5bd3352a3fbf9494449ffee3b4bab5e8cc3a6
Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Date:   Thu Aug 23 17:00:25 2018 -0700

    hfsplus: fix NULL dereference in hfsplus_lookup()
    
    [ Upstream commit a7ec7a4193a2eb3b5341243fc0b621c1ac9e4ec4 ]
    
    An HFS+ filesystem can be mounted read-only without having a metadata
    directory, which is needed to support hardlinks.  But if the catalog
    data is corrupted, a directory lookup may still find dentries claiming
    to be hardlinks.
    
    hfsplus_lookup() does check that ->hidden_dir is not NULL in such a
    situation, but mistakenly does so after dereferencing it for the first
    time.  Reorder this check to prevent a crash.
    
    This happens when looking up corrupted catalog data (dentry) on a
    filesystem with no metadata directory (this could only ever happen on a
    read-only mount).  Wen Xu sent the replication steps in detail to the
    fsdevel list: https://bugzilla.kernel.org/show_bug.cgi?id=200297
    
    Link: http://lkml.kernel.org/r/20180712215344.q44dyrhymm4ajkao@eaf
    Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Cc: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccbe4990bb1bf84a425015f68d7e7a2b9d1b3f8a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Aug 21 21:59:34 2018 -0700

    reiserfs: change j_timestamp type to time64_t
    
    [ Upstream commit 8b73ce6a4bae4fe12bcb2c361c0da4183c2e1b6f ]
    
    This uses the deprecated time_t type but is write-only, and could be
    removed, but as Jeff explains, having a timestamp can be usefule for
    post-mortem analysis in crash dumps.
    
    In order to remove one of the last instances of time_t, this changes the
    type to time64_t, same as j_trans_start_time.
    
    Link: http://lkml.kernel.org/r/20180622133315.221210-1-arnd@arndb.de
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7befd11e0b259699ed1ee69dd3ee66da25b2d5e
Author: Jann Horn <jannh@google.com>
Date:   Tue Aug 21 22:00:58 2018 -0700

    fork: don't copy inconsistent signal handler state to child
    
    [ Upstream commit 06e62a46bbba20aa5286102016a04214bb446141 ]
    
    Before this change, if a multithreaded process forks while one of its
    threads is changing a signal handler using sigaction(), the memcpy() in
    copy_sighand() can race with the struct assignment in do_sigaction().  It
    isn't clear whether this can cause corruption of the userspace signal
    handler pointer, but it definitely can cause inconsistency between
    different fields of struct sigaction.
    
    Take the appropriate spinlock to avoid this.
    
    I have tested that this patch prevents inconsistency between sa_sigaction
    and sa_flags, which is possible before this patch.
    
    Link: http://lkml.kernel.org/r/20180702145108.73189-1-jannh@google.com
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 189ff5b00004072b63969ea28b8d1512a651892c
Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Date:   Thu Aug 23 17:00:31 2018 -0700

    hfs: prevent crash on exit from failed search
    
    [ Upstream commit dc2572791d3a41bab94400af2b6bca9d71ccd303 ]
    
    hfs_find_exit() expects fd->bnode to be NULL after a search has failed.
    hfs_brec_insert() may instead set it to an error-valued pointer.  Fix
    this to prevent a crash.
    
    Link: http://lkml.kernel.org/r/53d9749a029c41b4016c495fc5838c9dba3afc52.1530294815.git.ernesto.mnd.fernandez@gmail.com
    Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
    Cc: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Cc: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14957e348e78a760f70b7c31ed8573fd8b1c5e9e
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Tue Aug 21 21:59:12 2018 -0700

    hfsplus: don't return 0 when fill_super() failed
    
    [ Upstream commit 7464726cb5998846306ed0a7d6714afb2e37b25d ]
    
    syzbot is reporting NULL pointer dereference at mount_fs() [1].  This is
    because hfsplus_fill_super() is by error returning 0 when
    hfsplus_fill_super() detected invalid filesystem image, and mount_bdev()
    is returning NULL because dget(s->s_root) == NULL if s->s_root == NULL,
    and mount_fs() is accessing root->d_sb because IS_ERR(root) == false if
    root == NULL.  Fix this by returning -EINVAL when hfsplus_fill_super()
    detected invalid filesystem image.
    
    [1] https://syzkaller.appspot.com/bug?id=21acb6850cecbc960c927229e597158cf35f33d0
    
    Link: http://lkml.kernel.org/r/d83ce31a-874c-dd5b-f790-41405983a5be@I-love.SAKURA.ne.jp
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot <syzbot+01ffaf5d9568dd1609f7@syzkaller.appspotmail.com>
    Reviewed-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d98ec8a9e205f885f66b5a0890daa3ce3d2cac74
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Wed Aug 22 12:19:24 2018 +1000

    cifs: check if SMB2 PDU size has been padded and suppress the warning
    
    [ Upstream commit e6c47dd0da1e3a484e778046fc10da0b20606a86 ]
    
    Some SMB2/3 servers, Win2016 but possibly others too, adds padding
    not only between PDUs in a compound but also to the final PDU.
    This padding extends the PDU to a multiple of 8 bytes.
    
    Check if the unexpected length looks like this might be the case
    and avoid triggering the log messages for :
    
      "SMB2 server sent bad RFC1001 len %d not %d\n"
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4890349d7902027cd7380c7a0e23f429907473e9
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date:   Thu Aug 23 19:49:54 2018 +0300

    vti6: remove !skb->ignore_df check from vti6_xmit()
    
    [ Upstream commit 9f2895461439fda2801a7906fb4c5fb3dbb37a0a ]
    
    Before the commit d6990976af7c ("vti6: fix PMTU caching and reporting
    on xmit") '!skb->ignore_df' check was always true because the function
    skb_scrub_packet() was called before it, resetting ignore_df to zero.
    
    In the commit, skb_scrub_packet() was moved below, and now this check
    can be false for the packet, e.g. when sending it in the two fragments,
    this prevents successful PMTU updates in such case. The next attempts
    to send the packet lead to the same tx error. Moreover, vti6 initial
    MTU value relies on PMTU adjustments.
    
    This issue can be reproduced with the following LTP test script:
        udp_ipsec_vti.sh -6 -p ah -m tunnel -s 2000
    
    Fixes: ccd740cbc6e0 ("vti6: Add pmtu handling to vti6_xmit.")
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86a0a00794c21b35c72d767a98fb917b5b76b513
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 30 14:24:29 2018 +0200

    tcp: do not restart timewait timer on rst reception
    
    [ Upstream commit 63cc357f7bba6729869565a12df08441a5995d9a ]
    
    RFC 1337 says:
     ''Ignore RST segments in TIME-WAIT state.
       If the 2 minute MSL is enforced, this fix avoids all three hazards.''
    
    So with net.ipv4.tcp_rfc1337=1, expected behaviour is to have TIME-WAIT sk
    expire rather than removing it instantly when a reset is received.
    
    However, Linux will also re-start the TIME-WAIT timer.
    
    This causes connect to fail when tying to re-use ports or very long
    delays (until syn retry interval exceeds MSL).
    
    packetdrill test case:
    // Demonstrate bogus rearming of TIME-WAIT timer in rfc1337 mode.
    `sysctl net.ipv4.tcp_rfc1337=1`
    
    0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
    0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
    0.000 bind(3, ..., ...) = 0
    0.000 listen(3, 1) = 0
    
    0.100 < S 0:0(0) win 29200 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    0.100 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    0.200 < . 1:1(0) ack 1 win 257
    0.200 accept(3, ..., ...) = 4
    
    // Receive first segment
    0.310 < P. 1:1001(1000) ack 1 win 46
    
    // Send one ACK
    0.310 > . 1:1(0) ack 1001
    
    // read 1000 byte
    0.310 read(4, ..., 1000) = 1000
    
    // Application writes 100 bytes
    0.350 write(4, ..., 100) = 100
    0.350 > P. 1:101(100) ack 1001
    
    // ACK
    0.500 < . 1001:1001(0) ack 101 win 257
    
    // close the connection
    0.600 close(4) = 0
    0.600 > F. 101:101(0) ack 1001 win 244
    
    // Our side is in FIN_WAIT_1 & waits for ack to fin
    0.7 < . 1001:1001(0) ack 102 win 244
    
    // Our side is in FIN_WAIT_2 with no outstanding data.
    0.8 < F. 1001:1001(0) ack 102 win 244
    0.8 > . 102:102(0) ack 1002 win 244
    
    // Our side is now in TIME_WAIT state, send ack for fin.
    0.9 < F. 1002:1002(0) ack 102 win 244
    0.9 > . 102:102(0) ack 1002 win 244
    
    // Peer reopens with in-window SYN:
    1.000 < S 1000:1000(0) win 9200 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    
    // Therefore, reply with ACK.
    1.000 > . 102:102(0) ack 1002 win 244
    
    // Peer sends RST for this ACK.  Normally this RST results
    // in tw socket removal, but rfc1337=1 setting prevents this.
    1.100 < R 1002:1002(0) win 244
    
    // second syn. Due to rfc1337=1 expect another pure ACK.
    31.0 < S 1000:1000(0) win 9200 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    31.0 > . 102:102(0) ack 1002 win 244
    
    // .. and another RST from peer.
    31.1 < R 1002:1002(0) win 244
    31.2 `echo no timer restart;ss -m -e -a -i -n -t -o state TIME-WAIT`
    
    // third syn after one minute.  Time-Wait socket should have expired by now.
    63.0 < S 1000:1000(0) win 9200 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    
    // so we expect a syn-ack & 3whs to proceed from here on.
    63.0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
    
    Without this patch, 'ss' shows restarts of tw timer and last packet is
    thus just another pure ack, more than one minute later.
    
    This restores the original code from commit 283fd6cf0be690a83
    ("Merge in ANK networking jumbo patch") in netdev-vger-cvs.git .
    
    For some reason the else branch was removed/lost in 1f28b683339f7
    ("Merge in TCP/UDP optimizations and [..]") and timer restart became
    unconditional.
    
    Reported-by: Michal Tesar <mtesar@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 375e88743c94e9b9871b9e50c66e11b40667530f
Author: Manish Chopra <manish.chopra@cavium.com>
Date:   Thu Aug 23 13:20:52 2018 -0700

    qlge: Fix netdev features configuration.
    
    [ Upstream commit 6750c87074c5b534d82fdaabb1deb45b8f1f57de ]
    
    qlge_fix_features() is not supposed to modify hardware or
    driver state, rather it is supposed to only fix requested
    fetures bits. Currently qlge_fix_features() also goes for
    interface down and up unnecessarily if there is not even
    any change in features set.
    
    This patch changes/fixes following -
    
    1) Move reload of interface or device re-config from
       qlge_fix_features() to qlge_set_features().
    2) Reload of interface in qlge_set_features() only if
       relevant feature bit (NETIF_F_HW_VLAN_CTAG_RX) is changed.
    3) Get rid of qlge_fix_features() since driver is not really
       required to fix any features bit.
    
    Signed-off-by: Manish <manish.chopra@cavium.com>
    Reviewed-by: Benjamin Poirier <bpoirier@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1e4b0be0dec7bd5fb1f125c942770903f7d6eb1
Author: Doug Berger <opendmb@gmail.com>
Date:   Tue Aug 28 12:33:15 2018 -0700

    net: bcmgenet: use MAC link status for fixed phy
    
    [ Upstream commit c3c397c1f16c51601a3fac4fe0c63ad8aa85a904 ]
    
    When using the fixed PHY with GENET (e.g. MOCA) the PHY link
    status can be determined from the internal link status captured
    by the MAC. This allows the PHY state machine to use the correct
    link state with the fixed PHY even if MAC link event interrupts
    are missed when the net device is opened.
    
    Fixes: 8d88c6ebb34c ("net: bcmgenet: enable MoCA link state change detection")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Reviewed-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 2c155709e4ef2d86d0176aac82e44c048a7e0255
Author: Greg Hackmann <ghackmann@android.com>
Date:   Tue Sep 4 09:33:36 2018 -0700

    staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free
    
    The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
    times while operating on one of the client's ion_handles.  This creates
    windows where userspace can call ION_IOC_FREE on the same client with
    the same handle, and effectively make the kernel drop its own reference.
    For example:
    
    - thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
    - thread A: starts ION_IOC_MAP and increments the refcount to 2
    - thread B: ION_IOC_FREE decrements the refcount to 1
    - thread B: ION_IOC_FREE decrements the refcount to 0 and frees the
                handle
    - thread A: continues ION_IOC_MAP with a dangling ion_handle * to
                freed memory
    
    Fix this by holding client->lock for the duration of
    ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE.  Also
    remove ion_handle_get_by_id(), since there's literally no way to use it
    safely.
    
    This patch is applied on top of 4.4.y, and applies to older kernels
    too.  4.9.y was fixed separately.  Kernels 4.12 and later are
    unaffected, since all the underlying ion_handle infrastructure has been
    ripped out.
    
    Cc: stable@vger.kernel.org # v4.4-
    Signed-off-by: Greg Hackmann <ghackmann@google.com>
    Acked-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3dea38fc8528c9d04acd9a28bcdd7dab3b461fa
Author: Michal Hocko <mhocko@suse.cz>
Date:   Wed Jun 27 17:46:50 2018 +0200

    x86/speculation/l1tf: Fix up pte->pfn conversion for PAE
    
    commit e14d7dfb41f5807a0c1c26a13f2b8ef16af24935 upstream.
    
    Jan has noticed that pte_pfn and co. resp. pfn_pte are incorrect for
    CONFIG_PAE because phys_addr_t is wider than unsigned long and so the
    pte_val reps. shift left would get truncated. Fix this up by using proper
    types.
    
    [Just one chunk, again, needed here.  Thanks to Ben and Guenter for
    finding and fixing this. - gregkh]
    
    Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation")
    Reported-by: Jan Beulich <JBeulich@suse.com>
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>