1. 13 Oct, 2017 1 commit
  2. 10 Jul, 2017 2 commits
    • Doug Berger's avatar
      cma: fix calculation of aligned offset · e048cb32
      Doug Berger authored
      The align_offset parameter is used by bitmap_find_next_zero_area_off()
      to represent the offset of map's base from the previous alignment
      boundary; the function ensures that the returned index, plus the
      align_offset, honors the specified align_mask.
      
      The logic introduced by commit b5be83e3 ("mm: cma: align to physical
      address, not CMA region position") has the cma driver calculate the
      offset to the *next* alignment boundary.  In most cases, the base
      alignment is greater than that specified when making allocations,
      resulting in a zero offset whether we align up or down.  In the example
      given with the commit, the base alignment (8MB) was half the requested
      alignment (16MB) so the math also happened to work since the offset is
      8MB in both directions.  However, when requesting allocations with an
      alignment greater than twice that of the base, the returned index would
      not be correctly aligned.
      
      Also, the align_order arguments of cma_bitmap_aligned_mask() and
      cma_bitmap_aligned_offset() should not be negative so the argument type
      was made unsigned.
      
      Fixes: b5be83e3 ("mm: cma: align to physical address, not CMA region position")
      Link: http://lkml.kernel.org/r/20170628170742.2895-1-opendmb@gmail.comSigned-off-by: default avatarAngus Clark <angus@angusclark.org>
      Signed-off-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarGregory Fong <gregory.0xf0@gmail.com>
      Cc: Doug Berger <opendmb@gmail.com>
      Cc: Angus Clark <angus@angusclark.org>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Shiraz Hashim <shashim@codeaurora.org>
      Cc: Jaewon Kim <jaewon31.kim@samsung.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e048cb32
    • Anshuman Khandual's avatar
      mm/cma.c: warn if the CMA area could not be activated · e35ef639
      Anshuman Khandual authored
      While activating a CMA area we check to make sure that all the PFNs in
      the range are inside the same zone.  This is a requirement for
      alloc_contig_range() to work.  Any CMA area failing the check is
      disabled for good.  This happens silently right now making all future
      cma_alloc() allocations failure inevitable.
      
      Here we add an error message stating that the CMA area could not be
      activated which makes it easier to explain any future cma_alloc()
      failures on it.  While in there, change the bail out goto label from
      'err' to 'not_in_zone' which makes more sense.
      
      Link: http://lkml.kernel.org/r/20170605023729.26303-1-khandual@linux.vnet.ibm.comSigned-off-by: default avatarAnshuman Khandual <khandual@linux.vnet.ibm.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e35ef639
  3. 18 Apr, 2017 2 commits
  4. 25 Feb, 2017 3 commits
  5. 11 Jan, 2017 1 commit
  6. 11 Nov, 2016 1 commit
  7. 11 Oct, 2016 1 commit
  8. 27 May, 2016 1 commit
    • Stephen Rothwell's avatar
      mm/cma: silence warnings due to max() usage · badbda53
      Stephen Rothwell authored
      pageblock_order can be (at least) an unsigned int or an unsigned long
      depending on the kernel config and architecture, so use max_t(unsigned
      long, ...) when comparing it.
      
      fixes these warnings:
      
      In file included from include/asm-generic/bug.h:13:0,
                       from arch/powerpc/include/asm/bug.h:127,
                       from include/linux/bug.h:4,
                       from include/linux/mmdebug.h:4,
                       from include/linux/mm.h:8,
                       from include/linux/memblock.h:18,
                       from mm/cma.c:28:
      mm/cma.c: In function 'cma_init_reserved_mem':
      include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
        (void) (&_max1 == &_max2);                   ^
      mm/cma.c:186:27: note: in expansion of macro 'max'
        alignment = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
                                 ^
      mm/cma.c: In function 'cma_declare_contiguous':
      include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
        (void) (&_max1 == &_max2);                   ^
      include/linux/kernel.h:747:9: note: in definition of macro 'max'
        typeof(y) _max2 = (y);            ^
      mm/cma.c:270:29: note: in expansion of macro 'max'
         (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
                                   ^
      include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
        (void) (&_max1 == &_max2);                   ^
      include/linux/kernel.h:747:21: note: in definition of macro 'max'
        typeof(y) _max2 = (y);                        ^
      mm/cma.c:270:29: note: in expansion of macro 'max'
         (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
                                   ^
      
      [akpm@linux-foundation.org: coding-style fixes]
      Link: http://lkml.kernel.org/r/20160526150748.5be38a4f@canb.auug.org.auSigned-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      badbda53
  9. 06 Nov, 2015 1 commit
    • Andrew Morton's avatar
      mm/cma.c: suppress warning · 3acaea68
      Andrew Morton authored
      mm/cma.c: In function 'cma_alloc':
      mm/cma.c:366: warning: 'pfn' may be used uninitialized in this function
      
      The patch actually improves the tracing a bit: if alloc_contig_range()
      fails, tracing will display the offending pfn rather than -1.
      
      Cc: Stefan Strogin <stefan.strogin@gmail.com>
      Cc: Michal Nazarewicz <mpn@google.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3acaea68
  10. 23 Oct, 2015 1 commit
  11. 25 Jun, 2015 2 commits
    • Tony Luck's avatar
      mm/memblock: add extra "flags" to memblock to allow selection of memory based on attribute · fc6daaf9
      Tony Luck authored
      Some high end Intel Xeon systems report uncorrectable memory errors as a
      recoverable machine check.  Linux has included code for some time to
      process these and just signal the affected processes (or even recover
      completely if the error was in a read only page that can be replaced by
      reading from disk).
      
      But we have no recovery path for errors encountered during kernel code
      execution.  Except for some very specific cases were are unlikely to ever
      be able to recover.
      
      Enter memory mirroring. Actually 3rd generation of memory mirroing.
      
      Gen1: All memory is mirrored
      	Pro: No s/w enabling - h/w just gets good data from other side of the
      	     mirror
      	Con: Halves effective memory capacity available to OS/applications
      
      Gen2: Partial memory mirror - just mirror memory begind some memory controllers
      	Pro: Keep more of the capacity
      	Con: Nightmare to enable. Have to choose between allocating from
      	     mirrored memory for safety vs. NUMA local memory for performance
      
      Gen3: Address range partial memory mirror - some mirror on each memory
            controller
      	Pro: Can tune the amount of mirror and keep NUMA performance
      	Con: I have to write memory management code to implement
      
      The current plan is just to use mirrored memory for kernel allocations.
      This has been broken into two phases:
      
      1) This patch series - find the mirrored memory, use it for boot time
         allocations
      
      2) Wade into mm/page_alloc.c and define a ZONE_MIRROR to pick up the
         unused mirrored memory from mm/memblock.c and only give it out to
         select kernel allocations (this is still being scoped because
         page_alloc.c is scary).
      
      This patch (of 3):
      
      Add extra "flags" to memblock to allow selection of memory based on
      attribute.  No functional changes
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Xiexiuqi <xiexiuqi@huawei.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fc6daaf9
    • Shailendra Verma's avatar
  12. 15 Apr, 2015 1 commit
  13. 14 Apr, 2015 3 commits
  14. 13 Mar, 2015 1 commit
    • Danesh Petigara's avatar
      mm: cma: fix CMA aligned offset calculation · 850fc430
      Danesh Petigara authored
      The CMA aligned offset calculation is incorrect for non-zero order_per_bit
      values.
      
      For example, if cma->order_per_bit=1, cma->base_pfn= 0x2f800000 and
      align_order=12, the function returns a value of 0x17c00 instead of 0x400.
      
      This patch fixes the CMA aligned offset calculation.
      
      The previous calculation was wrong and would return too-large values for
      the offset, so that when cma_alloc looks for free pages in the bitmap with
      the requested alignment > order_per_bit, it starts too far into the bitmap
      and so CMA allocations will fail despite there actually being plenty of
      free pages remaining.  It will also probably have the wrong alignment.
      With this change, we will get the correct offset into the bitmap.
      
      One affected user is powerpc KVM, which has kvm_cma->order_per_bit set to
      KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, or 18 - 12 = 6.
      
      [gregory.0xf0@gmail.com: changelog additions]
      Signed-off-by: default avatarDanesh Petigara <dpetigara@broadcom.com>
      Reviewed-by: default avatarGregory Fong <gregory.0xf0@gmail.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      850fc430
  15. 12 Feb, 2015 1 commit
  16. 19 Dec, 2014 1 commit
    • Pintu Kumar's avatar
      mm: cma: split cma-reserved in dmesg log · e48322ab
      Pintu Kumar authored
      When the system boots up, in the dmesg logs we can see the memory
      statistics along with total reserved as below.  Memory: 458840k/458840k
      available, 65448k reserved, 0K highmem
      
      When CMA is enabled, still the total reserved memory remains the same.
      However, the CMA memory is not considered as reserved.  But, when we see
      /proc/meminfo, the CMA memory is part of free memory.  This creates
      confusion.  This patch corrects the problem by properly subtracting the
      CMA reserved memory from the total reserved memory in dmesg logs.
      
      Below is the dmesg snapshot from an arm based device with 512MB RAM and
      12MB single CMA region.
      
      Before this change:
        Memory: 458840k/458840k available, 65448k reserved, 0K highmem
      
      After this change:
        Memory: 458840k/458840k available, 53160k reserved, 12288k cma-reserved, 0K highmem
      Signed-off-by: default avatarPintu Kumar <pintu.k@samsung.com>
      Signed-off-by: default avatarVishnu Pratap Singh <vishnu.ps@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Cc: Rafael Aquini <aquini@redhat.com>
      Cc: Jerome Marchand <jmarchan@redhat.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e48322ab
  17. 13 Dec, 2014 2 commits
    • Thierry Reding's avatar
      mm/cma: make kmemleak ignore CMA regions · 620951e2
      Thierry Reding authored
      kmemleak will add allocations as objects to a pool.  The memory allocated
      for each object in this pool is periodically searched for pointers to
      other allocated objects.  This only works for memory that is mapped into
      the kernel's virtual address space, which happens not to be the case for
      most CMA regions.
      
      Furthermore, CMA regions are typically used to store data transferred to
      or from a device and therefore don't contain pointers to other objects.
      
      Without this, the kernel crashes on the first execution of the
      scan_gray_list() because it tries to access highmem.  Perhaps a more
      appropriate fix would be to reject any object that can't map to a kernel
      virtual address?
      
      [akpm@linux-foundation.org: add comment]
      [akpm@linux-foundation.org: fix comment, per Catalin]
      [sfr@canb.auug.org.au: include linux/io.h for phys_to_virt()]
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      620951e2
    • Gregory Fong's avatar
      mm: cma: align to physical address, not CMA region position · b5be83e3
      Gregory Fong authored
      The alignment in cma_alloc() was done w.r.t. the bitmap.  This is a
      problem when, for example:
      
      - a device requires 16M (order 12) alignment
      - the CMA region is not 16 M aligned
      
      In such a case, can result with the CMA region starting at, say,
      0x2f800000 but any allocation you make from there will be aligned from
      there.  Requesting an allocation of 32 M with 16 M alignment will result
      in an allocation from 0x2f800000 to 0x31800000, which doesn't work very
      well if your strange device requires 16M alignment.
      
      Change to use bitmap_find_next_zero_area_off() to account for the
      difference in alignment at reserve-time and alloc-time.
      Signed-off-by: default avatarGregory Fong <gregory.0xf0@gmail.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Laura Abbott <lauraa@codeaurora.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b5be83e3
  18. 11 Dec, 2014 1 commit
    • Joonsoo Kim's avatar
      mm/CMA: fix boot regression due to physical address of high_memory · 6b101e2a
      Joonsoo Kim authored
      high_memory isn't direct mapped memory so retrieving it's physical address
      isn't appropriate.  But, it would be useful to check physical address of
      highmem boundary so it's justfiable to get physical address from it.  In
      x86, there is a validation check if CONFIG_DEBUG_VIRTUAL and it triggers
      following boot failure reported by Ingo.
      
        ...
        BUG: Int 6: CR2 00f06f53
        ...
        Call Trace:
          dump_stack+0x41/0x52
          early_idt_handler+0x6b/0x6b
          cma_declare_contiguous+0x33/0x212
          dma_contiguous_reserve_area+0x31/0x4e
          dma_contiguous_reserve+0x11d/0x125
          setup_arch+0x7b5/0xb63
          start_kernel+0xb8/0x3e6
          i386_start_kernel+0x79/0x7d
      
      To fix boot regression, this patch implements workaround to avoid
      validation check in x86 when retrieving physical address of high_memory.
      __pa_nodebug() used by this patch is implemented only in x86 so there is
      no choice but to use dirty #ifdef.
      
      [akpm@linux-foundation.org: tweak comment]
      Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Tested-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6b101e2a
  19. 27 Oct, 2014 4 commits
  20. 14 Oct, 2014 2 commits
  21. 10 Oct, 2014 1 commit
    • Marek Szyprowski's avatar
      mm: cma: adjust address limit to avoid hitting low/high memory boundary · f7426b98
      Marek Szyprowski authored
      Russell King recently noticed that limiting default CMA region only to low
      memory on ARM architecture causes serious memory management issues with
      machines having a lot of memory (which is mainly available as high
      memory).  More information can be found the following thread:
      http://thread.gmane.org/gmane.linux.ports.arm.kernel/348441/
      
      Those two patches removes this limit letting kernel to put default CMA
      region into high memory when this is possible (there is enough high memory
      available and architecture specific DMA limit fits).
      
      This should solve strange OOM issues on systems with lots of RAM (i.e.
      >1GiB) and large (>256M) CMA area.
      
      This patch (of 2):
      
      Automatically allocated regions should not cross low/high memory boundary,
      because such regions cannot be later correctly initialized due to spanning
      across two memory zones.  This patch adds a check for this case and a
      simple code for moving region to low memory if automatically selected
      address might not fit completely into high memory.
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Cc: Daniel Drake <drake@endlessm.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f7426b98
  22. 07 Aug, 2014 7 commits