1. 21 Nov, 2018 40 commits
    • Jarod Wilson's avatar
      bonding/802.3ad: fix link_failure_count tracking · 218b6e82
      Jarod Wilson authored
      commit ea53abfa upstream.
      
      Commit 4d2c0cda set slave->link to
      BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
      were read, to fix a problem with slaves getting into weird states, but
      in the process, broke tracking of link failures, as going straight to
      BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
      means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
      !link_state was already true, we never incremented commit, and never got
      a chance to call bond_miimon_commit(), where slave->link_failure_count
      would be incremented. I believe the simple fix here is to mark the slave
      as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
      _FAIL to either _UP or _DOWN, and in the latter case, we now get proper
      incrementing of link_failure_count again.
      
      Fixes: 4d2c0cda ("bonding: speed/duplex update at NETDEV_UP event")
      CC: Mahesh Bandewar <maheshb@google.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      218b6e82
    • Ard Biesheuvel's avatar
      ARM: 8809/1: proc-v7: fix Thumb annotation of cpu_v7_hvc_switch_mm · 9333523b
      Ard Biesheuvel authored
      commit 6282e916 upstream.
      
      Due to what appears to be a copy/paste error, the opening ENTRY()
      of cpu_v7_hvc_switch_mm() lacks a matching ENDPROC(), and instead,
      the one for cpu_v7_smc_switch_mm() is duplicated.
      
      Given that it is ENDPROC() that emits the Thumb annotation, the
      cpu_v7_hvc_switch_mm() routine will be called in ARM mode on a
      Thumb2 kernel, resulting in the following splat:
      
        Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc1-00030-g4d28ad89189d-dirty #488
        Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
        PC is at cpu_v7_hvc_switch_mm+0x12/0x18
        LR is at flush_old_exec+0x31b/0x570
        pc : [<c0316efe>]    lr : [<c04117c7>]    psr: 00000013
        sp : ee899e50  ip : 00000000  fp : 00000001
        r10: eda28f34  r9 : eda31800  r8 : c12470e0
        r7 : eda1fc00  r6 : eda53000  r5 : 00000000  r4 : ee88c000
        r3 : c0316eec  r2 : 00000001  r1 : eda53000  r0 : 6da6c000
        Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      
      Note the 'ISA ARM' in the last line.
      
      Fix this by using the correct name in ENDPROC().
      
      Cc: <stable@vger.kernel.org>
      Fixes: 10115105 ("ARM: spectre-v2: add firmware based hardening")
      Reviewed-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9333523b
    • Vasily Khoruzhick's avatar
      netfilter: conntrack: fix calculation of next bucket number in early_drop · 1be1576a
      Vasily Khoruzhick authored
      commit f393808d upstream.
      
      If there's no entry to drop in bucket that corresponds to the hash,
      early_drop() should look for it in other buckets. But since it increments
      hash instead of bucket number, it actually looks in the same bucket 8
      times: hsize is 16k by default (14 bits) and hash is 32-bit value, so
      reciprocal_scale(hash, hsize) returns the same value for hash..hash+7 in
      most cases.
      
      Fix it by increasing bucket number instead of hash and rename _hash
      to bucket to avoid future confusion.
      
      Fixes: 3e86638e ("netfilter: conntrack: consider ct netns in early_drop logic")
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: default avatarVasily Khoruzhick <vasilykh@arista.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1be1576a
    • Michal Hocko's avatar
      memory_hotplug: cond_resched in __remove_pages · ccd35ba5
      Michal Hocko authored
      commit dd33ad7b upstream.
      
      We have received a bug report that unbinding a large pmem (>1TB) can
      result in a soft lockup:
      
        NMI watchdog: BUG: soft lockup - CPU#9 stuck for 23s! [ndctl:4365]
        [...]
        Supported: Yes
        CPU: 9 PID: 4365 Comm: ndctl Not tainted 4.12.14-94.40-default #1 SLE12-SP4
        Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.01.00.0833.051120182255 05/11/2018
        task: ffff9cce7d4410c0 task.stack: ffffbe9eb1bc4000
        RIP: 0010:__put_page+0x62/0x80
        Call Trace:
         devm_memremap_pages_release+0x152/0x260
         release_nodes+0x18d/0x1d0
         device_release_driver_internal+0x160/0x210
         unbind_store+0xb3/0xe0
         kernfs_fop_write+0x102/0x180
         __vfs_write+0x26/0x150
         vfs_write+0xad/0x1a0
         SyS_write+0x42/0x90
         do_syscall_64+0x74/0x150
         entry_SYSCALL_64_after_hwframe+0x3d/0xa2
        RIP: 0033:0x7fd13166b3d0
      
      It has been reported on an older (4.12) kernel but the current upstream
      code doesn't cond_resched in the hot remove code at all and the given
      range to remove might be really large.  Fix the issue by calling
      cond_resched once per memory section.
      
      Link: http://lkml.kernel.org/r/20181031125840.23982-1-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ccd35ba5
    • Andrea Arcangeli's avatar
      mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings · 67a19f87
      Andrea Arcangeli authored
      commit ac5b2c18 upstream.
      
      THP allocation might be really disruptive when allocated on NUMA system
      with the local node full or hard to reclaim.  Stefan has posted an
      allocation stall report on 4.12 based SLES kernel which suggests the
      same issue:
      
        kvm: page allocation stalls for 194572ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null)
        kvm cpuset=/ mems_allowed=0-1
        CPU: 10 PID: 84752 Comm: kvm Tainted: G        W 4.12.0+98-ph <a href="/view.php?id=1" title="[geschlossen] Integration Ramdisk" class="resolved">0000001</a> SLE15 (unreleased)
        Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 12/05/2017
        Call Trace:
         dump_stack+0x5c/0x84
         warn_alloc+0xe0/0x180
         __alloc_pages_slowpath+0x820/0xc90
         __alloc_pages_nodemask+0x1cc/0x210
         alloc_pages_vma+0x1e5/0x280
         do_huge_pmd_wp_page+0x83f/0xf00
         __handle_mm_fault+0x93d/0x1060
         handle_mm_fault+0xc6/0x1b0
         __do_page_fault+0x230/0x430
         do_page_fault+0x2a/0x70
         page_fault+0x7b/0x80
         [...]
        Mem-Info:
        active_anon:126315487 inactive_anon:1612476 isolated_anon:5
         active_file:60183 inactive_file:245285 isolated_file:0
         unevictable:15657 dirty:286 writeback:1 unstable:0
         slab_reclaimable:75543 slab_unreclaimable:2509111
         mapped:81814 shmem:31764 pagetables:370616 bounce:0
         free:32294031 free_pcp:6233 free_cma:0
        Node 0 active_anon:254680388kB inactive_anon:1112760kB active_file:240648kB inactive_file:981168kB unevictable:13368kB isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
        Node 1 active_anon:250583072kB inactive_anon:5337144kB active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
      
      The defrag mode is "madvise" and from the above report it is clear that
      the THP has been allocated for MADV_HUGEPAGA vma.
      
      Andrea has identified that the main source of the problem is
      __GFP_THISNODE usage:
      
      : The problem is that direct compaction combined with the NUMA
      : __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very
      : hard the local node, instead of failing the allocation if there's no
      : THP available in the local node.
      :
      : Such logic was ok until __GFP_THISNODE was added to the THP allocation
      : path even with MPOL_DEFAULT.
      :
      : The idea behind the __GFP_THISNODE addition, is that it is better to
      : provide local memory in PAGE_SIZE units than to use remote NUMA THP
      : backed memory. That largely depends on the remote latency though, on
      : threadrippers for example the overhead is relatively low in my
      : experience.
      :
      : The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in
      : extremely slow qemu startup with vfio, if the VM is larger than the
      : size of one host NUMA node. This is because it will try very hard to
      : unsuccessfully swapout get_user_pages pinned pages as result of the
      : __GFP_THISNODE being set, instead of falling back to PAGE_SIZE
      : allocations and instead of trying to allocate THP on other nodes (it
      : would be even worse without vfio type1 GUP pins of course, except it'd
      : be swapping heavily instead).
      
      Fix this by removing __GFP_THISNODE for THP requests which are
      requesting the direct reclaim.  This effectivelly reverts 5265047a
      on the grounds that the zone/node reclaim was known to be disruptive due
      to premature reclaim when there was memory free.  While it made sense at
      the time for HPC workloads without NUMA awareness on rare machines, it
      was ultimately harmful in the majority of cases.  The existing behaviour
      is similar, if not as widespare as it applies to a corner case but
      crucially, it cannot be tuned around like zone_reclaim_mode can.  The
      default behaviour should always be to cause the least harm for the
      common case.
      
      If there are specialised use cases out there that want zone_reclaim_mode
      in specific cases, then it can be built on top.  Longterm we should
      consider a memory policy which allows for the node reclaim like behavior
      for the specific memory ranges which would allow a
      
      [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com
      
      Mel said:
      
      : Both patches look correct to me but I'm responding to this one because
      : it's the fix.  The change makes sense and moves further away from the
      : severe stalling behaviour we used to see with both THP and zone reclaim
      : mode.
      :
      : I put together a basic experiment with usemem configured to reference a
      : buffer multiple times that is 80% the size of main memory on a 2-socket
      : box with symmetric node sizes and defrag set to "always".  The defrag
      : setting is not the default but it would be functionally similar to
      : accessing a buffer with madvise(MADV_HUGEPAGE).  Usemem is configured to
      : reference the buffer multiple times and while it's not an interesting
      : workload, it would be expected to complete reasonably quickly as it fits
      : within memory.  The results were;
      :
      : usemem
      :                                   vanilla           noreclaim-v1
      : Amean     Elapsd-1       42.78 (   0.00%)       26.87 (  37.18%)
      : Amean     Elapsd-3       27.55 (   0.00%)        7.44 (  73.00%)
      : Amean     Elapsd-4        5.72 (   0.00%)        5.69 (   0.45%)
      :
      : This shows the elapsed time in seconds for 1 thread, 3 threads and 4
      : threads referencing buffers 80% the size of memory.  With the patches
      : applied, it's 37.18% faster for the single thread and 73% faster with two
      : threads.  Note that 4 threads showing little difference does not indicate
      : the problem is related to thread counts.  It's simply the case that 4
      : threads gets spread so their workload mostly fits in one node.
      :
      : The overall view from /proc/vmstats is more startling
      :
      :                          4.19.0-rc1  4.19.0-rc1
      :                             vanillanoreclaim-v1r1
      : Minor Faults               35593425      708164
      : Major Faults                 484088          36
      : Swap Ins                    3772837           0
      : Swap Outs                   3932295           0
      :
      : Massive amounts of swap in/out without the patch
      :
      : Direct pages scanned        6013214           0
      : Kswapd pages scanned              0           0
      : Kswapd pages reclaimed            0           0
      : Direct pages reclaimed      4033009           0
      :
      : Lots of reclaim activity without the patch
      :
      : Kswapd efficiency              100%        100%
      : Kswapd velocity               0.000       0.000
      : Direct efficiency               67%        100%
      : Direct velocity           11191.956       0.000
      :
      : Mostly from direct reclaim context as you'd expect without the patch.
      :
      : Page writes by reclaim  3932314.000       0.000
      : Page writes file                 19           0
      : Page writes anon            3932295           0
      : Page reclaim immediate        42336           0
      :
      : Writes from reclaim context is never good but the patch eliminates it.
      :
      : We should never have default behaviour to thrash the system for such a
      : basic workload.  If zone reclaim mode behaviour is ever desired but on a
      : single task instead of a global basis then the sensible option is to build
      : a mempolicy that enforces that behaviour.
      
      This was a severe regression compared to previous kernels that made
      important workloads unusable and it starts when __GFP_THISNODE was
      added to THP allocations under MADV_HUGEPAGE.  It is not a significant
      risk to go to the previous behavior before __GFP_THISNODE was added, it
      worked like that for years.
      
      This was simply an optimization to some lucky workloads that can fit in
      a single node, but it ended up breaking the VM for others that can't
      possibly fit in a single node, so going back is safe.
      
      [mhocko@suse.com: rewrote the changelog based on the one from Andrea]
      Link: http://lkml.kernel.org/r/20180925120326.24392-2-mhocko@kernel.org
      Fixes: 5265047a ("mm, thp: really limit transparent hugepage allocation to local node")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarStefan Priebe <s.priebe@profihost.ag>
      Debugged-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Tested-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Cc: Zi Yan <zi.yan@cs.rutgers.edu>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: <stable@vger.kernel.org>	[4.1+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67a19f87
    • Wengang Wang's avatar
      ocfs2: free up write context when direct IO failed · 6bb462a4
      Wengang Wang authored
      commit 5040f8df upstream.
      
      The write context should also be freed even when direct IO failed.
      Otherwise a memory leak is introduced and entries remain in
      oi->ip_unwritten_list causing the following BUG later in unlink path:
      
        ERROR: bug expression: !list_empty(&oi->ip_unwritten_list)
        ERROR: Clear inode of 215043, inode has unwritten extents
        ...
        Call Trace:
        ? __set_current_blocked+0x42/0x68
        ocfs2_evict_inode+0x91/0x6a0 [ocfs2]
        ? bit_waitqueue+0x40/0x33
        evict+0xdb/0x1af
        iput+0x1a2/0x1f7
        do_unlinkat+0x194/0x28f
        SyS_unlinkat+0x1b/0x2f
        do_syscall_64+0x79/0x1ae
        entry_SYSCALL_64_after_hwframe+0x151/0x0
      
      This patch also logs, with frequency limit, direct IO failures.
      
      Link: http://lkml.kernel.org/r/20181102170632.25921-1-wen.gang.wang@oracle.comSigned-off-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
      Reviewed-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Reviewed-by: default avatarJoseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bb462a4
    • Changwei Ge's avatar
      ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry · 148dc931
      Changwei Ge authored
      commit 29aa3016 upstream.
      
      Somehow, file system metadata was corrupted, which causes
      ocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().
      
      According to the original design intention, if above happens we should
      skip the problematic block and continue to retrieve dir entry.  But
      there is obviouse misuse of brelse around related code.
      
      After failure of ocfs2_check_dir_entry(), current code just moves to
      next position and uses the problematic buffer head again and again
      during which the problematic buffer head is released for multiple times.
      I suppose, this a serious issue which is long-lived in ocfs2.  This may
      cause other file systems which is also used in a the same host insane.
      
      So we should also consider about bakcporting this patch into linux
      -stable.
      
      Link: http://lkml.kernel.org/r/HK2PR06MB045211675B43EED794E597B6D56E0@HK2PR06MB0452.apcprd06.prod.outlook.comSigned-off-by: default avatarChangwei Ge <ge.changwei@h3c.com>
      Suggested-by: default avatarChangkuo Shi <shi.changkuo@h3c.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      148dc931
    • Marc Zyngier's avatar
      soc: ti: QMSS: Fix usage of irq_set_affinity_hint · 176e8d6d
      Marc Zyngier authored
      commit 832ad0e3 upstream.
      
      The Keystone QMSS driver is pretty damaged, in the sense that it
      does things like this:
      
      	irq_set_affinity_hint(irq, to_cpumask(&cpu_map));
      
      where cpu_map is a local variable. As we leave the function, this
      will point to nowhere-land, and things will end-up badly.
      
      Instead, let's use a proper cpumask that gets allocated, giving
      the driver a chance to actually work with things like irqbalance
      as well as have a hypothetical 64bit future.
      
      Cc: stable@vger.kernel.org
      Acked-by: default avatarSantosh Shilimkar <ssantosh@kernel.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      176e8d6d
    • Christophe Leroy's avatar
      Revert "powerpc/8xx: Use L1 entry APG to handle _PAGE_ACCESSED for CONFIG_SWAP" · ce65f0f6
      Christophe Leroy authored
      commit cc4ebf5c upstream.
      
      This reverts commit 4f94b2c7.
      
      That commit was buggy, as it used rlwinm instead of rlwimi.
      Instead of fixing that bug, we revert the previous commit in order to
      reduce the dependency between L1 entries and L2 entries
      
      Fixes: 4f94b2c7 ("powerpc/8xx: Use L1 entry APG to handle _PAGE_ACCESSED for CONFIG_SWAP")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce65f0f6
    • Ming Lei's avatar
      SCSI: fix queue cleanup race before queue initialization is done · 410306a0
      Ming Lei authored
      commit 8dc765d4 upstream.
      
      c2856ae2 ("blk-mq: quiesce queue before freeing queue") has
      already fixed this race, however the implied synchronize_rcu()
      in blk_mq_quiesce_queue() can slow down LUN probe a lot, so caused
      performance regression.
      
      Then 1311326c ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
      tried to quiesce queue for avoiding unnecessary synchronize_rcu()
      only when queue initialization is done, because it is usual to see
      lots of inexistent LUNs which need to be probed.
      
      However, turns out it isn't safe to quiesce queue only when queue
      initialization is done. Because when one SCSI command is completed,
      the user of sending command can be waken up immediately, then the
      scsi device may be removed, meantime the run queue in scsi_end_request()
      is still in-progress, so kernel panic can be caused.
      
      In Red Hat QE lab, there are several reports about this kind of kernel
      panic triggered during kernel booting.
      
      This patch tries to address the issue by grabing one queue usage
      counter during freeing one request and the following run queue.
      
      Fixes: 1311326c ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
      Cc: Andrew Jones <drjones@redhat.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: linux-scsi@vger.kernel.org
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: jianchao.wang <jianchao.w.wang@oracle.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      410306a0
    • Quinn Tran's avatar
      scsi: qla2xxx: Initialize port speed to avoid setting lower speed · dd2fb8c6
      Quinn Tran authored
      commit f635e48e upstream.
      
      This patch initializes port speed so that firmware does not set lower
      operating speed. Setting lower speed in firmware impacts WRITE perfomance.
      
      Fixes: 726b8548 ("qla2xxx: Add framework for async fabric discovery")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Tested-by: default avatarLaurence Oberman <loberman@redhat.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd2fb8c6
    • Greg Edwards's avatar
      vhost/scsi: truncate T10 PI iov_iter to prot_bytes · b1e99af9
      Greg Edwards authored
      commit 4542d623 upstream.
      
      Commands with protection information included were not truncating the
      protection iov_iter to the number of protection bytes in the command.
      This resulted in vhost_scsi mis-calculating the size of the protection
      SGL in vhost_scsi_calc_sgls(), and including both the protection and
      data SG entries in the protection SGL.
      
      Fixes: 09b13fa8 ("vhost/scsi: Add ANY_LAYOUT support in vhost_scsi_handle_vq")
      Signed-off-by: default avatarGreg Edwards <gedwards@ddn.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Fixes: 09b13fa8
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1e99af9
    • John Garry's avatar
      crypto: hisilicon - Fix reference after free of memories on error path · 12555475
      John Garry authored
      commit 0b0cf6af upstream.
      
      coccicheck currently warns of the following issues in the driver:
      drivers/crypto/hisilicon/sec/sec_algs.c:864:51-66: ERROR: reference preceded by free on line 812
      drivers/crypto/hisilicon/sec/sec_algs.c:864:40-49: ERROR: reference preceded by free on line 813
      drivers/crypto/hisilicon/sec/sec_algs.c:861:8-24: ERROR: reference preceded by free on line 814
      drivers/crypto/hisilicon/sec/sec_algs.c:860:41-51: ERROR: reference preceded by free on line 815
      drivers/crypto/hisilicon/sec/sec_algs.c:867:7-18: ERROR: reference preceded by free on line 816
      
      It would appear than on certain error paths that we may attempt reference-
      after-free some memories.
      
      This patch fixes those issues. The solution doesn't look perfect, but
      having same memories free'd possibly from separate functions makes it
      tricky.
      
      Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver")
      Reviewed-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12555475
    • John Garry's avatar
      crypto: hisilicon - Fix NULL dereference for same dst and src · 093d6ab5
      John Garry authored
      commit 68a031d2 upstream.
      
      When the source and destination addresses for the cipher are the same, we
      will get a NULL dereference from accessing the split destination
      scatterlist memories, as shown:
      
      [   56.565719] tcrypt:
      [   56.565719] testing speed of async ecb(aes) (hisi_sec_aes_ecb) encryption
      [   56.574683] tcrypt: test 0 (128 bit key, 16 byte blocks):
      [   56.587585] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      [   56.596361] Mem abort info:
      [   56.599151]   ESR = 0x96000006
      [   56.602196]   Exception class = DABT (current EL), IL = 32 bits
      [   56.608105]   SET = 0, FnV = 0
      [   56.611149]   EA = 0, S1PTW = 0
      [   56.614280] Data abort info:
      [   56.617151]   ISV = 0, ISS = 0x00000006
      [   56.620976]   CM = 0, WnR = 0
      [   56.623930] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
      [   56.630533] [0000000000000000] pgd=0000041fc7e4d003, pud=0000041fcd9bf003, pmd=0000000000000000
      [   56.639224] Internal error: Oops: 96000006 [#1] PREEMPT SMP
      [   56.644782] Modules linked in: tcrypt(+)
      [   56.648695] CPU: 21 PID: 2326 Comm: insmod Tainted: G        W         4.19.0-rc6-00001-g3fabfb8-dirty #716
      [   56.658420] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 10/05/2018
      [   56.667537] pstate: 20000005 (nzCv daif -PAN -UAO)
      [   56.672322] pc : sec_alg_skcipher_crypto+0x318/0x748
      [   56.677274] lr : sec_alg_skcipher_crypto+0x178/0x748
      [   56.682224] sp : ffff0000118e3840
      [   56.685525] x29: ffff0000118e3840 x28: ffff841fbb3f8118
      [   56.690825] x27: 0000000000000000 x26: 0000000000000000
      [   56.696125] x25: ffff841fbb3f8080 x24: ffff841fbadc0018
      [   56.701425] x23: ffff000009119000 x22: ffff841fbb24e280
      [   56.706724] x21: ffff841ff212e780 x20: ffff841ff212e700
      [   56.712023] x19: 0000000000000001 x18: ffffffffffffffff
      [   56.717322] x17: 0000000000000000 x16: 0000000000000000
      [   56.722621] x15: ffff0000091196c8 x14: 72635f7265687069
      [   56.727920] x13: 636b735f676c615f x12: ffff000009119940
      [   56.733219] x11: 0000000000000000 x10: 00000000006080c0
      [   56.738519] x9 : 0000000000000000 x8 : ffff841fbb24e480
      [   56.743818] x7 : ffff841fbb24e500 x6 : ffff841ff00cdcc0
      [   56.749117] x5 : 0000000000000010 x4 : 0000000000000000
      [   56.754416] x3 : ffff841fbb24e380 x2 : ffff841fbb24e480
      [   56.759715] x1 : 0000000000000000 x0 : ffff000008f682c8
      [   56.765016] Process insmod (pid: 2326, stack limit = 0x(____ptrval____))
      [   56.771702] Call trace:
      [   56.774136]  sec_alg_skcipher_crypto+0x318/0x748
      [   56.778740]  sec_alg_skcipher_encrypt+0x10/0x18
      [   56.783259]  test_skcipher_speed+0x2a0/0x700 [tcrypt]
      [   56.788298]  do_test+0x18f8/0x48c8 [tcrypt]
      [   56.792469]  tcrypt_mod_init+0x60/0x1000 [tcrypt]
      [   56.797161]  do_one_initcall+0x5c/0x178
      [   56.800985]  do_init_module+0x58/0x1b4
      [   56.804721]  load_module+0x1da4/0x2150
      [   56.808456]  __se_sys_init_module+0x14c/0x1e8
      [   56.812799]  __arm64_sys_init_module+0x18/0x20
      [   56.817231]  el0_svc_common+0x60/0xe8
      [   56.820880]  el0_svc_handler+0x2c/0x80
      [   56.824615]  el0_svc+0x8/0xc
      [   56.827483] Code: a94c87a3 910b2000 f87b7842 f9004ba2 (b87b7821)
      [   56.833564] ---[ end trace 0f63290590e93d94 ]---
      Segmentation fault
      
      Fix this by only accessing these memories when we have different src and
      dst.
      
      Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver")
      Reviewed-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      093d6ab5
    • Gustavo A. R. Silva's avatar
      reset: hisilicon: fix potential NULL pointer dereference · 459cfe0a
      Gustavo A. R. Silva authored
      commit e9a2310f upstream.
      
      There is a potential execution path in which function
      platform_get_resource() returns NULL. If this happens,
      we will end up having a NULL pointer dereference.
      
      Fix this by replacing devm_ioremap with devm_ioremap_resource,
      which has the NULL check and the memory region request.
      
      This code was detected with the help of Coccinelle.
      
      Cc: stable@vger.kernel.org
      Fixes: 97b7129c ("reset: hisilicon: change the definition of hisi_reset_init")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      459cfe0a
    • Dan Williams's avatar
      acpi, nfit: Fix ARS overflow continuation · b0a737bf
      Dan Williams authored
      commit 3fa58dca upstream.
      
      When the platform BIOS is unable to report all the media error records
      it requires the OS to restart the scrub at a prescribed location. The
      driver detects the overflow condition, but then fails to report it to
      the ARS state machine after reaping the records. Propagate -ENOSPC
      correctly to continue the ARS operation.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 1cf03c00 ("nfit: scrub and register regions in a workqueue")
      Reported-by: default avatarJacek Zloch <jacek.zloch@intel.com>
      Reviewed-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0a737bf
    • Vishal Verma's avatar
      acpi/nfit, x86/mce: Validate a MCE's address before using it · 8c547624
      Vishal Verma authored
      commit e8a308e5 upstream.
      
      The NFIT machine check handler uses the physical address from the mce
      structure, and compares it against information in the ACPI NFIT table
      to determine whether that location lies on an NVDIMM. The mce->addr
      field however may not always be valid, and this is indicated by the
      MCI_STATUS_ADDRV bit in the status field.
      
      Export mce_usable_address() which already performs validation for the
      address, and use it in the NFIT handler.
      
      Fixes: 6839a6d9 ("nfit: do an ARS scrub on hitting a latent media error")
      Reported-by: default avatarRobert Elliott <elliott@hpe.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      CC: Arnd Bergmann <arnd@arndb.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      CC: Dave Jiang <dave.jiang@intel.com>
      CC: elliott@hpe.com
      CC: "H. Peter Anvin" <hpa@zytor.com>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Len Brown <lenb@kernel.org>
      CC: linux-acpi@vger.kernel.org
      CC: linux-edac <linux-edac@vger.kernel.org>
      CC: linux-nvdimm@lists.01.org
      CC: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      CC: Ross Zwisler <zwisler@kernel.org>
      CC: stable <stable@vger.kernel.org>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Tony Luck <tony.luck@intel.com>
      CC: x86-ml <x86@kernel.org>
      CC: Yazen Ghannam <yazen.ghannam@amd.com>
      Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c547624
    • Vishal Verma's avatar
      acpi/nfit, x86/mce: Handle only uncorrectable machine checks · 9013ac4d
      Vishal Verma authored
      commit 5d96c934 upstream.
      
      The MCE handler for nfit devices is called for memory errors on a
      Non-Volatile DIMM and adds the error location to a 'badblocks' list.
      This list is used by the various NVDIMM drivers to avoid consuming known
      poison locations during IO.
      
      The MCE handler gets called for both corrected and uncorrectable errors.
      Until now, both kinds of errors have been added to the badblocks list.
      However, corrected memory errors indicate that the problem has already
      been fixed by hardware, and the resulting interrupt is merely a
      notification to Linux.
      
      As far as future accesses to that location are concerned, it is
      perfectly fine to use, and thus doesn't need to be included in the above
      badblocks list.
      
      Add a check in the nfit MCE handler to filter out corrected mce events,
      and only process uncorrectable errors.
      
      Fixes: 6839a6d9 ("nfit: do an ARS scrub on hitting a latent media error")
      Reported-by: default avatarOmar Avelar <omar.avelar@intel.com>
      Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Dan Williams <dan.j.williams@intel.com>
      CC: Dave Jiang <dave.jiang@intel.com>
      CC: elliott@hpe.com
      CC: "H. Peter Anvin" <hpa@zytor.com>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Len Brown <lenb@kernel.org>
      CC: linux-acpi@vger.kernel.org
      CC: linux-edac <linux-edac@vger.kernel.org>
      CC: linux-nvdimm@lists.01.org
      CC: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      CC: Ross Zwisler <zwisler@kernel.org>
      CC: stable <stable@vger.kernel.org>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Tony Luck <tony.luck@intel.com>
      CC: x86-ml <x86@kernel.org>
      CC: Yazen Ghannam <yazen.ghannam@amd.com>
      Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9013ac4d
    • Mikulas Patocka's avatar
      mach64: fix image corruption due to reading accelerator registers · 3690f530
      Mikulas Patocka authored
      commit c09bcc91 upstream.
      
      Reading the registers without waiting for engine idle returns
      unpredictable values. These unpredictable values result in display
      corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
      bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
      never ever clear the bit, resulting in display corruption.
      
      We don't want to wait for idle because it would degrade performance, so
      this patch modifies the driver so that it never reads accelerator
      registers.
      
      HOST_CNTL doesn't have to be read, we can just write it with
      HOST_BYTE_ALIGN because no other part of the driver cares if
      HOST_BYTE_ALIGN is set.
      
      DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
      with the default value and in atyfb_imageblit with the value set according
      to the source image data.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <syrjala@sci.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3690f530
    • Mikulas Patocka's avatar
      mach64: fix display corruption on big endian machines · 215c5598
      Mikulas Patocka authored
      commit 3c6c6a78 upstream.
      
      The code for manual bit triple is not endian-clean. It builds the variable
      "hostdword" using byte accesses, therefore we must read the variable with
      "le32_to_cpu".
      
      The patch also enables (hardware or software) bit triple only if the image
      is monochrome (image->depth). If we want to blit full-color image, we
      shouldn't use the triple code.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <syrjala@sci.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      215c5598
    • Dmitry Osipenko's avatar
      thermal: core: Fix use-after-free in thermal_cooling_device_destroy_sysfs · 2561c45b
      Dmitry Osipenko authored
      commit 3c587768 upstream.
      
      This patch fixes use-after-free that was detected by KASAN. The bug is
      triggered on a CPUFreq driver module unload by freeing 'cdev' on device
      unregister and then using the freed structure during of the cdev's sysfs
      data destruction. The solution is to unregister the sysfs at first, then
      destroy sysfs data and finally release the cooling device.
      
      Cc: <stable@vger.kernel.org> # v4.17+
      Fixes: 8ea22951 ("thermal: Add cooling device's statistics in sysfs")
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2561c45b
    • Yan, Zheng's avatar
      Revert "ceph: fix dentry leak in splice_dentry()" · e2496105
      Yan, Zheng authored
      commit efe32823 upstream.
      
      This reverts commit 8b8f53af.
      
      splice_dentry() is used by three places. For two places, req->r_dentry
      is passed to splice_dentry(). In the case of error, req->r_dentry does
      not get updated. So splice_dentry() should not drop reference.
      
      Cc: stable@vger.kernel.org # 4.18+
      Signed-off-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2496105
    • Ilya Dryomov's avatar
      libceph: bump CEPH_MSG_MAX_DATA_LEN · 542705af
      Ilya Dryomov authored
      commit 94e6992b upstream.
      
      If the read is large enough, we end up spinning in the messenger:
      
        libceph: osd0 192.168.122.1:6801 io error
        libceph: osd0 192.168.122.1:6801 io error
        libceph: osd0 192.168.122.1:6801 io error
      
      This is a receive side limit, so only reads were affected.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      542705af
    • Enric Balletbo i Serra's avatar
      clk: rockchip: Fix static checker warning in rockchip_ddrclk_get_parent call · 72872e36
      Enric Balletbo i Serra authored
      commit 665636b2 upstream.
      
      Fixes the signedness bug returning '(-22)' on the return type by removing the
      sanity checker in rockchip_ddrclk_get_parent(). The function should return
      and unsigned value only and it's safe to remove the sanity checker as the
      core functions that call get_parent like clk_core_get_parent_by_index already
      ensures the validity of the clk index returned (index >= core->num_parents).
      
      Fixes: a4f182bf ("clk: rockchip: add new clock-type for the ddrclk")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Reviewed-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72872e36
    • Ziyuan Xu's avatar
      clk: rockchip: fix wrong mmc sample phase shift for rk3328 · a3eeeed1
      Ziyuan Xu authored
      commit 82f4b67f upstream.
      
      mmc sample shift is 0 for RK3328 referring to the TRM.
      So fix them.
      
      Fixes: fe3511ad ("clk: rockchip: add clock controller for rk3328")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarZiyuan Xu <xzy.xu@rock-chips.com>
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3eeeed1
    • Icenowy Zheng's avatar
      clk: sunxi-ng: h6: fix bus clocks' divider position · 1a2502d3
      Icenowy Zheng authored
      commit 2852bfbf upstream.
      
      The bus clocks (AHB/APB) on Allwinner H6 have their second divider start
      at bit 8, according to the user manual and the BSP code. However,
      currently the divider offset is incorrectly set to 16, thus the divider
      is not correctly read and the clock frequency is not correctly calculated.
      
      Fix this bit offset on all affected bus clocks in ccu-sun50i-h6.
      
      Cc: stable@vger.kernel.org # v4.17.y
      Signed-off-by: default avatarIcenowy Zheng <icenowy@aosc.io>
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a2502d3
    • Ronald Wahl's avatar
      clk: at91: Fix division by zero in PLL recalc_rate() · 11ace021
      Ronald Wahl authored
      commit 0f5cb0e6 upstream.
      
      Commit a982e45d ("clk: at91: PLL recalc_rate() now using cached MUL
      and DIV values") removed a check that prevents a division by zero. This
      now causes a stacktrace when booting the kernel on a at91 platform if
      the PLL DIV register contains zero. This commit reintroduces this check.
      
      Fixes: a982e45d ("clk: at91: PLL recalc_rate() now using cached...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRonald Wahl <rwahl@gmx.de>
      Acked-by: default avatarLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11ace021
    • Krzysztof Kozlowski's avatar
      clk: s2mps11: Fix matching when built as module and DT node contains compatible · 3d8c2945
      Krzysztof Kozlowski authored
      commit 8985167e upstream.
      
      When driver is built as module and DT node contains clocks compatible
      (e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
      module aliases won't match.
      
      The modalias from uevent: of:NclocksT<NULL>Csamsung,s2mps11-clk
      The modalias from driver: platform:s2mps11-clk
      
      The devices are instantiated by parent's MFD.  However both Device Tree
      bindings and parent define the compatible for clocks devices.  In case
      of module matching this DT compatible will be used.
      
      The issue will not happen if this is a built-in (no need for module
      matching) or when clocks DT node does not contain compatible (not
      correct from bindings perspective but working for driver).
      
      Note when backporting to stable kernels: adjust the list of device ID
      entries.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 53c31b34 ("mfd: sec-core: Add of_compatible strings for clock MFD cells")
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d8c2945
    • Richard Weinberger's avatar
      um: Drop own definition of PTRACE_SYSEMU/_SINGLESTEP · 4a0344c5
      Richard Weinberger authored
      commit 0676b957 upstream.
      
      32bit UML used to define PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
      own its own because many years ago not all libcs had these request codes
      in their UAPI.
      These days PTRACE_SYSEMU/_SINGLESTEP is well known and part of glibc
      and our own define becomes problematic.
      
      With change c48831d0eebf ("linux/x86: sync sys/ptrace.h with Linux 4.14
      [BZ #22433]") glibc turned PTRACE_SYSEMU/_SINGLESTEP into a enum and
      UML failed to build.
      
      Let's drop our define and rely on the fact that every libc has
      PTRACE_SYSEMU/_SINGLESTEP.
      
      Cc: <stable@vger.kernel.org>
      Cc: Ritesh Raj Sarraf <rrs@researchut.com>
      Reported-and-tested-by: default avatarRitesh Raj Sarraf <rrs@researchut.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a0344c5
    • Max Filippov's avatar
      xtensa: fix boot parameters address translation · 3ad5f233
      Max Filippov authored
      commit 40dc948f upstream.
      
      The bootloader may pass physical address of the boot parameters structure
      to the MMUv3 kernel in the register a2. Code in the _SetupMMU block in
      the arch/xtensa/kernel/head.S is supposed to map that physical address to
      the virtual address in the configured virtual memory layout.
      
      This code haven't been updated when additional 256+256 and 512+512
      memory layouts were introduced and it may produce wrong addresses when
      used with these layouts.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ad5f233
    • Max Filippov's avatar
      xtensa: make sure bFLT stack is 16 byte aligned · 591dd5df
      Max Filippov authored
      commit 0773495b upstream.
      
      Xtensa ABI requires stack alignment to be at least 16. In noMMU
      configuration ARCH_SLAB_MINALIGN is used to align stack. Make it at
      least 16.
      
      This fixes the following runtime error in noMMU configuration, caused by
      interaction between insufficiently aligned stack and alloca function,
      that results in corruption of on-stack variable in the libc function
      glob:
      
       Caught unhandled exception in 'sh' (pid = 47, pc = 0x02d05d65)
        - should not happen
        EXCCAUSE is 15
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      591dd5df
    • Max Filippov's avatar
      xtensa: add NOTES section to the linker script · 47af963b
      Max Filippov authored
      commit 4119ba21 upstream.
      
      This section collects all source .note.* sections together in the
      vmlinux image. Without it .note.Linux section may be placed at address
      0, while the rest of the kernel is at its normal address, resulting in a
      huge vmlinux.bin image that may not be linked into the xtensa Image.elf.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47af963b
    • Huacai Chen's avatar
      MIPS: Loongson-3: Fix BRIDGE irq delivery problem · 5d55ba0f
      Huacai Chen authored
      [ Upstream commit 360fe725 ]
      
      After commit e509bd7d ("genirq: Allow migration of chained
      interrupts by installing default action") Loongson-3 fails at here:
      
      setup_irq(LOONGSON_HT1_IRQ, &cascade_irqaction);
      
      This is because both chained_action and cascade_irqaction don't have
      IRQF_SHARED flag. This will cause Loongson-3 resume fails because HPET
      timer interrupt can't be delivered during S3. So we set the irqchip of
      the chained irq to loongson_irq_chip which doesn't disable the chained
      irq in CP0.Status.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20434/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: Huacai Chen <chenhuacai@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5d55ba0f
    • Huacai Chen's avatar
      MIPS: Loongson-3: Fix CPU UART irq delivery problem · 0a825f0b
      Huacai Chen authored
      [ Upstream commit d06f8a2f ]
      
      Masking/unmasking the CPU UART irq in CP0_Status (and redirecting it to
      other CPUs) may cause interrupts be lost, especially in multi-package
      machines (Package-0's UART irq cannot be delivered to others). So make
      mask_loongson_irq() and unmask_loongson_irq() be no-ops.
      
      The original problem (UART IRQ may deliver to any core) is also because
      of masking/unmasking the CPU UART irq in CP0_Status. So it is safe to
      remove all of the stuff.
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20433/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: Huacai Chen <chenhuacai@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a825f0b
    • Minchan Kim's avatar
      zram: close udev startup race condition as default groups · 9e07f4e2
      Minchan Kim authored
      commit fef912bf upstream.
      commit 98af4d4d upstream.
      
      I got a report from Howard Chen that he saw zram and sysfs race(ie,
      zram block device file is created but sysfs for it isn't yet)
      when he tried to create new zram devices via hotadd knob.
      
      v4.20 kernel fixes it by [1, 2] but it's too large size to merge
      into -stable so this patch fixes the problem by registering defualt
      group by Greg KH's approach[3].
      
      This patch should be applied to every stable tree [3.16+] currently
      existing from kernel.org because the problem was introduced at 2.6.37
      by [4].
      
      [1] fef912bf, block: genhd: add 'groups' argument to device_add_disk
      [2] 98af4d4d, zram: register default groups with device_add_disk()
      [3] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
      [4] 33863c21, Staging: zram: Replace ioctls with sysfs interface
      
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Hannes Reinecke <hare@suse.com>
      Tested-by: default avatarHoward Chen <howardsoc@google.com>
      Signed-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9e07f4e2
    • Jerome Brunet's avatar
      clk: meson: axg: mark fdiv2 and fdiv3 as critical · 52cad794
      Jerome Brunet authored
      [ Upstream commit d6ee1e7e ]
      
      Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor
      uses the fdiv2 and fdiv3 to, among other things, provide the cpu
      clock.
      
      Until clock hand-off mechanism makes its way to CCF and the generic
      SCPI claims platform specific clocks, these clocks must be marked as
      critical to make sure they are never disabled when needed by the
      co-processor.
      
      Fixes: 05f81440 ("clk: meson: add fdiv clock gates")
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Acked-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      52cad794
    • Christian Hewitt's avatar
      clk: meson-gxbb: set fclk_div3 as CLK_IS_CRITICAL · a98af723
      Christian Hewitt authored
      [ Upstream commit e2576c8b ]
      
      On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
      with reboot; e.g. a ~60 second delay between issuing reboot and the
      board power cycling (and in some OS configurations reboot will fail
      and require manual power cycling).
      
      Similar to 'commit c987ac6f ("clk:
      meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4
      Co-Processor seems to depend on FCLK_DIV3 being operational.
      
      Until commit 05f81440 ("clk:
      meson: add fdiv clock gates"), this clock was modeled and left on by
      the bootloader.
      
      We don't have precise documentation about the SCPI Co-Processor and
      its clock requirement so we are learning things the hard way.
      
      Marking this clock as critical solves the problem but it should not
      be viewed as final solution. Ideally, the SCPI driver should claim
      these clocks. We also depends on some clock hand-off mechanism
      making its way to CCF, to make sure the clock stays on between its
      registration and the SCPI driver probe.
      
      Fixes: 05f81440 ("clk: meson: add fdiv clock gates")
      Signed-off-by: default avatarChristian Hewitt <christianshewitt@gmail.com>
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a98af723
    • Aaro Koskinen's avatar
      arm64: dts: stratix10: fix multicast filtering · 347d8803
      Aaro Koskinen authored
      commit fd5ba6ee upstream
      
      On Stratix 10, the EMAC has 256 hash buckets for multicast filtering. This
      needs to be specified in DTS, otherwise the stmmac driver defaults to 64
      buckets and initializes the filter incorrectly. As a result, e.g. valid
      IPv6 multicast traffic ends up being dropped.
      
      Fixes: 78cd6a9d ("arm64: dts: Add base stratix 10 dtsi")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDinh Nguyen <dinguyen@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      347d8803
    • Thor Thayer's avatar
      arm64: dts: stratix10: Support Ethernet Jumbo frame · 8f49fe42
      Thor Thayer authored
      commit a27460c9 upstream
      
      Properly specify the RX and TX FIFO size which is important
      for Jumbo frames.
      Update the max-frame-size to support Jumbo frames.
      Signed-off-by: default avatarThor Thayer <thor.thayer@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8f49fe42
    • Johan Hovold's avatar
      drm/msm: fix OF child-node lookup · 08261cad
      Johan Hovold authored
      commit f9a70823 upstream.
      
      Use the new of_get_compatible_child() helper to lookup the legacy
      pwrlevels child node instead of using of_find_compatible_node(), which
      searches the entire tree from a given start node and thus can return an
      unrelated (i.e.  non-child) node.
      
      This also addresses a potential use-after-free (e.g. after probe
      deferral) as the tree-wide helper drops a reference to its first
      argument (i.e. the probed device's node).
      
      While at it, also fix the related child-node reference leak.
      
      Fixes: e2af8b6b ("drm/msm: gpu: Use OPP tables if we can")
      Cc: stable <stable@vger.kernel.org>     # 4.12
      Cc: Jordan Crouse <jcrouse@codeaurora.org>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: David Airlie <airlied@linux.ie>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08261cad