1. Dec 06, 2018
    • Paul Burton's avatar
      MIPS: Expand MIPS32 ASIDs to 64 bits · ff4dd232
      Paul Burton authored
      
      
      ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32
      kernels. This is problematic because it is feasible for the ASID version
      to overflow & wrap around to zero.
      
      We currently attempt to handle this overflow by simply setting the ASID
      version to 1, using asid_first_version(), but we make no attempt to
      account for the fact that there may be mm_structs with stale ASIDs that
      have versions which we now reuse due to the overflow & wrap around.
      
      Encountering this requires that:
      
        1) A struct mm_struct X is active on CPU A using ASID (V,n).
      
        2) That mm is not used on CPU A for the length of time that it takes
           for CPU A's asid_cache to overflow & wrap around to the same
           version V that the mm had in step 1. During this time tasks using
           the mm could either be sleeping or only scheduled on other CPUs.
      
        3) Some other mm Y becomes active on CPU A and is allocated the same
           ASID (V,n).
      
        4) mm X now becomes active on CPU A again, and now incorrectly has the
           same ASID as mm Y.
      
      Where struct mm_struct ASIDs are represented above in the format
      (version, EntryHi.ASID), and on a typical MIPS32 system version will be
      24 bits wide & EntryHi.ASID will be 8 bits wide.
      
      The length of time required in step 2 is highly dependent upon the CPU &
      workload, but for a hypothetical 2GHz CPU running a workload which
      generates a new ASID every 10000 cycles this period is around 248 days.
      Due to this long period of time & the fact that tasks need to be
      scheduled in just the right (or wrong, depending upon your inclination)
      way, this is obviously a difficult bug to encounter but it's entirely
      possible as evidenced by reports.
      
      In order to fix this, simply extend ASIDs to 64 bits even on MIPS32
      builds. This will extend the period of time required for the
      hypothetical system above to encounter the problem from 28 days to
      around 3 trillion years, which feels safely outside of the realms of
      possibility.
      
      The cost of this is slightly more generated code in some commonly
      executed paths, but this is pretty minimal:
      
                               | Code Size Gain | Percentage
        -----------------------|----------------|-------------
          decstation_defconfig |           +270 | +0.00%
              32r2el_defconfig |           +652 | +0.01%
              32r6el_defconfig |          +1000 | +0.01%
      
      I have been unable to measure any change in performance of the LMbench
      lat_ctx or lat_proc tests resulting from the 64b ASIDs on either
      32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Suggested-by: default avatarJames Hogan <jhogan@kernel.org>
      References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/
      References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/
      Cc: Jiwei Sun <jiwei.sun@windriver.com>
      Cc: Yu Huabing <yhb@ruijie.com.cn>
      Cc: stable@vger.kernel.org # 2.6.12+
      Cc: linux-mips@vger.kernel.org
      ff4dd232
  2. Dec 05, 2018
  3. Dec 04, 2018
    • Mathieu Malaterre's avatar
      mips: annotate implicit fall throughs · 69095e39
      Mathieu Malaterre authored
      
      
      There is a plan to build the kernel with -Wimplicit-fallthrough and
      these places in the code produced warnings. Fix them up.
      
      This patch produces no change in behaviour, but should be reviewed in
      case these are actually bugs not intentional fallthoughs.
      
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Kees Cook <keescook@google.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      69095e39
  4. Nov 27, 2018
  5. Nov 22, 2018
  6. Nov 21, 2018
    • Paul Burton's avatar
      MIPS: Regenerate defconfigs · af84c003
      Paul Burton authored
      
      
      A couple of patches have come up recently to remove particular instances
      of obsolete Kconfig symbols from defconfigs. Rather than doing this
      piecemeal, simply regenerate them all.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      References: https://patchwork.linux-mips.org/patch/19635/
      References: https://patchwork.linux-mips.org/patch/21156/
      Patchwork: https://patchwork.linux-mips.org/patch/21184/
      Cc: Anders Roxell <anders.roxell@linaro.org>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: linux-mips@linux-mips.org
      af84c003
    • Paul Burton's avatar
      MIPS: malta: Use img-ascii-lcd driver for LCD display · 0b003749
      Paul Burton authored
      
      
      Remove the Malta display platform code in favour of probing the
      img-ascii-lcd driver via device tree. This reduces the amount of
      platform code & the img-ascii-lcd driver offers us advantages in terms
      of code sharing with other boards & functionality such as changing the
      displayed message via sysfs. Defconfigs are untouched because the driver
      already defaults y on when CONFIG_MIPS_MALTA=y.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21182/
      Cc: linux-mips@linux-mips.org
      0b003749
    • Paul Burton's avatar
      MIPS: ptrace: introduce NT_MIPS_MSA regset · 3cd64083
      Paul Burton authored
      
      
      The current methods for obtaining FP context via ptrace only provide
      either 32 or 64 bits per data register. With MSA, where vector registers
      are aliased with scalar FP data registers, those registers are 128 bits
      wide. Thus a new mechanism is required for userland to access those
      registers via ptrace. This patch introduces an NT_MIPS_MSA regset which
      provides, in this order:
      
        - The full 128 bits value of each vector register, in native
          endianness saved as though elements are doubles. That is, the format
          of each vector register is as would be obtained by saving it to
          memory using an st.d instruction.
      
        - The 32 bit scalar FP implementation register (FIR).
      
        - The 32 bit scalar FP control & status register (FCSR).
      
        - The 32 bit MSA implementation register (MSAIR).
      
        - The 32 bit MSA control & status register (MSACSR).
      
      The provision of the FIR & FCSR registers in addition to the MSA
      equivalents allows scalar FP context to be retrieved as a subset of
      the context available via this regset. Along with the MSA equivalents
      they also nicely form the final 128 bit "register" of the regset.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21180/
      Cc: linux-mips@linux-mips.org
      3cd64083
    • Huacai Chen's avatar
      MIPS: Align kernel load address to 64KB · bec0de4c
      Huacai Chen authored
      
      
      KEXEC needs the new kernel's load address to be aligned on a page
      boundary (see sanity_check_segment_list()), but on MIPS the default
      vmlinuz load address is only explicitly aligned to 16 bytes.
      
      Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
      the alignment calculated by calc_vmlinuz_load_addr to 64KB.
      
      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/21131/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: Steven J . Hill <Steven.Hill@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: <stable@vger.kernel.org> # 2.6.36+
      bec0de4c