1. 14 Feb, 2023 3 commits
  2. 13 Feb, 2023 2 commits
  3. 12 Feb, 2023 10 commits
  4. 11 Feb, 2023 5 commits
  5. 10 Feb, 2023 19 commits
  6. 09 Feb, 2023 1 commit
    • Isaac J. Manjarres's avatar
      of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem · ce4d9a1e
      Isaac J. Manjarres authored
      Patch series "Fix kmemleak crashes when scanning CMA regions", v2.
      
      When trying to boot a device with an ARM64 kernel with the following
      config options enabled:
      
      CONFIG_DEBUG_PAGEALLOC=y
      CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
      CONFIG_DEBUG_KMEMLEAK=y
      
      a crash is encountered when kmemleak starts to scan the list of gray
      or allocated objects that it maintains. Upon closer inspection, it was
      observed that these page-faults always occurred when kmemleak attempted
      to scan a CMA region.
      
      At the moment, kmemleak is made aware of CMA regions that are specified
      through the devicetree to be dynamically allocated within a range of
      addresses. However, kmemleak should not need to scan CMA regions or any
      reserved memory region, as those regions can be used for DMA transfers
      between drivers and peripherals, and thus wouldn't contain anything
      useful for kmemleak.
      
      Additionally, since CMA regions are unmapped from the kernel's address
      space when they are freed to the buddy allocator at boot when
      CONFIG_DEBUG_PAGEALLOC is enabled, kmemleak shouldn't attempt to access
      those memory regions, as that will trigger a crash. Thus, kmemleak
      should ignore all dynamically allocated reserved memory regions.
      
      
      This patch (of 1):
      
      Currently, kmemleak ignores dynamically allocated reserved memory regions
      that don't have a kernel mapping.  However, regions that do retain a
      kernel mapping (e.g.  CMA regions) do get scanned by kmemleak.
      
      This is not ideal for two reasons:
      
      1  kmemleak works by scanning memory regions for pointers to allocated
         objects to determine if those objects have been leaked or not. 
         However, reserved memory regions can be used between drivers and
         peripherals for DMA transfers, and thus, would not contain pointers to
         allocated objects, making it unnecessary for kmemleak to scan these
         reserved memory regions.
      
      2  When CONFIG_DEBUG_PAGEALLOC is enabled, along with kmemleak, the
         CMA reserved memory regions are unmapped from the kernel's address
         space when they are freed to buddy at boot.  These CMA reserved regions
         are still tracked by kmemleak, however, and when kmemleak attempts to
         scan them, a crash will happen, as accessing the CMA region will result
         in a page-fault, since the regions are unmapped.
      
      Thus, use kmemleak_ignore_phys() for all dynamically allocated reserved
      memory regions, instead of those that do not have a kernel mapping
      associated with them.
      
      Link: https://lkml.kernel.org/r/20230208232001.2052777-1-isaacmanjarres@google.com
      Link: https://lkml.kernel.org/r/20230208232001.2052777-2-isaacmanjarres@google.com
      Fixes: a7259df7 ("memblock: make memblock_find_in_range method private")
      Signed-off-by: default avatarIsaac J. Manjarres <isaacmanjarres@google.com>
      Acked-by: default avatarMike Rapoport (IBM) <rppt@kernel.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Kirill A. Shutemov <kirill.shtuemov@linux.intel.com>
      Cc: Nick Kossifidis <mick@ics.forth.gr>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Cc: Saravana Kannan <saravanak@google.com>
      Cc: <stable@vger.kernel.org>	[5.15+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      ce4d9a1e