Skip to content
  1. Jul 31, 2015
  2. Jul 30, 2015
  3. Jul 28, 2015
  4. Jul 11, 2015
    • John David Anglin's avatar
      parisc: Fix some PTE/TLB race conditions and optimize __flush_tlb_range based on timing results · 01ab6057
      John David Anglin authored
      
      
      The increased use of pdtlb/pitlb instructions seemed to increase the
      frequency of random segmentation faults building packages. Further, we
      had a number of cases where TLB inserts would repeatedly fail and all
      forward progress would stop. The Haskell ghc package caused a lot of
      trouble in this area. The final indication of a race in pte handling was
      this syslog entry on sibaris (C8000):
      
       swap_free: Unused swap offset entry 00000004
       BUG: Bad page map in process mysqld  pte:00000100 pmd:019bbec5
       addr:00000000ec464000 vm_flags:00100073 anon_vma:0000000221023828 mapping: (null) index:ec464
       CPU: 1 PID: 9176 Comm: mysqld Not tainted 4.0.0-2-parisc64-smp #1 Debian 4.0.5-1
       Backtrace:
        [<0000000040173eb0>] show_stack+0x20/0x38
        [<0000000040444424>] dump_stack+0x9c/0x110
        [<00000000402a0d38>] print_bad_pte+0x1a8/0x278
        [<00000000402a28b8>] unmap_single_vma+0x3d8/0x770
        [<00000000402a4090>] zap_page_range+0xf0/0x198
        [<00000000402ba2a4>] SyS_madvise+0x404/0x8c0
      
      Note that the pte value is 0 except for the accessed bit 0x100. This bit
      shouldn't be set without the present bit.
      
      It should be noted that the madvise system call is probably a trigger for many
      of the random segmentation faults.
      
      In looking at the kernel code, I found the following problems:
      
      1) The pte_clear define didn't take TLB lock when clearing a pte.
      2) We didn't test pte present bit inside lock in exception support.
      3) The pte and tlb locks needed to merged in order to ensure consistency
      between page table and TLB. This also has the effect of serializing TLB
      broadcasts on SMP systems.
      
      The attached change implements the above and a few other tweaks to try
      to improve performance. Based on the timing code, TLB purges are very
      slow (e.g., ~ 209 cycles per page on rp3440). Thus, I think it
      beneficial to test the split_tlb variable to avoid duplicate purges.
      Probably, all PA 2.0 machines have combined TLBs.
      
      I dropped using __flush_tlb_range in flush_tlb_mm as I realized all
      applications and most threads have a stack size that is too large to
      make this useful. I added some comments to this effect.
      
      Since implementing 1 through 3, I haven't had any random segmentation
      faults on mx3210 (rp3440) in about one week of building code and running
      as a Debian buildd.
      
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      01ab6057
  5. Jul 10, 2015
  6. Jul 09, 2015
  7. Jul 08, 2015
  8. Jul 07, 2015
    • Al Stone's avatar
      ACPI / ARM64 : use the new BAD_MADT_GICC_ENTRY macro · 99e3e3ae
      Al Stone authored
      For those parts of the arm64 ACPI code that need to check GICC subtables
      in the MADT, use the new BAD_MADT_GICC_ENTRY macro instead of the previous
      BAD_MADT_ENTRY.  The new macro takes into account differences in the size
      of the GICC subtable that the old macro did not; this caused failures even
      though the subtable entries are valid.
      
      Fixes: aeb823bb
      
       ("ACPICA: ACPI 6.0: Add changes for FADT table.")
      Signed-off-by: default avatarAl Stone <al.stone@linaro.org>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatar"Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      99e3e3ae
    • Al Stone's avatar
      ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro · b6cfb277
      Al Stone authored
      The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
      of the MADT.  In the ACPI 5.1 version of the spec, the struct for the
      GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
      ACPI 6.0, the struct is 80 bytes long.  But, there is only one definition
      in ACPICA for this struct -- and that is the 6.0 version.  Hence, when
      BAD_MADT_ENTRY() compares the struct size to the length in the GICC
      subtable, it fails if 5.1 structs are in use, and there are systems in
      the wild that have them.
      
      This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
      only, accounting for the difference in specification versions that are
      possible.  The BAD_MADT_ENTRY() will continue to work as is for all other
      MADT subtables.
      
      This code is being added to an arm64 header file since that is currently
      the only architecture using the GICC subtable of the MADT.  As a GIC is
      specific to ARM, it is also unlikely the subtable will be used elsewhere.
      
      Fixes: aeb823bb
      
       ("ACPICA: ACPI 6.0: Add changes for FADT table.")
      Signed-off-by: default avatarAl Stone <al.stone@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatar"Rafael J. Wysocki" <rjw@rjwysocki.net>
      [catalin.marinas@arm.com: extra brackets around macro arguments]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b6cfb277