linux-toradex.git/drivers/of/of_reserved_mem.c, branch v6.3-rc3

Merge tag 'devicetree-for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2023-02-24T21:31:53+00:00

Pull devicetree updates from Rob Herring:
 "DT core:

   - Add node lifecycle unit tests

   - Add of_property_present() helper aligned with fwnode API

   - Print more information on reserved regions on boot

   - Update dtc to upstream v1.6.1-66-gabbd523bae6e

   - Use strscpy() to instead of strncpy() in DT core

   - Add option for schema validation on %.dtb targets

  Bindings:

   - Add/fix support for listing multiple patterns in DT_SCHEMA_FILES

   - Rework external memory controller/bus bindings to properly support
     controller specific child node properties

   - Convert loongson,ls1x-intc, fcs,fusb302, sil,sii8620, Rockchip
     RK3399 PCIe, Synquacer I2C, and Synquacer EXIU bindings to DT
     schema format

   - Add RiscV SBI PMU event mapping binding

   - Add missing contraints on Arm SCMI child node allowed properties

   - Add a bunch of missing Socionext UniPhier glue block bindings and
     example fixes

   - Various fixes for duplicate or conflicting type definitions on DT
     properties"

* tag 'devicetree-for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (66 commits)
  dt-bindings: regulator: Add mps,mpq7932 power-management IC
  of: dynamic: Fix spelling mistake "kojbect" -> "kobject"
  dt-bindings: drop Sagar Kadam from SiFive binding maintainership
  dt-bindings: sram: qcom,imem: document sm8450
  dt-bindings: interrupt-controller: convert loongson,ls1x-intc.txt to json-schema
  dt-bindings: arm: Add Cortex-A715 and X3
  of: dynamic: add lifecycle docbook info to node creation functions
  of: add consistency check to of_node_release()
  of: do not use "%pOF" printk format on node with refcount of zero
  of: unittest: add node lifecycle tests
  of: update kconfig unittest help
  of: add processing of EXPECT_NOT to of_unittest_expect
  of: prepare to add processing of EXPECT_NOT to of_unittest_expect
  of: Use preferred of_property_read_* functions
  of: Use of_property_present() helper
  of: Add of_property_present() helper
  of: reserved_mem: Use proper binary prefix
  dt-bindings: Fix multi pattern support in DT_SCHEMA_FILES
  of: reserved-mem: print out reserved-mem details during boot
  dt-bindings: serial: restrict possible child node names
  ...

of: reserved_mem: Use proper binary prefix

2023-02-17T21:21:36+00:00

The printed reserved memory information uses the non-standard "K"
prefix, while all other printed values use proper binary prefixes.
Fix this by using "Ki" instead.

While at it, drop the superfluous spaces inside the parentheses, to
reduce printed line length.

Fixes: aeb9267eb6b1df99 ("of: reserved-mem: print out reserved-mem details during boot")
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20230216083725.1244817-1-geert+renesas@glider.be
Signed-off-by: Rob Herring

of: reserved-mem: print out reserved-mem details during boot

2023-02-15T21:07:42+00:00

It's important to know reserved-mem information in mobile world
since reserved memory via device tree keeps increased in platform
(e.g., 45% in our platform). Therefore, it's crucial to know the
reserved memory sizes breakdown for the memory accounting.

This patch prints out reserved memory details during boot to make
them visible.

Below is an example output:

[    0.000000] OF: reserved mem: 0x00000009f9400000..0x00000009fb3fffff ( 32768 KB ) map reusable test1
[    0.000000] OF: reserved mem: 0x00000000ffdf0000..0x00000000ffffffff ( 2112 KB ) map non-reusable test2
[    0.000000] OF: reserved mem: 0x0000000091000000..0x00000000912fffff ( 3072 KB ) nomap non-reusable test3

Signed-off-by: Martin Liu 
Link: https://lore.kernel.org/r/20230209160954.1471909-1-liumartin@google.com
Signed-off-by: Rob Herring

of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem

2023-02-09T23:56:51+00:00

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: a7259df76702 ("memblock: make memblock_find_in_range method private")
Signed-off-by: Isaac J. Manjarres 
Acked-by: Mike Rapoport (IBM) 
Acked-by: Catalin Marinas 
Cc: Frank Rowand 
Cc: Kirill A. Shutemov 
Cc: Nick Kossifidis 
Cc: Rafael J. Wysocki 
Cc: Rob Herring 
Cc: Russell King (Oracle) 
Cc: Saravana Kannan 
Cc: 	[5.15+]
Signed-off-by: Andrew Morton

of: reserved-memory: Print allocation/reservation failures as error

2022-06-28T20:15:36+00:00

If the allocation/reservation of reserved-memory fails, it is normally
an error, so print it as an error so that it doesn't get hidden from the
console due to the loglevel.  Also make the allocation failure include
the size just like the reservation failure.

Signed-off-by: Vincent Whitchurch 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220628113540.2790835-1-vincent.whitchurch@axis.com

cma: factor out minimum alignment requirement

2022-03-22T22:57:05+00:00

Patch series "mm: enforce pageblock_order < MAX_ORDER".

Having pageblock_order >= MAX_ORDER seems to be able to happen in corner
cases and some parts of the kernel are not prepared for it.

For example, Aneesh has shown [1] that such kernels can be compiled on
ppc64 with 64k base pages by setting FORCE_MAX_ZONEORDER=8, which will
run into a WARN_ON_ONCE(order >= MAX_ORDER) in comapction code right
during boot.

