1. 02 Feb, 2019 5 commits
    • Qian Cai's avatar
      efi/arm64: Fix debugfs crash by adding a terminator for ptdump marker · 74c953ca
      Qian Cai authored
      When reading 'efi_page_tables' debugfs triggers an out-of-bounds access here:
      
        arch/arm64/mm/dump.c: 282
        if (addr >= st->marker[1].start_address) {
      
      called from:
      
        arch/arm64/mm/dump.c: 331
        note_page(st, addr, 2, pud_val(pud));
      
      because st->marker++ is is called after "UEFI runtime end" which is the
      last element in addr_marker[]. Therefore, add a terminator like the one
      for kernel_page_tables, so it can be skipped to print out non-existent
      markers.
      
      Here's the KASAN bug report:
      
        # cat /sys/kernel/debug/efi_page_tables
        ---[ UEFI runtime start ]---
        0x0000000020000000-0x0000000020010000          64K PTE       RW NX SHD AF ...
        0x0000000020200000-0x0000000021340000       17664K PTE       RW NX SHD AF ...
        ...
        0x0000000021920000-0x0000000021950000         192K PTE       RW x  SHD AF ...
        0x0000000021950000-0x00000000219a0000         320K PTE       RW NX SHD AF ...
        ---[ UEFI runtime end ]---
        ---[ (null) ]---
        ---[ (null) ]---
      
         BUG: KASAN: global-out-of-bounds in note_page+0x1f0/0xac0
         Read of size 8 at addr ffff2000123f2ac0 by task read_all/42464
         Call trace:
          dump_backtrace+0x0/0x298
          show_stack+0x24/0x30
          dump_stack+0xb0/0xdc
          print_address_description+0x64/0x2b0
          kasan_report+0x150/0x1a4
          __asan_report_load8_noabort+0x30/0x3c
          note_page+0x1f0/0xac0
          walk_pgd+0xb4/0x244
          ptdump_walk_pgd+0xec/0x140
          ptdump_show+0x40/0x50
          seq_read+0x3f8/0xad0
          full_proxy_read+0x9c/0xc0
          __vfs_read+0xfc/0x4c8
          vfs_read+0xec/0x208
          ksys_read+0xd0/0x15c
          __arm64_sys_read+0x84/0x94
          el0_svc_handler+0x258/0x304
          el0_svc+0x8/0xc
      
        The buggy address belongs to the variable:
         __compound_literal.0+0x20/0x800
      
        Memory state around the buggy address:
         ffff2000123f2980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         ffff2000123f2a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
        >ffff2000123f2a80: fa fa fa fa 00 00 00 00 fa fa fa fa 00 00 00 00
                                                  ^
         ffff2000123f2b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         ffff2000123f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
      
      [ ardb: fix up whitespace ]
      [ mingo: fix up some moar ]
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 9d80448a ("efi/arm64: Add debugfs node to dump UEFI runtime page tables")
      Link: http://lkml.kernel.org/r/20190202095017.13799-2-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      74c953ca
    • Linus Torvalds's avatar
      Merge tag 'xtensa-20190201' of git://github.com/jcmvbkbc/linux-xtensa · cd984a5b
      Linus Torvalds authored
      Pull xtensa fixes from Max Filippov:
      
       - fix ccount_timer_shutdown for secondary CPUs
      
       - fix secondary CPU initialization
      
       - fix secondary CPU reset vector clash with double exception vector
      
       - fix present CPUs when booting with 'maxcpus' parameter
      
       - limit possible CPUs by configured NR_CPUS
      
       - issue a warning if xtensa PIC is asked to retrigger anything other
         than software IRQ
      
       - fix masking/unmasking of the first two IRQs on xtensa MX PIC
      
       - fix typo in Kconfig description for user space unaligned access
         feature
      
       - fix Kconfig warning for selecting BUILTIN_DTB
      
      * tag 'xtensa-20190201' of git://github.com/jcmvbkbc/linux-xtensa:
        xtensa: SMP: limit number of possible CPUs by NR_CPUS
        xtensa: rename BUILTIN_DTB to BUILTIN_DTB_SOURCE
        xtensa: Fix typo use space=>user space
        drivers/irqchip: xtensa-mx: fix mask and unmask
        drivers/irqchip: xtensa: add warning to irq_retrigger
        xtensa: SMP: mark each possible CPU as present
        xtensa: smp_lx200_defconfig: fix vectors clash
        xtensa: SMP: fix secondary CPU initialization
        xtensa: SMP: fix ccount_timer_shutdown
      cd984a5b
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · 8b050fe4
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "Although we're still debugging a few minor arm64-specific issues in
        mainline, I didn't want to hold this lot up in the meantime.
      
        We've got an additional KASLR fix after the previous one wasn't quite
        complete, a fix for a performance regression when mapping executable
        pages into userspace and some fixes for kprobe blacklisting. All
        candidates for stable.
      
        Summary:
      
         - Fix module loading when KASLR is configured but disabled at runtime
      
         - Fix accidental IPI when mapping user executable pages
      
         - Ensure hyp-stub and KVM world switch code cannot be kprobed"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: hibernate: Clean the __hyp_text to PoC after resume
        arm64: hyp-stub: Forbid kprobing of the hyp-stub
        arm64: kprobe: Always blacklist the KVM world-switch code
        arm64: kaslr: ensure randomized quantities are clean also when kaslr is off
        arm64: Do not issue IPIs for user executable ptes
      8b050fe4
    • Linus Torvalds's avatar
      Merge tag '5.0-rc4-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6 · 33640d71
      Linus Torvalds authored
      Pull smb3 fixes from Steve French:
       "SMB3 fixes, some from this week's SMB3 test evemt, 5 for stable and a
        particularly important one for queryxattr (see xfstests 70 and 117)"
      
      * tag '5.0-rc4-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
        cifs: update internal module version number
        CIFS: fix use-after-free of the lease keys
        CIFS: Do not consider -ENODATA as stat failure for reads
        CIFS: Do not count -ENODATA as failure for query directory
        CIFS: Fix trace command logging for SMB2 reads and writes
        CIFS: Fix possible oops and memory leaks in async IO
        cifs: limit amount of data we request for xattrs to CIFSMaxBufSize
        cifs: fix computation for MAX_SMB2_HDR_SIZE
      33640d71
    • Linus Torvalds's avatar
      Merge tag 'apparmor-pr-2019-02-01' of... · b7bd29b5
      Linus Torvalds authored
      Merge tag 'apparmor-pr-2019-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
      
      Pull apparmor bug fixes from John Johansen:
       "Two bug fixes for apparmor:
      
         - Fix aa_label_build() error handling for failed merges
      
         - Fix warning about unused function apparmor_ipv6_postroute"
      
      * tag 'apparmor-pr-2019-02-01' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor:
        apparmor: Fix aa_label_build() error handling for failed merges
        apparmor: Fix warning about unused function apparmor_ipv6_postroute
      b7bd29b5
  2. 01 Feb, 2019 19 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma · 5eeb6335
      Linus Torvalds authored
      Pull rdma fixes from Jason Gunthorpe:
       "Still not much going on, the usual set of oops and driver fixes this
        time:
      
         - Fix two uapi breakage regressions in mlx5 drivers
      
         - Various oops fixes in hfi1, mlx4, umem, uverbs, and ipoib
      
         - A protocol bug fix for hfi1 preventing it from implementing the
           verbs API properly, and a compatability fix for EXEC STACK user
           programs
      
         - Fix missed refcounting in the 'advise_mr' patches merged this
           cycle.
      
         - Fix wrong use of the uABI in the hns SRQ patches merged this cycle"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
        IB/uverbs: Fix OOPs in uverbs_user_mmap_disassociate
        IB/ipoib: Fix for use-after-free in ipoib_cm_tx_start
        IB/uverbs: Fix ioctl query port to consider device disassociation
        RDMA/mlx5: Fix flow creation on representors
        IB/uverbs: Fix OOPs upon device disassociation
        RDMA/umem: Add missing initialization of owning_mm
        RDMA/hns: Update the kernel header file of hns
        IB/mlx5: Fix how advise_mr() launches async work
        RDMA/device: Expose ib_device_try_get(()
        IB/hfi1: Add limit test for RC/UC send via loopback
        IB/hfi1: Remove overly conservative VM_EXEC flag check
        IB/{hfi1, qib}: Fix WC.byte_len calculation for UD_SEND_WITH_IMM
        IB/mlx4: Fix using wrong function to destroy sqp AHs under SRIOV
        RDMA/mlx5: Fix check for supported user flags when creating a QP
      5eeb6335
    • Linus Torvalds's avatar
      Merge tag 'iomap-5.0-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 9ace868a
      Linus Torvalds authored
      Pull iomap fixes from Darrick Wong:
       "A couple of iomap fixes to eliminate some memory corruption and hang
        problems that were reported:
      
         - fix page migration when using iomap for pagecache management
      
         - fix a use-after-free bug in the directio code"
      
      * tag 'iomap-5.0-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        iomap: fix a use after free in iomap_dio_rw
        iomap: get/put the page in iomap_page_create/release()
      9ace868a
    • Linus Torvalds's avatar
      Merge tag 'pm-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 3325254c
      Linus Torvalds authored
      Pull power management fixes from Rafael Wysocki:
       "These fix a PM-runtime framework regression introduced by the recent
        switch-over of device autosuspend to hrtimers and a mistake in the
        "poll idle state" code introduced by a recent change in it.
      
        Specifics:
      
         - Since ktime_get() turns out to be problematic for device
           autosuspend in the PM-runtime framework, make it use
           ktime_get_mono_fast_ns() instead (Vincent Guittot).
      
         - Fix an initial value of a local variable in the "poll idle state"
           code that makes it behave not exactly as expected when all idle
           states except for the "polling" one are disabled (Doug Smythies)"
      
      * tag 'pm-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        cpuidle: poll_state: Fix default time limit
        PM-runtime: Fix deadlock with ktime_get()
      3325254c
    • Linus Torvalds's avatar
      Merge tag 'acpi-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 4771eec1
      Linus Torvalds authored
      Pull ACPI Kconfig fixes from Rafael Wysocki:
       "Prevent invalid configurations from being created (e.g. by randconfig)
        due to some ACPI-related Kconfig options' dependencies that are not
        specified directly (Sinan Kaya)"
      
      * tag 'acpi-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        platform/x86: Fix unmet dependency warning for SAMSUNG_Q10
        platform/x86: Fix unmet dependency warning for ACPI_CMPC
        mfd: Fix unmet dependency warning for MFD_TPS68470
      4771eec1
    • Linus Torvalds's avatar
      Merge tag 'mmc-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc · cca2e06a
      Linus Torvalds authored
      Pull MMC host fixes from Ulf Hansson:
      
       - mediatek: Fix incorrect register write for tunings
      
       - bcm2835: Fixup leakage of DMA channel on probe errors
      
      * tag 'mmc-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
        mmc: mediatek: fix incorrect register setting of hs400_cmd_int_delay
        mmc: bcm2835: Fix DMA channel leak on probe error
      cca2e06a
    • Linus Torvalds's avatar
      Merge tag 'i3c/fixes-for-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux · 520fac05
      Linus Torvalds authored
      Pull i3c fixes from Boris Brezillon:
      
       - Fix a deadlock in the designware driver
      
       - Fix the error path in i3c_master_add_i3c_dev_locked()
      
      * tag 'i3c/fixes-for-5.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux:
        i3c: master: dw: fix deadlock
        i3c: fix missing detach if failed to retrieve i3c dev
      520fac05
    • Linus Torvalds's avatar
      x86: explicitly align IO accesses in memcpy_{to,from}io · c228d294
      Linus Torvalds authored
      In commit 170d13ca ("x86: re-introduce non-generic memcpy_{to,from}io")
      I made our copy from IO space use a separate copy routine rather than
      rely on the generic memcpy.  I did that because our generic memory copy
      isn't actually well-defined when it comes to internal access ordering or
      alignment, and will in fact depend on various CPUID flags.
      
      In particular, the default memcpy() for a modern Intel CPU will
      generally be just a "rep movsb", which works reasonably well for
      medium-sized memory copies of regular RAM, since the CPU will turn it
      into fairly optimized microcode.
      
      However, for non-cached memory and IO, "rep movs" ends up being
      horrendously slow and will just do the architectural "one byte at a
      time" accesses implied by the movsb.
      
      At the other end of the spectrum, if you _don't_ end up using the "rep
      movsb" code, you'd likely fall back to the software copy, which does
      overlapping accesses for the tail, and may copy things backwards.
      Again, for regular memory that's fine, for IO memory not so much.
      
      The thinking was that clearly nobody really cared (because things
      worked), but some people had seen horrible performance due to the byte
      accesses, so let's just revert back to our long ago version that dod
      "rep movsl" for the bulk of the copy, and then fixed up the potentially
      last few bytes of the tail with "movsw/b".
      
      Interestingly (and perhaps not entirely surprisingly), while that was
      our original memory copy implementation, and had been used before for
      IO, in the meantime many new users of memcpy_*io() had come about.  And
      while the access patterns for the memory copy weren't well-defined (so
      arguably _any_ access pattern should work), in practice the "rep movsb"
      case had been very common for the last several years.
      
      In particular Jarkko Sakkinen reported that the memcpy_*io() change
      resuled in weird errors from his Geminilake NUC TPM module.
      
      And it turns out that the TPM TCG accesses according to spec require
      that the accesses be
      
       (a) done strictly sequentially
      
       (b) be naturally aligned
      
      otherwise the TPM chip will abort the PCI transaction.
      
      And, in fact, the tpm_crb.c driver did this:
      
      	memcpy_fromio(buf, priv->rsp, 6);
      	...
      	memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
      
      which really should never have worked in the first place, but back
      before commit 170d13ca it *happened* to work, because the
      memcpy_fromio() would be expanded to a regular memcpy, and
      
       (a) gcc would expand the first memcpy in-line, and turn it into a
           4-byte and a 2-byte read, and they happened to be in the right
           order, and the alignment was right.
      
       (b) gcc would call "memcpy()" for the second one, and the machines that
           had this TPM chip also apparently ended up always having ERMS
           ("Enhanced REP MOVSB/STOSB instructions"), so we'd use the "rep
           movbs" for that copy.
      
      In other words, basically by pure luck, the code happened to use the
      right access sizes in the (two different!) memcpy() implementations to
      make it all work.
      
      But after commit 170d13ca, both of the memcpy_fromio() calls
      resulted in a call to the routine with the consistent memory accesses,
      and in both cases it started out transferring with 4-byte accesses.
      Which worked for the first copy, but resulted in the second copy doing a
      32-bit read at an address that was only 2-byte aligned.
      
      Jarkko is actually fixing the fragile code in the TPM driver, but since
      this is an excellent example of why we absolutely must not use a generic
      memcpy for IO accesses, _and_ an IO-specific one really should strive to
      align the IO accesses, let's do exactly that.
      
      Side note: Jarkko also noted that the driver had been used on ARM
      platforms, and had worked.  That was because on 32-bit ARM, memcpy_*io()
      ends up always doing byte accesses, and on 64-bit ARM it first does byte
      accesses to align to 8-byte boundaries, and then does 8-byte accesses
      for the bulk.
      
      So ARM actually worked by design, and the x86 case worked by pure luck.
      
      We *might* want to make x86-64 do the 8-byte case too.  That should be a
      pretty straightforward extension, but let's do one thing at a time.  And
      generally MMIO accesses aren't really all that performance-critical, as
      shown by the fact that for a long time we just did them a byte at a
      time, and very few people ever noticed.
      Reported-and-tested-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Tested-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Cc: David Laight <David.Laight@aculab.com>
      Fixes: 170d13ca ("x86: re-introduce non-generic memcpy_{to,from}io")
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c228d294
    • John Johansen's avatar
      apparmor: Fix aa_label_build() error handling for failed merges · d6d478ae
      John Johansen authored
      aa_label_merge() can return NULL for memory allocations failures
      make sure to handle and set the correct error in this case.
      Reported-by: default avatarPeng Hao <peng.hao2@zte.com.cn>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      d6d478ae
    • James Morse's avatar
      arm64: hibernate: Clean the __hyp_text to PoC after resume · f7daa9c8
      James Morse authored
      During resume hibernate restores all physical memory. Any memory
      that is accessed with the MMU disabled needs to be cleaned to the
      PoC.
      
      KVMs __hyp_text was previously ommitted as it runs with the MMU
      enabled, but now that the hyp-stub is located in this section,
      we must clean __hyp_text too.
      
      This ensures secondary CPUs that come online after hibernate
      has finished resuming, and load KVM via the freshly written
      hyp-stub see the correct instructions.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f7daa9c8
    • James Morse's avatar
      arm64: hyp-stub: Forbid kprobing of the hyp-stub · 8fac5cbd
      James Morse authored
      The hyp-stub is loaded by the kernel's early startup code at EL2
      during boot, before KVM takes ownership later. The hyp-stub's
      text is part of the regular kernel text, meaning it can be kprobed.
      
      A breakpoint in the hyp-stub causes the CPU to spin in el2_sync_invalid.
      
      Add it to the __hyp_text.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8fac5cbd
    • James Morse's avatar
      arm64: kprobe: Always blacklist the KVM world-switch code · f2b3d856
      James Morse authored
      On systems with VHE the kernel and KVM's world-switch code run at the
      same exception level. Code that is only used on a VHE system does not
      need to be annotated as __hyp_text as it can reside anywhere in the
       kernel text.
      
      __hyp_text was also used to prevent kprobes from patching breakpoint
      instructions into this region, as this code runs at a different
      exception level. While this is no longer true with VHE, KVM still
      switches VBAR_EL1, meaning a kprobe's breakpoint executed in the
      world-switch code will cause a hyp-panic.
      
      Move the __hyp_text check in the kprobes blacklist so it applies on
      VHE systems too, to cover the common code and guest enter/exit
      assembly.
      
      Fixes: 888b3c87 ("arm64: Treat all entry code as non-kprobe-able")
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f2b3d856
    • Ard Biesheuvel's avatar
      arm64: kaslr: ensure randomized quantities are clean also when kaslr is off · 8ea23593
      Ard Biesheuvel authored
      Commit 1598ecda ("arm64: kaslr: ensure randomized quantities are
      clean to the PoC") added cache maintenance to ensure that global
      variables set by the kaslr init routine are not wiped clean due to
      cache invalidation occurring during the second round of page table
      creation.
      
      However, if kaslr_early_init() exits early with no randomization
      being applied (either due to the lack of a seed, or because the user
      has disabled kaslr explicitly), no cache maintenance is performed,
      leading to the same issue we attempted to fix earlier, as far as the
      module_alloc_base variable is concerned.
      
      Note that module_alloc_base cannot be initialized statically, because
      that would cause it to be subject to a R_AARCH64_RELATIVE relocation,
      causing it to be overwritten by the second round of KASLR relocation
      processing.
      
      Fixes: f80fb3a3 ("arm64: add support for kernel ASLR")
      Cc: <stable@vger.kernel.org> # v4.6+
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      8ea23593
    • Catalin Marinas's avatar
      arm64: Do not issue IPIs for user executable ptes · 132fdc37
      Catalin Marinas authored
      Commit 3b8c9f1c ("arm64: IPI each CPU after invalidating the I-cache
      for kernel mappings") was aimed at fixing the I-cache invalidation for
      kernel mappings. However, it inadvertently caused all cache maintenance
      for user mappings via set_pte_at() -> __sync_icache_dcache() ->
      sync_icache_aliases() to call kick_all_cpus_sync().
      Reported-by: default avatarShijith Thotton <sthotton@marvell.com>
      Tested-by: default avatarShijith Thotton <sthotton@marvell.com>
      Reported-by: default avatarWandun Chen <chenwandun@huawei.com>
      Fixes: 3b8c9f1c ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
      Cc: <stable@vger.kernel.org> # 4.19.x-
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      132fdc37
    • Petr Vorel's avatar
      apparmor: Fix warning about unused function apparmor_ipv6_postroute · a1a02062
      Petr Vorel authored
      when compiled without CONFIG_IPV6:
      security/apparmor/lsm.c:1601:21: warning: ‘apparmor_ipv6_postroute’ defined but not used [-Wunused-function]
       static unsigned int apparmor_ipv6_postroute(void *priv,
                           ^~~~~~~~~~~~~~~~~~~~~~~
      Reported-by: default avatarJordan Glover <Golden_Miller83@protonmail.ch>
      Tested-by: default avatarJordan Glover <Golden_Miller83@protonmail.ch>
      Signed-off-by: default avatarPetr Vorel <pvorel@suse.cz>
      Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      a1a02062
    • Rafael J. Wysocki's avatar
      Merge branch 'acpi-misc' · b473406a
      Rafael J. Wysocki authored
      * acpi-misc:
        platform/x86: Fix unmet dependency warning for SAMSUNG_Q10
        platform/x86: Fix unmet dependency warning for ACPI_CMPC
      b473406a
    • Rafael J. Wysocki's avatar
      Merge branch 'pm-cpuidle-fixes' · cbffab68
      Rafael J. Wysocki authored
      * pm-cpuidle-fixes:
        cpuidle: poll_state: Fix default time limit
      cbffab68
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 5b4746a0
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "Mostly driver fixes, but there's a core framework fix in here too:
      
         - Revert the commits that introduce clk management for the SP clk on
           MMP2 SoCs (used for OLPC). Turns out it wasn't a good idea and
           there isn't any need to manage this clk, it just causes more
           headaches.
      
         - A performance regression that went unnoticed for many years where
           we would traverse the entire clk tree looking for a clk by name
           when we already have the pointer to said clk that we're looking for
      
         - A parent linkage fix for the qcom SDM845 clk driver
      
         - An i.MX clk driver rate miscalculation fix where order of
           operations were messed up
      
         - One error handling fix from the static checkers"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: qcom: gcc: Use active only source for CPUSS clocks
        clk: ti: Fix error handling in ti_clk_parse_divider_data()
        clk: imx: Fix fractional clock set rate computation
        clk: Remove global clk traversal on fetch parent index
        Revert "dt-bindings: marvell,mmp2: Add clock id for the SP clock"
        Revert "clk: mmp2: add SP clock"
        Revert "Input: olpc_apsp - enable the SP clock"
      5b4746a0
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 52107c54
      Linus Torvalds authored
      Pull crypto fix from Herbert Xu:
       "This fixes a bug in cavium/nitrox where the callback is invoked prior
        to the DMA unmap"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: cavium/nitrox - Invoke callback after DMA unmap
      52107c54
    • Linus Torvalds's avatar
      Merge tag 'pci-v5.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · 44e56f32
      Linus Torvalds authored
      Pull PCI fixes from Bjorn Helgaas:
      
       - Revert armada8k GPIO reset change that broke Macchiatobin booting
         (Baruch Siach)
      
       - Use actual size config reads on ARM cns3xxx (Koen Vandeputte)
      
       - Fix ARM cns3xxx config write alignment issue (Koen Vandeputte)
      
       - Fix imx6 PHY device link error checking (Leonard Crestez)
      
       - Fix imx6 probe failure on chips without separate PCI power domain
         (Leonard Crestez)
      
      * tag 'pci-v5.0-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        Revert "PCI: armada8k: Add support for gpio controlled reset signal"
        ARM: cns3xxx: Use actual size reads for PCIe
        ARM: cns3xxx: Fix writing to wrong PCI config registers after alignment
        PCI: imx: Fix checking pd_pcie_phy device link addition
        PCI: imx: Fix probe failure without power domain
      44e56f32
  3. 31 Jan, 2019 11 commits
  4. 30 Jan, 2019 5 commits
    • Doug Smythies's avatar
      cpuidle: poll_state: Fix default time limit · 1617971c
      Doug Smythies authored
      The default time is declared in units of microsecnds,
      but is used as nanoseconds, resulting in significant
      accounting errors for idle state 0 time when all idle
      states deeper than 0 are disabled.
      
      Under these unusual conditions, we don't really care
      about the poll time limit anyhow.
      
      Fixes: 800fb34a ("cpuidle: poll_state: Disregard disable idle states")
      Signed-off-by: default avatarDoug Smythies <dsmythies@telus.net>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1617971c
    • Vincent Guittot's avatar
      PM-runtime: Fix deadlock with ktime_get() · 15efb47d
      Vincent Guittot authored
      A deadlock has been seen when swicthing clocksources which use
      PM-runtime.  The call path is:
      
      change_clocksource
          ...
          write_seqcount_begin
          ...
          timekeeping_update
              ...
              sh_cmt_clocksource_enable
                  ...
                  rpm_resume
                      pm_runtime_mark_last_busy
                          ktime_get
                              do
                                  read_seqcount_begin
                              while read_seqcount_retry
          ....
          write_seqcount_end
      
      Although we should be safe because we haven't yet changed the
      clocksource at that time, we can't do that because of seqcount
      protection.
      
      Use ktime_get_mono_fast_ns() instead which is lock safe for such
      cases.
      
      With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
      monotonic across an update and as a result can goes backward.
      According to update_fast_timekeeper() description: "In the worst
      case, this can result is a slightly wrong timestamp (a few
      nanoseconds)". For PM-runtime autosuspend, this means only that
      the suspend decision may be slightly suboptimal.
      
      Fixes: 8234f673 ("PM-runtime: Switch autosuspend over to using hrtimers")
      Reported-by: default avatarBiju Das <biju.das@bp.renesas.com>
      Signed-off-by: default avatarVincent Guittot <vincent.guittot@linaro.org>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      15efb47d
    • Waiman Long's avatar
      fs/dcache: Track & report number of negative dentries · af0c9af1
      Waiman Long authored
      The current dentry number tracking code doesn't distinguish between
      positive & negative dentries.  It just reports the total number of
      dentries in the LRU lists.
      
      As excessive number of negative dentries can have an impact on system
      performance, it will be wise to track the number of positive and
      negative dentries separately.
      
      This patch adds tracking for the total number of negative dentries in
      the system LRU lists and reports it in the 5th field in the
      /proc/sys/fs/dentry-state file.  The number, however, does not include
      negative dentries that are in flight but not in the LRU yet as well as
      those in the shrinker lists which are on the way out anyway.
      
      The number of positive dentries in the LRU lists can be roughly found by
      subtracting the number of negative dentries from the unused count.
      
      Matthew Wilcox had confirmed that since the introduction of the
      dentry_stat structure in 2.1.60, the dummy array was there, probably for
      future extension.  They were not replacements of pre-existing fields.
      So no sane applications that read the value of /proc/sys/fs/dentry-state
      will do dummy thing if the last 2 fields of the sysctl parameter are not
      zero.  IOW, it will be safe to use one of the dummy array entry for
      negative dentry count.
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      af0c9af1
    • Waiman Long's avatar
      fs: Don't need to put list_lru into its own cacheline · 7d10f70f
      Waiman Long authored
      The list_lru structure is essentially just a pointer to a table of
      per-node LRU lists.  Even if CONFIG_MEMCG_KMEM is defined, the list
      field is just used for LRU list registration and shrinker_id is set at
      initialization.  Those fields won't need to be touched that often.
      
      So there is no point to make the list_lru structures to sit in their own
      cachelines.
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7d10f70f
    • Waiman Long's avatar
      fs/dcache: Fix incorrect nr_dentry_unused accounting in shrink_dcache_sb() · 1dbd449c
      Waiman Long authored
      The nr_dentry_unused per-cpu counter tracks dentries in both the LRU
      lists and the shrink lists where the DCACHE_LRU_LIST bit is set.
      
      The shrink_dcache_sb() function moves dentries from the LRU list to a
      shrink list and subtracts the dentry count from nr_dentry_unused.  This
      is incorrect as the nr_dentry_unused count will also be decremented in
      shrink_dentry_list() via d_shrink_del().
      
      To fix this double decrement, the decrement in the shrink_dcache_sb()
      function is taken out.
      
      Fixes: 4e717f5c ("list_lru: remove special case function list_lru_dispose_all."
      Cc: stable@kernel.org
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1dbd449c