Currently mm_iommu_do_alloc() is called in 2 cases:
- VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory:
	this locks &mem_list_mutex and then locks mm::mmap_sem
	several times when adjusting locked_vm or pinning pages;
- vfio_pci_nvgpu_regops::mmap() for GPU memory:
	this is called with mm::mmap_sem held already and it locks
	&mem_list_mutex.

So one can craft a userspace program to do special ioctl and mmap in
2 threads concurrently and cause a deadlock which lockdep warns about
(below).

We did not hit this yet because QEMU constructs the machine in a single
thread.

This moves the overlap check next to where the new entry is added and
reduces the amount of time spent with &mem_list_mutex held.

This moves locked_vm adjustment from under &mem_list_mutex.

This relies on mm_iommu_adjust_locked_vm() doing nothing when entries==0.

This is one of the lockdep warnings:

======================================================
WARNING: possible circular locking dependency detected
5.1.0-rc2-le_nv2_aikATfstn1-p1 #363 Not tainted
------------------------------------------------------
qemu-system-ppc/8038 is trying to acquire lock:
000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490

but task is already holding lock:
00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&mm->mmap_sem){++++}:
       lock_acquire+0xf8/0x260
       down_write+0x44/0xa0
       mm_iommu_adjust_locked_vm.part.1+0x4c/0x190
       mm_iommu_do_alloc+0x310/0x490
       tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce]
       vfio_fops_unl_ioctl+0x94/0x430 [vfio]
       do_vfs_ioctl+0xe4/0x930
       ksys_ioctl+0xc4/0x110
       sys_ioctl+0x28/0x80
       system_call+0x5c/0x70

-> #0 (mem_list_mutex){+.+.}:
       __lock_acquire+0x1484/0x1900
       lock_acquire+0xf8/0x260
       __mutex_lock+0x88/0xa70
       mm_iommu_do_alloc+0x70/0x490
       vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci]
       vfio_pci_mmap+0x198/0x2a0 [vfio_pci]
       vfio_device_fops_mmap+0x44/0x70 [vfio]
       mmap_region+0x5d4/0x770
       do_mmap+0x42c/0x650
       vm_mmap_pgoff+0x124/0x160
       ksys_mmap_pgoff+0xdc/0x2f0
       sys_mmap+0x40/0x80
       system_call+0x5c/0x70

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&mm->mmap_sem);
                               lock(mem_list_mutex);
                               lock(&mm->mmap_sem);
  lock(mem_list_mutex);

 *** DEADLOCK ***

1 lock held by qemu-system-ppc/8038:
 #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160

Fixes: c10c21ef ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19)
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Joel reported weird crashes using skiroot_defconfig, in his case we
jumped into an NX page:

  kernel tried to execute exec-protected page (c000000002bff4f0) - exploit attempt? (uid: 0)
  BUG: Unable to handle kernel instruction fetch
  Faulting instruction address: 0xc000000002bff4f0

Looking at the disassembly, we had simply branched to that address:

  c000000000c001bc  49fff335    bl     c000000002bff4f0

But that didn't match the original kernel image:

  c000000000c001bc  4bfff335    bl     c000000000bff4f0 <kobject_get+0x8>

When STRICT_KERNEL_RWX is enabled, and we're using the radix MMU, we
call radix__change_memory_range() late in boot to change page
protections. We do that both to mark rodata read only and also to mark
init text no-execute. That involves walking the kernel page tables,
and clearing _PAGE_WRITE or _PAGE_EXEC respectively.

With radix we may use hugepages for the linear mapping, so the code in
radix__change_memory_range() uses eg. pmd_huge() to test if it has
found a huge mapping, and if so it stops the page table walk and
changes the PMD permissions.

However if the kernel is built without HUGETLBFS support, pmd_huge()
is just a #define that always returns 0. That causes the code in
radix__change_memory_range() to incorrectly interpret the PMD value as
a pointer to a PTE page rather than as a PTE at the PMD level.

We can see this using `dv` in xmon which also uses pmd_huge():

  0:mon> dv c000000000000000
  pgd  @ 0xc000000001740000
  pgdp @ 0xc000000001740000 = 0x80000000ffffb009
  pudp @ 0xc0000000ffffb000 = 0x80000000ffffa009
  pmdp @ 0xc0000000ffffa000 = 0xc00000000000018f   <- this is a PTE
  ptep @ 0xc000000000000100 = 0xa64bb17da64ab07d   <- kernel text

The end result is we treat the value at 0xc000000000000100 as a PTE
and clear _PAGE_WRITE or _PAGE_EXEC, potentially corrupting the code
at that address.

In Joel's specific case we cleared the sign bit in the offset of the
branch, causing a backward branch to turn into a forward branch which
caused us to branch into a non-executable page. However the exact
nature of the crash depends on kernel version, compiler version, and
other factors.

We need to fix radix__change_memory_range() to not use accessors that
depend on HUGETLBFS, but we also have radix memory hotplug code that
uses pmd_huge() etc that will also need fixing. So for now just
disallow the broken combination of Radix with HUGETLBFS disabled.

The only defconfig we have that is affected is skiroot_defconfig, so
turn on HUGETLBFS there so that it still gets Radix.

Fixes: 566ca99a ("powerpc/mm/radix: Add dummy radix_enabled()")
Cc: stable@vger.kernel.org # v4.7+
Reported-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

The recent commit 8bc08689 ("powerpc/mm: Only define
MAX_PHYSMEM_BITS in SPARSEMEM configurations") removed our definition
of MAX_PHYSMEM_BITS when SPARSEMEM is disabled.

This inadvertently broke some 64-bit FLATMEM using configs with eg:

  arch/powerpc/include/asm/book3s/64/mmu-hash.h:584:6: error: "MAX_PHYSMEM_BITS" is not defined, evaluates to 0
   #if (MAX_PHYSMEM_BITS > MAX_EA_BITS_PER_CONTEXT)
        ^~~~~~~~~~~~~~~~

Fix it by making sure we define MAX_PHYSMEM_BITS for all 64-bit
configs regardless of SPARSEMEM.

Fixes: 8bc08689 ("powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations")
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Reported-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Commit 48e7b769 ("powerpc/64s/hash: Convert SLB miss handlers to C")
broke the radix-mode segment exception handler. In radix mode, this is
exception is not an SLB miss, rather it signals that the EA is outside
the range translated by any page table.

The commit lost the radix feature alternate code patch, which can
cause faults to some EAs to kernel BUG at arch/powerpc/mm/slb.c:639!

The original radix code would send faults to slb_miss_large_addr,
which would end up faulting due to slb_addr_limit being 0. This patch
sends radix directly to do_bad_slb_fault, which is a bit clearer.

Fixes: 48e7b769 ("powerpc/64s/hash: Convert SLB miss handlers to C")
Cc: stable@vger.kernel.org # v4.20+
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Commit b5b4453e ("powerpc/vdso64: Fix CLOCK_MONOTONIC
inconsistencies across Y2038") changed the type of wtom_clock_sec
to s64 on PPC64. Therefore, VDSO32 needs to read it with a 4 bytes
shift in order to retrieve the lower part of it.

Fixes: b5b4453e ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Commit 0df977ea ("powerpc/6xx: Don't use SPRN_SPRG2 for storing
stack pointer while in RTAS") changes the code to use a field in
thread struct to store the stack pointer while in RTAS instead of
using SPRN_SPRG2. It therefore converts all places which were
manipulating SPRN_SPRG2 to use that field. During early startup, the
zeroing of SPRN_SPRG2 has been replaced by a zeroing of that field in
thread struct. But at least in start_here, that's done wrongly because
it used the physical address of the fields while MMU is on at that
time.

So the virtual address of the field should be used instead, but in
the meantime, thread struct has already been zeroed and initialised
so we can just drop this initialisation.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Fixes: 0df977ea ("powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while in RTAS")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

On pseries, TLB multihit are reported as D-Cache Multihit. This is because
the wrongly populated mc_err_types[] array. Per PAPR, TLB error type is 0x04
and mc_err_types[4] points to "D-Cache" instead of "TLB" string. Fixup the
mc_err_types[] array.

Machine check error type per PAPR:
  0x00 = Uncorrectable Memory Error (UE)
  0x01 = SLB error
  0x02 = ERAT Error
  0x04 = TLB error
  0x05 = D-Cache error
  0x07 = I-Cache error

Fixes: 8f0b8056 ("powerpc/pseries: Display machine check error details.")
Cc: stable@vger.kernel.org # v4.20+
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
we currently use of_read_property() to obtain the pointer to the array
corresponding to the property "ibm,drc-indexes". The elements of this
array are of type __be32, but are accessed without any conversion to
the OS-endianness, which is buggy on a Little Endian OS.

Fix this by using of_property_read_u32_index() accessor function to
safely read the elements of the array.

Fixes: e83636ac ("pseries/drc-info: Search DRC properties for CPU indexes")
Cc: stable@vger.kernel.org # v4.16+
Reported-by: Pavithra R. Prakash <pavrampu@in.ibm.com>
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
[mpe: Make the WARN_ON a WARN_ON_ONCE so it's not retriggerable]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Chandan reported that fstests' generic/026 test hit a crash:

  BUG: Unable to handle kernel data access at 0xc00000062ac40000
  Faulting instruction address: 0xc000000000092240
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries
  CPU: 0 PID: 27828 Comm: chacl Not tainted 5.0.0-rc2-next-20190115-00001-g6de6dba64dda #1
  NIP:  c000000000092240 LR: c00000000066a55c CTR: 0000000000000000
  REGS: c00000062c0c3430 TRAP: 0300   Not tainted  (5.0.0-rc2-next-20190115-00001-g6de6dba64dda)
  MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 44000842  XER: 20000000
  CFAR: 00007fff7f3108ac DAR: c00000062ac40000 DSISR: 40000000 IRQMASK: 0
  GPR00: 0000000000000000 c00000062c0c36c0 c0000000017f4c00 c00000000121a660
  GPR04: c00000062ac3fff9 0000000000000004 0000000000000020 00000000275b19c4
  GPR08: 000000000000000c 46494c4500000000 5347495f41434c5f c0000000026073a0
  GPR12: 0000000000000000 c0000000027a0000 0000000000000000 0000000000000000
  GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  GPR20: c00000062ea70020 c00000062c0c38d0 0000000000000002 0000000000000002
  GPR24: c00000062ac3ffe8 00000000275b19c4 0000000000000001 c00000062ac30000
  GPR28: c00000062c0c38d0 c00000062ac30050 c00000062ac30058 0000000000000000
  NIP memcmp+0x120/0x690
  LR  xfs_attr3_leaf_lookup_int+0x53c/0x5b0
  Call Trace:
    xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable)
    xfs_da3_node_lookup_int+0x32c/0x5a0
    xfs_attr_node_addname+0x170/0x6b0
    xfs_attr_set+0x2ac/0x340
    __xfs_set_acl+0xf0/0x230
    xfs_set_acl+0xd0/0x160
    set_posix_acl+0xc0/0x130
    posix_acl_xattr_set+0x68/0x110
    __vfs_setxattr+0xa4/0x110
    __vfs_setxattr_noperm+0xac/0x240
    vfs_setxattr+0x128/0x130
    setxattr+0x248/0x600
    path_setxattr+0x108/0x120
    sys_setxattr+0x28/0x40
    system_call+0x5c/0x70
  Instruction dump:
  7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 2c050000
  4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 7d4a3436 7c295040

The instruction dump decodes as:
  subfic  r6,r5,8
  rlwinm  r6,r6,3,0,28
  ldbrx   r9,0,r3
  ldbrx   r10,0,r4      <-

Which shows us doing an 8 byte load from c00000062ac3fff9, which
crosses the page boundary at c00000062ac40000 and faults.

It's not OK for memcmp to read past the end of the source or
destination buffers if that would cross a page boundary, because we
don't know that the next page is mapped.

As pointed out by Segher, we can read past the end of the source or
destination as long as we don't cross a 4K boundary, because that's
our minimum page size on all platforms.

The bug is in the code at the .Lcmp_rest_lt8bytes label. When we get
there we know that s1 is 8-byte aligned and we have at least 1 byte to
read, so a single 8-byte load won't read past the end of s1 and cross
a page boundary.

But we have to be more careful with s2. So check if it's within 8
bytes of a 4K boundary and if so go to the byte-by-byte loop.

Fixes: 2d9ee327 ("powerpc/64: Align bytes before fall back to .Lshort in powerpc64 memcmp()")
Cc: stable@vger.kernel.org # v4.19+
Reported-by: Chandan Rajendra <chandan@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Tested-by: Chandan Rajendra <chandan@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Pull ext4 fixes from Ted Ts'o:
 "Miscellaneous ext4 bug fixes for 5.1"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: prohibit fstrim in norecovery mode
  ext4: cleanup bh release code in ext4_ind_remove_space()
  ext4: brelse all indirect buffer in ext4_ind_remove_space()
  ext4: report real fs size after failed resize
  ext4: add missing brelse() in add_new_gdb_meta_bg()
  ext4: remove useless ext4_pin_inode()
  ext4: avoid panic during forced reboot
  ext4: fix data corruption caused by unaligned direct AIO
  ext4: fix NULL pointer dereference while journal is aborted

Pull scheduler updates from Thomas Gleixner:
 "Third more careful attempt for this set of fixes:

   - Prevent a 32bit math overflow in the cpufreq code

   - Fix a buffer overflow when scanning the cgroup2 cpu.max property

   - A set of fixes for the NOHZ scheduler logic to prevent waking up
     CPUs even if the capacity of the busy CPUs is sufficient along with
     other tweaks optimizing the behaviour for asymmetric systems
     (big/little)"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/fair: Skip LLC NOHZ logic for asymmetric systems
  sched/fair: Tune down misfit NOHZ kicks
  sched/fair: Comment some nohz_balancer_kick() kick conditions
  sched/core: Fix buffer overflow in cgroup2 property cpu.max
  sched/cpufreq: Fix 32-bit math overflow

Pull perf updates from Thomas Gleixner:
 "A larger set of perf updates.

  Not all of them are strictly fixes, but that's solely the tip
  maintainers fault as they let the timely -rc1 pull request fall
  through the cracks for various reasons including travel. So I'm
  sending this nevertheless because rebasing and distangling fixes and
  updates would be a mess and risky as well. As of tomorrow, a strict
  fixes separation is happening again. Sorry for the slip-up.

  Kernel:

   - Handle RECORD_MMAP vs. RECORD_MMAP2 correctly so different
     consumers of the mmap event get what they requested.

  Tools:

   - A larger set of updates to perf record/report/scripts vs. time
     stamp handling

   - More Python3 fixups

   - A pile of memory leak plumbing

   - perf BPF improvements and fixes

   - Finalize the perf.data directory storage"

[ Note: the kernel part is strictly a fix, the updates are purely to
  tooling       - Linus ]

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (75 commits)
  perf bpf: Show more BPF program info in print_bpf_prog_info()
  perf bpf: Extract logic to create program names from perf_event__synthesize_one_bpf_prog()
  perf tools: Save bpf_prog_info and BTF of new BPF programs
  perf evlist: Introduce side band thread
  perf annotate: Enable annotation of BPF programs
  perf build: Check what binutils's 'disassembler()' signature to use
  perf bpf: Process PERF_BPF_EVENT_PROG_LOAD for annotation
  perf symbols: Introduce DSO_BINARY_TYPE__BPF_PROG_INFO
  perf feature detection: Add -lopcodes to feature-libbfd
  perf top: Add option --no-bpf-event
  perf bpf: Save BTF information as headers to perf.data
  perf bpf: Save BTF in a rbtree in perf_env
  perf bpf: Save bpf_prog_info information as headers to perf.data
  perf bpf: Save bpf_prog_info in a rbtree in perf_env
  perf bpf: Make synthesize_bpf_events() receive perf_session pointer instead of perf_tool
  perf bpf: Synthesize bpf events with bpf_program__get_prog_info_linear()
  bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump()
  tools lib bpf: Introduce bpf_program__get_prog_info_linear()
  perf record: Replace option --bpf-event with --no-bpf-event
  perf tests: Fix a memory leak in test__perf_evsel__tp_sched_test()
  ...

Pull x86 fixes from Thomas Gleixner:
 "A set of x86 fixes:

   - Prevent potential NULL pointer dereferences in the HPET and HyperV
     code

   - Exclude the GART aperture from /proc/kcore to prevent kernel
     crashes on access

   - Use the correct macros for Cyrix I/O on Geode processors

   - Remove yet another kernel address printk leak

   - Announce microcode reload completion as requested by quite some
     people. Microcode loading has become popular recently.

   - Some 'Make Clang' happy fixlets

   - A few cleanups for recently added code"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/gart: Exclude GART aperture from kcore
  x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error
  x86/mm/pti: Make local symbols static
  x86/cpu/cyrix: Remove {get,set}Cx86_old macros used for Cyrix processors
  x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors
  x86/microcode: Announce reload operation's completion
  x86/hyperv: Prevent potential NULL pointer dereference
  x86/hpet: Prevent potential NULL pointer dereference
  x86/lib: Fix indentation issue, remove extra tab
  x86/boot: Restrict header scope to make Clang happy
  x86/mm: Don't leak kernel addresses
  x86/cpufeature: Fix various quality problems in the <asm/cpu_device_hd.h> header

Pull timer fixes from Thomas Gleixner:
 "A set of small fixes plus the removal of stale board support code:

   - Remove the board support code from the clpx711x clocksource driver.
     This change had fallen through the cracks and I'm sending it now
     rather than dealing with people who want to improve that stale code
     for 3 month.

   - Use the proper clocksource mask on RICSV

   - Make local scope functions and variables static"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clocksource/drivers/clps711x: Remove board support
  clocksource/drivers/riscv: Fix clocksource mask
  clocksource/drivers/mips-gic-timer: Make gic_compare_irqaction static
  clocksource/drivers/timer-ti-dm: Make omap_dm_timer_set_load_start() static
  clocksource/drivers/tcb_clksrc: Make tc_clksrc_suspend/resume() static
  clocksource/drivers/clps711x: Make clps711x_clksrc_init() static
  time/jiffies: Make refined_jiffies static

Pull locking fixes from Thomas Gleixner:
 "Two small fixes:

   - Cure a recently introduces error path hickup which tries to
     unregister a not registered lockdep key in te workqueue code

   - Prevent unaligned cmpxchg() crashes in the robust list handling
     code by sanity checking the user space supplied futex pointer"

* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  futex: Ensure that futex address is aligned in handle_futex_death()
  workqueue: Only unregister a registered lockdep key

Pull irq fixes from Thomas Gleixner:
 "A set of fixes for the interrupt subsystem:

   - Remove secondary GIC support on systems w/o device-tree support

   - A set of small fixlets in various irqchip drivers

   - static and fall-through annotations

   - Kernel doc and typo fixes"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq: Mark expected switch case fall-through
  genirq/devres: Remove excess parameter from kernel doc
  irqchip/irq-mvebu-sei: Make mvebu_sei_ap806_caps static
  irqchip/mbigen: Don't clear eventid when freeing an MSI
  irqchip/stm32: Don't set rising configuration registers at init
  irqchip/stm32: Don't clear rising/falling config registers at init
  dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support
  irqchip/mmp: Make mmp_irq_domain_ops static
  irqchip/brcmstb-l2: Make two init functions static
  genirq: Fix typo in comment of IRQD_MOVE_PCNTXT
  irqchip/gic-v3-its: Fix comparison logic in lpi_range_cmp
  irqchip/gic: Drop support for secondary GIC in non-DT systems
  irqchip/imx-irqsteer: Fix of_property_read_u32() error handling

Pull core fixes from Thomas Gleixner:
 "Two small fixes:

   - Move the large objtool_file struct off the stack so objtool works
     in setups with a tight stack limit.

   - Make a few variables static in the watchdog core code"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  watchdog/core: Make variables static
  objtool: Move objtool_file struct off the stack

Pull thermal management fixes from Zhang Rui:

 - Fix a wrong __percpu structure declaration in intel_powerclamp driver
   (Luc Van Oostenryck)

 - Fix truncated name of the idle injection kthreads created by
   intel_powerclamp driver (Zhang Rui)

 - Fix the missing UUID supports in int3400 thermal driver (Matthew
   Garrett)

 - Fix a crash when accessing the debugfs of bcm2835 SoC thermal driver
   (Phil Elwell)

 - A couple of trivial fixes/cleanups in some SoC thermal drivers

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
  thermal/intel_powerclamp: fix truncated kthread name
  thermal: mtk: Allocate enough space for mtk_thermal.
  thermal/int340x_thermal: fix mode setting
  thermal/int340x_thermal: Add additional UUIDs
  thermal: cpu_cooling: Remove unused cur_freq variable
  thermal: bcm2835: Fix crash in bcm2835_thermal_debugfs
  thermal: samsung: Fix incorrect check after code merge
  thermal/intel_powerclamp: fix __percpu declaration of worker_data

Pull smb3 fixes from Steve French:

 - two fixes for stable for guest mount problems with smb3.1.1

 - two fixes for crediting (SMB3 flow control) on resent requests

 - a byte range lock leak fix

 - two fixes for incorrect rc mappings

* tag '5.1-rc1-cifs-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: update internal module version number
  SMB3: Fix SMB3.1.1 guest mounts to Samba
  cifs: Fix slab-out-of-bounds when tracing SMB tcon
  cifs: allow guest mounts to work for smb3.11
  fix incorrect error code mapping for OBJECTID_NOT_FOUND
  cifs: fix that return -EINVAL when do dedupe operation
  CIFS: Fix an issue with re-sending rdata when transport returning -EAGAIN
  CIFS: Fix an issue with re-sending wdata when transport returning -EAGAIN

Pull auxdisplay updates from Miguel Ojeda:
 "A few fixes and improvements for auxdisplay:

   - Series to fix a memory leak in hd44780 while introducing
     charlcd_free(). From Andy Shevchenko

   - Series to clean up the Kconfig menus and a couple of improvements
     for charlcd. From Mans Rullgard"

* tag 'auxdisplay-for-linus-v5.1-rc2' of git://github.com/ojeda/linux:
  auxdisplay: charlcd: make backlight initial state configurable
  auxdisplay: charlcd: simplify init message display
  auxdisplay: deconfuse configuration
  auxdisplay: hd44780: Convert to use charlcd_free()
  auxdisplay: panel: Convert to use charlcd_free()
  auxdisplay: charlcd: Introduce charlcd_free() helper
  auxdisplay: charlcd: Move to_priv() to charlcd namespace
  auxdisplay: hd44780: Fix memory leak on ->remove()

Pull SCSI fixes from James Bottomley:
 "Six fixes to four drivers and two core fixes.

  One core fix simply corrects a missed destroy_rcu_head() but the other
  is hopefully the end of an ongoing effort to make suspend/resume play
  nicely with scsi quiesce"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: ibmvscsi: Fix empty event pool access during host removal
  scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton
  scsi: hisi_sas: Add softreset in hisi_sas_I_T_nexus_reset()
  scsi: qla2xxx: Fix NULL pointer crash due to stale CPUID
  scsi: qla2xxx: Fix FC-AL connection target discovery
  scsi: core: Avoid that a kernel warning appears during system resume
  scsi: core: Also call destroy_rcu_head() for passthrough requests
  scsi: iscsi: flush running unbind operations when removing a session

Since board support for the CLPS711X platform was removed,
remove the board support from the clps711x-timer driver.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lkml.kernel.org/r/20181220111626.17140-1-shc_work@mail.ru

Pull io_uring fixes and improvements from Jens Axboe:
 "The first five in this series are heavily inspired by the work Al did
  on the aio side to fix the races there.

  The last two re-introduce a feature that was in io_uring before it got
  merged, but which I pulled since we didn't have a good way to have
  BVEC iters that already have a stable reference. These aren't
  necessarily related to block, it's just how io_uring pins fixed
  buffers"

* tag 'io_uring-20190323' of git://git.kernel.dk/linux-block:
  block: add BIO_NO_PAGE_REF flag
  iov_iter: add ITER_BVEC_FLAG_NO_REF flag
  io_uring: mark me as the maintainer
  io_uring: retry bulk slab allocs as single allocs
  io_uring: fix poll races
  io_uring: fix fget/fput handling
  io_uring: add prepped flag
  io_uring: make io_read/write return an integer
  io_uring: use regular request ref counts

Pull block fixes from Jens Axboe:
 "A set of fixes/changes that should go into this series. This contains:

   - Kernel doc / comment updates (Bart, Shenghui)

   - Un-export of core-only used function (Bart)

   - Fix race on loop file access (Dongli)

   - pf/pcd queue cleanup fixes (me)

   - Use appropriate helper for RESTART bit set (Yufen)

   - Use named identifier for classic poll (Yufen)"

* tag 'for-linus-20190323' of git://git.kernel.dk/linux-block:
  sbitmap: trivial - update comment for sbitmap_deferred_clear_bit
  blkcg: Fix kernel-doc warnings
  blk-iolatency: #include "blk.h"
  block: Unexport blk_mq_add_to_requeue_list()
  block: add BLK_MQ_POLL_CLASSIC for hybrid poll and return EINVAL for unexpected value
  blk-mq: remove unused 'nr_expired' from blk_mq_hw_ctx
  loop: access lo_backing_file only when the loop device is Lo_bound
  blk-mq: use blk_mq_sched_mark_restart_hctx to set RESTART
  paride/pcd: cleanup queues when detection fails
  paride/pf: cleanup queues when detection fails

Pull ceph fixes from Ilya Dryomov:
 "A follow up for the new alloc_size logic and a blacklisting fix,
  marked for stable"

* tag 'ceph-for-5.1-rc2' of git://github.com/ceph/ceph-client:
  rbd: drop wait_for_latest_osdmap()
  libceph: wait for latest osdmap in ceph_monc_blacklist_add()
  rbd: set io_min, io_opt and discard_granularity to alloc_size

The ext4 fstrim implementation uses the block bitmaps to find free space
that can be discarded.  If we haven't replayed the journal, the bitmaps
will be stale and we absolutely *cannot* use stale metadata to zap the
underlying storage.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>

Currently, we are releasing the indirect buffer where we are done with
it in ext4_ind_remove_space(), so we can see the brelse() and
BUFFER_TRACE() everywhere.  It seems fragile and hard to read, and we
may probably forget to release the buffer some day.  This patch cleans
up the code by putting of the code which releases the buffers to the
end of the function.
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>

All indirect buffers get by ext4_find_shared() should be released no
mater the branch should be freed or not. But now, we forget to release
the lower depth indirect buffers when removing space from the same
higher depth indirect block. It will lead to buffer leak and futher
more, it may lead to quota information corruption when using old quota,
consider the following case.

 - Create and mount an empty ext4 filesystem without extent and quota
   features,
 - quotacheck and enable the user & group quota,
 - Create some files and write some data to them, and then punch hole
   to some files of them, it may trigger the buffer leak problem
   mentioned above.
 - Disable quota and run quotacheck again, it will create two new
   aquota files and write the checked quota information to them, which
   probably may reuse the freed indirect block(the buffer and page
   cache was not freed) as data block.
 - Enable quota again, it will invoke
   vfs_load_quota_inode()->invalidate_bdev() to try to clean unused
   buffers and pagecache. Unfortunately, because of the buffer of quota
   data block is still referenced, quota code cannot read the up to date
   quota info from the device and lead to quota information corruption.

This problem can be reproduced by xfstests generic/231 on ext3 file
system or ext4 file system without extent and quota features.

This patch fix this problem by releasing the missing indirect buffers,
in ext4_ind_remove_space().
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: stable@kernel.org

In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.

With -Wimplicit-fallthrough added to CFLAGS:

 kernel/irq/manage.c: In function ‘irq_do_set_affinity’:
 kernel/irq/manage.c:198:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
   cpumask_copy(desc->irq_common_data.affinity, mask);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 kernel/irq/manage.c:199:2: note: here
   case IRQ_SET_MASK_OK_NOCOPY:
   ^~~~

Annotate it.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/20190228213714.GA9246@embeddedor

For all riscv architectures (RV32, RV64 and RV128), the clocksource
is a 64 bit incrementing counter.

Fix the clock source mask accordingly.

Tested on both 64bit and 32 bit virt machine in QEMU.

Fixes: 62b01943 ("clocksource: new RISC-V SBI timer driver")
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-riscv@lists.infradead.org
Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Anup Patel <Anup.Patel@wdc.com>
Cc: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190322215411.19362-1-atish.patra@wdc.com

On machines where the GART aperture is mapped over physical RAM,
/proc/kcore contains the GART aperture range. Accessing the GART range via
/proc/kcore results in a kernel crash.

vmcore used to have the same issue, until it was fixed with commit
2a3e83c6 ("x86/gart: Exclude GART aperture from vmcore")', leveraging
existing hook infrastructure in vmcore to let /proc/vmcore return zeroes
when attempting to read the aperture region, and so it won't read from the
actual memory.

Apply the same workaround for kcore. First implement the same hook
infrastructure for kcore, then reuse the hook functions introduced in the
previous vmcore fix. Just with some minor adjustment, rename some functions
for more general usage, and simplify the hook infrastructure a bit as there
is no module usage yet.
Suggested-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jiri Bohac <jbohac@suse.cz>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Omar Sandoval <osandov@fb.com>
Cc: Dave Young <dyoung@redhat.com>
Link: https://lkml.kernel.org/r/20190308030508.13548-1-kasong@redhat.com

To 2.19
Signed-off-by: Steve French <stfrench@microsoft.com>

Workaround problem with Samba responses to SMB3.1.1
null user (guest) mounts.  The server doesn't set the
expected flag in the session setup response so we have
to do a similar check to what is done in smb3_validate_negotiate
where we also check if the user is a null user (but not sec=krb5
since username might not be passed in on mount for Kerberos case).

Note that the commit below tightened the conditions and forced signing
for the SMB2-TreeConnect commands as per MS-SMB2.
However, this should only apply to normal user sessions and not for
cases where there is no user (even if server forgets to set the flag
in the response) since we don't have anything useful to sign with.
This is especially important now that the more secure SMB3.1.1 protocol
is in the default dialect list.

An earlier patch ("cifs: allow guest mounts to work for smb3.11") fixed
the guest mounts to Windows.

    Fixes: 6188f28b ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Paulo Alcantara <palcantara@suse.de>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>

This patch fixes the following KASAN report:

[  779.044746] BUG: KASAN: slab-out-of-bounds in string+0xab/0x180
[  779.044750] Read of size 1 at addr ffff88814f327968 by task trace-cmd/2812

[  779.044756] CPU: 1 PID: 2812 Comm: trace-cmd Not tainted 5.1.0-rc1+ #62
[  779.044760] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-0-ga698c89-prebuilt.qemu.org 04/01/2014
[  779.044761] Call Trace:
[  779.044769]  dump_stack+0x5b/0x90
[  779.044775]  ? string+0xab/0x180
[  779.044781]  print_address_description+0x6c/0x23c
[  779.044787]  ? string+0xab/0x180
[  779.044792]  ? string+0xab/0x180
[  779.044797]  kasan_report.cold.3+0x1a/0x32
[  779.044803]  ? string+0xab/0x180
[  779.044809]  string+0xab/0x180
[  779.044816]  ? widen_string+0x160/0x160
[  779.044822]  ? vsnprintf+0x5bf/0x7f0
[  779.044829]  vsnprintf+0x4e7/0x7f0
[  779.044836]  ? pointer+0x4a0/0x4a0
[  779.044841]  ? seq_buf_vprintf+0x79/0xc0
[  779.044848]  seq_buf_vprintf+0x62/0xc0
[  779.044855]  trace_seq_printf+0x113/0x210
[  779.044861]  ? trace_seq_puts+0x110/0x110
[  779.044867]  ? trace_raw_output_prep+0xd8/0x110
[  779.044876]  trace_raw_output_smb3_tcon_class+0x9f/0xc0
[  779.044882]  print_trace_line+0x377/0x890
[  779.044888]  ? tracing_buffers_read+0x300/0x300
[  779.044893]  ? ring_buffer_read+0x58/0x70
[  779.044899]  s_show+0x6e/0x140
[  779.044906]  seq_read+0x505/0x6a0
[  779.044913]  vfs_read+0xaf/0x1b0
[  779.044919]  ksys_read+0xa1/0x130
[  779.044925]  ? kernel_write+0xa0/0xa0
[  779.044931]  ? __do_page_fault+0x3d5/0x620
[  779.044938]  do_syscall_64+0x63/0x150
[  779.044944]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  779.044949] RIP: 0033:0x7f62c2c2db31
[ 779.044955] Code: fe ff ff 48 8d 3d 17 9e 09 00 48 83 ec 08 e8 96 02
02 00 66 0f 1f 44 00 00 8b 05 fa fc 2c 00 48 63 ff 85 c0 75 13 31 c0
0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 55 53 48 89 d5 48
89
[  779.044958] RSP: 002b:00007ffd6e116678 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  779.044964] RAX: ffffffffffffffda RBX: 0000560a38be9260 RCX: 00007f62c2c2db31
[  779.044966] RDX: 0000000000002000 RSI: 00007ffd6e116710 RDI: 0000000000000003
[  779.044966] RDX: 0000000000002000 RSI: 00007ffd6e116710 RDI: 0000000000000003
[  779.044969] RBP: 00007f62c2ef5420 R08: 0000000000000000 R09: 0000000000000003
[  779.044972] R10: ffffffffffffffa8 R11: 0000000000000246 R12: 00007ffd6e116710
[  779.044975] R13: 0000000000002000 R14: 0000000000000d68 R15: 0000000000002000

[  779.044981] Allocated by task 1257:
[  779.044987]  __kasan_kmalloc.constprop.5+0xc1/0xd0
[  779.044992]  kmem_cache_alloc+0xad/0x1a0
[  779.044997]  getname_flags+0x6c/0x2a0
[  779.045003]  user_path_at_empty+0x1d/0x40
[  779.045008]  do_faccessat+0x12a/0x330
[  779.045012]  do_syscall_64+0x63/0x150
[  779.045017]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[  779.045019] Freed by task 1257:
[  779.045023]  __kasan_slab_free+0x12e/0x180
[  779.045029]  kmem_cache_free+0x85/0x1b0
[  779.045034]  filename_lookup.part.70+0x176/0x250
[  779.045039]  do_faccessat+0x12a/0x330
[  779.045043]  do_syscall_64+0x63/0x150
[  779.045048]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[  779.045052] The buggy address belongs to the object at ffff88814f326600
which belongs to the cache names_cache of size 4096
[  779.045057] The buggy address is located 872 bytes to the right of
4096-byte region [ffff88814f326600, ffff88814f327600)
[  779.045058] The buggy address belongs to the page:
[  779.045062] page:ffffea00053cc800 count:1 mapcount:0 mapping:ffff88815b191b40 index:0x0 compound_mapcount: 0
[  779.045067] flags: 0x200000000010200(slab|head)
[  779.045075] raw: 0200000000010200 dead000000000100 dead000000000200 ffff88815b191b40
[  779.045081] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
[  779.045083] page dumped because: kasan: bad access detected

[  779.045085] Memory state around the buggy address:
[  779.045089]  ffff88814f327800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  779.045093]  ffff88814f327880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  779.045097] >ffff88814f327900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  779.045099]                                                           ^
[  779.045103]  ffff88814f327980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  779.045107]  ffff88814f327a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  779.045109] ==================================================================
[  779.045110] Disabling lock debugging due to kernel taint

