1. 05 May, 2020 3 commits
  2. 27 Apr, 2020 1 commit
    • Lars Hofhansl's avatar
      platform/x86: thinkpad_acpi: Add support for dual fan control · 14232c6e
      Lars Hofhansl authored
      This adds dual fan control for the following models:
      P50, P51, P52, P70, P71, P72, P1 gen1, P2 gen2, X1E gen1 and X1E gen2.
      
      Both fans are controlled together as if they were a single fan.
      
      Tested on an X1 Extreme Gen1, an X1 Extreme Gen2, and a P50.
      
      The patch is defensive, it adds only specific supported machines, and falls
      back to the old behavior if both fans cannot be controlled.
      
      Background:
      I tested the BIOS default behavior on my X1E gen2 and both fans are always
      changed together. So rather than adding controls for each fan, this controls
      both fans together as the BIOS would do.
      
      This was inspired by a discussion on dual fan support for the thinkfan tool
      (see link below). All BIOS IDs are taken from there. The X1E gen2 ID is
      verified on my machine.
      
      Thanks to GitHub users voidworker and civic9 for the earlier patches and
      BIOS IDs, and to users peter-stoll and sassman for testing the patch on
      their machines.
      
      BugLink: https://github.com/vmatare/thinkfan/issues/58Signed-off-by: default avatarLars Hofhansl <larsh@apache.org>
      [andy: massaged commit message to capitalize ID and convert to BugLink]
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      14232c6e
  3. 24 Apr, 2020 23 commits
  4. 23 Apr, 2020 4 commits
  5. 20 Apr, 2020 7 commits
  6. 19 Apr, 2020 2 commits
    • Linus Torvalds's avatar
      Linux 5.7-rc2 · ae83d0b4
      Linus Torvalds authored
      ae83d0b4
    • Brian Geffon's avatar
      mm: Fix MREMAP_DONTUNMAP accounting on VMA merge · dadbd85f
      Brian Geffon authored
      When remapping a mapping where a portion of a VMA is remapped
      into another portion of the VMA it can cause the VMA to become
      split. During the copy_vma operation the VMA can actually
      be remerged if it's an anonymous VMA whose pages have not yet
      been faulted. This isn't normally a problem because at the end
      of the remap the original portion is unmapped causing it to
      become split again.
      
      However, MREMAP_DONTUNMAP leaves that original portion in place which
      means that the VMA which was split and then remerged is not actually
      split at the end of the mremap. This patch fixes a bug where
      we don't detect that the VMAs got remerged and we end up
      putting back VM_ACCOUNT on the next mapping which is completely
      unreleated. When that next mapping is unmapped it results in
      incorrectly unaccounting for the memory which was never accounted,
      and eventually we will underflow on the memory comittment.
      
      There is also another issue which is similar, we're currently
      accouting for the number of pages in the new_vma but that's wrong.
      We need to account for the length of the remap operation as that's
      all that is being added. If there was a mapping already at that
      location its comittment would have been adjusted as part of
      the munmap at the start of the mremap.
      
      A really simple repro can be seen in:
      https://gist.github.com/bgaff/e101ce99da7d9a8c60acc641d07f312c
      
      Fixes: e346b381 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarBrian Geffon <bgeffon@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dadbd85f