We can get pageblock_order >= MAX_ORDER when the default hugetlb size is
bigger than the maximum allocation granularity of the buddy, in which
case we are no longer talking about huge pages but instead gigantic
pages.

Having pageblock_order >= MAX_ORDER can only make alloc_contig_range()
of such gigantic pages more likely to succeed.

Reliable use of gigantic pages either requires boot time allcoation or
CMA, no need to overcomplicate some places in the kernel to optimize for
corner cases that are broken in other areas of the kernel.

This patch (of 2):

Let's enforce pageblock_order < MAX_ORDER and simplify.

Especially patch #1 can be regarded a cleanup before:
	[PATCH v5 0/6] Use pageblock_order for cma and alloc_contig_range
	alignment. [2]

[1] https://lkml.kernel.org/r/87r189a2ks.fsf@linux.ibm.com
[2] https://lkml.kernel.org/r/20220211164135.1803616-1-zi.yan@sent.com

Link: https://lkml.kernel.org/r/20220214174132.219303-2-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Zi Yan 
Acked-by: Rob Herring 
Cc: Aneesh Kumar K.V 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Frank Rowand 
Cc: Michael S. Tsirkin 
Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Minchan Kim 
Cc: Vlastimil Babka 
Cc: John Garry via iommu 

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: rename memblock_free to memblock_phys_free

2021-11-06T20:30:41+00:00

Since memblock_free() operates on a physical range, make its name
reflect it and rename it to memblock_phys_free(), so it will be a
logical counterpart to memblock_phys_alloc().

The callers are updated with the below semantic patch:

    @@
    expression addr;
    expression size;
    @@
    - memblock_free(addr, size);
    + memblock_phys_free(addr, size);

Link: https://lkml.kernel.org/r/20210930185031.18648-6-rppt@kernel.org
Signed-off-by: Mike Rapoport 
Cc: Christophe Leroy 
Cc: Juergen Gross 
Cc: Shahab Vahedi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: exclude MEMBLOCK_NOMAP regions from kmemleak

2021-10-22T04:30:49+00:00

Vladimir Zapolskiy reports:

Commit a7259df76702 ("memblock: make memblock_find_in_range method
private") invokes a kernel panic while running kmemleak on OF platforms
with nomaped regions:

  Unable to handle kernel paging request at virtual address fff000021e00000
  [...]
    scan_block+0x64/0x170
    scan_gray_list+0xe8/0x17c
    kmemleak_scan+0x270/0x514
    kmemleak_write+0x34c/0x4ac

The memory allocated from memblock is registered with kmemleak, but if
it is marked MEMBLOCK_NOMAP it won't have linear map entries so an
attempt to scan such areas will fault.

Ideally, memblock_mark_nomap() would inform kmemleak to ignore
MEMBLOCK_NOMAP memory, but it can be called before kmemleak interfaces
operating on physical addresses can use __va() conversion.

Make sure that functions that mark allocated memory as MEMBLOCK_NOMAP
take care of informing kmemleak to ignore such memory.

Link: https://lore.kernel.org/all/8ade5174-b143-d621-8c8e-dc6a1898c6fb@linaro.org
Link: https://lore.kernel.org/all/c30ff0a2-d196-c50d-22f0-bd50696b1205@quicinc.com
Fixes: a7259df76702 ("memblock: make memblock_find_in_range method private")
Reported-by: Vladimir Zapolskiy 
Signed-off-by: Mike Rapoport 
Reviewed-by: Catalin Marinas 
Tested-by: Vladimir Zapolskiy 
Tested-by: Qian Cai 
Signed-off-by: Linus Torvalds

memblock: make memblock_find_in_range method private

2021-09-03T16:58:17+00:00

There are a lot of uses of memblock_find_in_range() along with
memblock_reserve() from the times memblock allocation APIs did not exist.

memblock_find_in_range() is the very core of memblock allocations, so any
future changes to its internal behaviour would mandate updates of all the
users outside memblock.

Replace the calls to memblock_find_in_range() with an equivalent calls to
memblock_phys_alloc() and memblock_phys_alloc_range() and make
memblock_find_in_range() private method of memblock.

This simplifies the callers, ensures that (unlikely) errors in
memblock_reserve() are handled and improves maintainability of
memblock_find_in_range().

Link: https://lkml.kernel.org/r/20210816122622.30279-1-rppt@kernel.org
Signed-off-by: Mike Rapoport 
Reviewed-by: Catalin Marinas 		[arm64]
Acked-by: Kirill A. Shutemov 
Acked-by: Rafael J. Wysocki 	[ACPI]
Acked-by: Russell King (Oracle) 
Acked-by: Nick Kossifidis 			[riscv]
Tested-by: Guenter Roeck 
Acked-by: Rob Herring 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

of: of_reserved_mem: mark nomap memory instead of removing

2021-06-24T19:47:26+00:00

Since commit 86588296acbf ("fdt: Properly handle "no-map" field in the memory region"),
nomap memory is changed to call memblock_mark_nomap() instead of
memblock_remove(). But it only changed the reserved memory with fixed
addr and size case in early_init_dt_reserve_memory_arch(), not
including the dynamical allocation by size case in
early_init_dt_alloc_reserved_memory_arch().

Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Signed-off-by: Dong Aisheng 
Reviewed-by: Quentin Perret 
Link: https://lore.kernel.org/r/20210611131153.3731147-2-aisheng.dong@nxp.com
Signed-off-by: Rob Herring