Correctly assign tree name str for smb3_tcon event.
Signed-off-by: Paulo Alcantara (SUSE) <paulo@paulo.ac>
Signed-off-by: Steve French <stfrench@microsoft.com>

Fix Guest/Anonymous sessions so that they work with SMB 3.11.

The commit noted below tightened the conditions and forced signing for
the SMB2-TreeConnect commands as per MS-SMB2.
However, this should only apply to normal user sessions and not for
Guest/Anonumous sessions.

Fixes: 6188f28b ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>

It was mapped to EIO which can be confusing when user space
queries for an object GUID for an object for which the server
file system doesn't support (or hasn't saved one).

As Amir Goldstein suggested this is similar to ENOATTR
(equivalently ENODATA in Linux errno definitions) so
changing NT STATUS code mapping for OBJECTID_NOT_FOUND
to ENODATA.
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Amir Goldstein <amir73il@gmail.com>

dedupe_file_range operations is combiled into remap_file_range.
But it's always skipped for dedupe operations in function
cifs_remap_file_range.

Example to test:
Before this patch:
  # dd if=/dev/zero of=cifs/file bs=1M count=1
  # xfs_io -c "dedupe cifs/file 4k 64k 4k" cifs/file
  XFS_IOC_FILE_EXTENT_SAME: Invalid argument

After this patch:
  # dd if=/dev/zero of=cifs/file bs=1M count=1
  # xfs_io -c "dedupe cifs/file 4k 64k 4k" cifs/file
  XFS_IOC_FILE_EXTENT_SAME: Operation not supported

Influence for xfstests:
generic/091
generic/112
generic/127
generic/263
These tests report this error "do_copy_range:: Invalid
argument" instead of "FIDEDUPERANGE: Invalid argument".
Because there are still two bugs cause these test failed.
https://bugzilla.kernel.org/show_bug.cgi?id=202935
https://bugzilla.kernel.org/show_bug.cgi?id=202785Signed-off-by: Xiaoli Feng <fengxiaoli0714@gmail.com>
Signed-off-by: Steve French <stfrench@microsoft.com>

When sending a rdata, transport may return -EAGAIN. In this case
we should re-obtain credits because the session may have been
reconnected.

Change in v2: adjust_credits before re-sending
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>

When sending a wdata, transport may return -EAGAIN. In this case
we should re-obtain credits because the session may have been
reconnected.

Change in v2: adjust_credits before re-sending
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>