From: kernel test robot <lkp@intel.com>
To: kernel@openeuler.org, Wupeng Ma <mawupeng1@huawei.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [openeuler:OLK-6.6 2392/2894] mm/memblock.c:1409:20: sparse: sparse: symbol 'memblock_alloc_range_nid_flags' was not declared. Should it be static?
Date: Thu, 1 Feb 2024 01:31:30 +0800 [thread overview]
Message-ID: <202402010125.UTtd3edB-lkp@intel.com> (raw)
tree: https://gitee.com/openeuler/kernel.git OLK-6.6
head: f6f9abf1a5ef2fc559630c77b3570346dcd19d40
commit: 64018b291c1f49622c4b23b303364d760306d662 [2392/2894] mm/memblock: Introduce ability to alloc memory from specify memory region
config: x86_64-randconfig-123-20240131 (https://download.01.org/0day-ci/archive/20240201/202402010125.UTtd3edB-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240201/202402010125.UTtd3edB-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202402010125.UTtd3edB-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> mm/memblock.c:1409:20: sparse: sparse: symbol 'memblock_alloc_range_nid_flags' was not declared. Should it be static?
vim +/memblock_alloc_range_nid_flags +1409 mm/memblock.c
1386
1387 /**
1388 * memblock_alloc_range_nid_flags - allocate boot memory block with specify flag
1389 * @size: size of memory block to be allocated in bytes
1390 * @align: alignment of the region and block's size
1391 * @start: the lower bound of the memory region to allocate (phys address)
1392 * @end: the upper bound of the memory region to allocate (phys address)
1393 * @nid: nid of the free area to find, %NUMA_NO_NODE for any node
1394 * @exact_nid: control the allocation fall back to other nodes
1395 * @flags: alloc memory from specify memblock flag
1396 *
1397 * The allocation is performed from memory region limited by
1398 * memblock.current_limit if @end == %MEMBLOCK_ALLOC_ACCESSIBLE.
1399 *
1400 * If the specified node can not hold the requested memory and @exact_nid
1401 * is false, the allocation falls back to any node in the system.
1402 *
1403 * In addition, function sets the min_count to 0 using kmemleak_alloc_phys for
1404 * allocated boot memory block, so that it is never reported as leaks.
1405 *
1406 * Return:
1407 * Physical address of allocated memory block on success, %0 on failure.
1408 */
> 1409 phys_addr_t __init memblock_alloc_range_nid_flags(phys_addr_t size,
1410 phys_addr_t align, phys_addr_t start,
1411 phys_addr_t end, int nid,
1412 bool exact_nid,
1413 enum memblock_flags flags)
1414 {
1415 phys_addr_t found;
1416
1417 if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
1418 nid = NUMA_NO_NODE;
1419
1420 if (!align) {
1421 /* Can't use WARNs this early in boot on powerpc */
1422 dump_stack();
1423 align = SMP_CACHE_BYTES;
1424 }
1425
1426 again:
1427 found = memblock_find_in_range_node(size, align, start, end, nid,
1428 flags);
1429 if (found && !memblock_reserve(found, size))
1430 goto done;
1431
1432 if (nid != NUMA_NO_NODE && !exact_nid) {
1433 found = memblock_find_in_range_node(size, align, start,
1434 end, NUMA_NO_NODE,
1435 flags);
1436 if (found && !memblock_reserve(found, size))
1437 goto done;
1438 }
1439
1440 if (flags & MEMBLOCK_MIRROR) {
1441 flags &= ~MEMBLOCK_MIRROR;
1442 pr_warn_ratelimited("Could not allocate %pap bytes of mirrored memory\n",
1443 &size);
1444 goto again;
1445 }
1446
1447 return 0;
1448
1449 done:
1450 /*
1451 * Skip kmemleak for those places like kasan_init() and
1452 * early_pgtable_alloc() due to high volume.
1453 */
1454 if (end != MEMBLOCK_ALLOC_NOLEAKTRACE)
1455 /*
1456 * Memblock allocated blocks are never reported as
1457 * leaks. This is because many of these blocks are
1458 * only referred via the physical address which is
1459 * not looked up by kmemleak.
1460 */
1461 kmemleak_alloc_phys(found, size, 0);
1462
1463 /*
1464 * Some Virtual Machine platforms, such as Intel TDX or AMD SEV-SNP,
1465 * require memory to be accepted before it can be used by the
1466 * guest.
1467 *
1468 * Accept the memory of the allocated buffer.
1469 */
1470 accept_memory(found, found + size);
1471
1472 return found;
1473 }
1474
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2024-01-31 17:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202402010125.UTtd3edB-lkp@intel.com \
--to=lkp@intel.com \
--cc=kernel@openeuler.org \
--cc=mawupeng1@huawei.com \
--cc=oe-kbuild-all@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.