linux-kernel - Re: [PATCH v5 02/27] mm, cma: support multiple contiguous ranges, if requested

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdVWviQ7O9yBFE3f=ev0eVb1CnsQvR6SKtEROBbM6z7g3w@mail.gmail.com>
Date: Mon, 7 Apr 2025 13:50:08 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Frank van der Linden <fvdl@...gle.com>
Cc: akpm@...ux-foundation.org, muchun.song@...ux.dev, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, yuzhao@...gle.com, usamaarif642@...il.com, 
	joao.m.martins@...cle.com, roman.gushchin@...ux.dev, ziy@...dia.com, 
	david@...hat.com, Arnd Bergmann <arnd@...db.de>, 
	Linux-Renesas <linux-renesas-soc@...r.kernel.org>, 
	Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 02/27] mm, cma: support multiple contiguous ranges, if requested

Hi Frank,

On Fri, 28 Feb 2025 at 19:30, Frank van der Linden <fvdl@...gle.com> wrote:
> Currently, CMA manages one range of physically contiguous memory.
> Creation of larger CMA areas with hugetlb_cma may run in to gaps
> in physical memory, so that they are not able to allocate that
> contiguous physical range from memblock when creating the CMA
> area.
>
> This can happen, for example, on an AMD system with > 1TB of memory,
> where there will be a gap just below the 1TB (40bit DMA) line. If
> you have set aside most of memory for potential hugetlb CMA allocation,
> cma_declare_contiguous_nid will fail.
>
> hugetlb_cma doesn't need the entire area to be one physically
> contiguous range. It just cares about being able to get physically
> contiguous chunks of a certain size (e.g. 1G), and it is fine
> to have the CMA area backed by multiple physical ranges, as
> long as it gets 1G contiguous allocations.
>
> Multi-range support is implemented by introducing an array of
> ranges, instead of just one big one. Each range has its own bitmap.
> Effectively, the allocate and release operations work as before,
> just per-range. So, instead of going through one large bitmap, they
> now go through a number of smaller ones.
>
> The maximum number of supported ranges is 8, as defined in
> CMA_MAX_RANGES.
>
> Since some current users of CMA expect a CMA area to just use one
> physically contiguous range, only allow for multiple ranges if a
> new interface, cma_declare_contiguous_nid_multi, is used. The other
> interfaces will work like before, creating only CMA areas with
> 1 range.
>
> cma_declare_contiguous_nid_multi works as follows, mimicking the
> default "bottom-up, above 4G" reservation approach:
>
> 0) Try cma_declare_contiguous_nid, which will use only one
>    region. If this succeeds, return. This makes sure that for
>    all the cases that currently work, the behavior remains
>    unchanged even if the caller switches from
>    cma_declare_contiguous_nid to cma_declare_contiguous_nid_multi.
> 1) Select the largest free memblock ranges above 4G, with
>    a maximum number of CMA_MAX_RANGES.
> 2) If we did not find at most CMA_MAX_RANGES that add
>    up to the total size requested, return -ENOMEM.
> 3) Sort the selected ranges by base address.
> 4) Reserve them bottom-up until we get what we wanted.
>
> Cc: Arnd Bergmann <arnd@...db.de>
> Signed-off-by: Frank van der Linden <fvdl@...gle.com>

Thanks for your patch, which is now commit c009da4258f9885c
("mm, cma: support multiple contiguous ranges, if requested")
in v6.15-rc1.

After this patch, the printed base address becomes zero on several
Renesas arm32/arm64 platforms:

  - Koelsch (R-Car M2-W):

      -cma: Reserved 64 MiB at 0x7c000000 on node -1
      +cma: Reserved 64 MiB at 0x00000000

   - Salvator-XS (R-Car H3 ES2.0):

      -cma: Reserved 128 MiB at 0x0000000078000000 on node -1
      +cma: Reserved 128 MiB at 0x0000000000000000

  - Gray Hawk Single (R-Car V4H):

      -cma: Reserved 128 MiB at 0x00000000b8000000 on node -1
      +cma: Reserved 128 MiB at 0x0000000000000000

None of these have actual RAM at address zero.  As I haven't noticed
any other impact on system operation, I do not know if this is purely
a cosmetic issue, or if it can cause real problems.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds