All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: oe-kbuild-all@lists.linux.dev
Subject: [davidhildenbrand:hotplug_vmemmap 14/14] mm/sparse-vmemmap.c:756:31: warning: unused variable 'section_nr'
Date: Sun, 08 Mar 2026 18:31:45 +0800	[thread overview]
Message-ID: <202603081805.ulEmbVAI-lkp@intel.com> (raw)

tree:   https://github.com/davidhildenbrand/linux hotplug_vmemmap
head:   58d0ede3533299d5c6ec069fd491a115558f7c6c
commit: 58d0ede3533299d5c6ec069fd491a115558f7c6c [14/14] mm/sparse: move memory hotplug bits to sparse-vmemmap.c
config: s390-randconfig-001-20260308 (https://download.01.org/0day-ci/archive/20260308/202603081805.ulEmbVAI-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 12.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260308/202603081805.ulEmbVAI-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/202603081805.ulEmbVAI-lkp@intel.com/

All warnings (new ones prefixed by >>):

   mm/sparse-vmemmap.c: In function 'section_deactivate':
>> mm/sparse-vmemmap.c:756:31: warning: unused variable 'section_nr' [-Wunused-variable]
     756 |                 unsigned long section_nr = pfn_to_section_nr(pfn);
         |                               ^~~~~~~~~~


vim +/section_nr +756 mm/sparse-vmemmap.c

   726	
   727	/*
   728	 * To deactivate a memory region, there are 3 cases to handle across
   729	 * two configurations (SPARSEMEM_VMEMMAP={y,n}):
   730	 *
   731	 * 1. deactivation of a partial hot-added section (only possible in
   732	 *    the SPARSEMEM_VMEMMAP=y case).
   733	 *      a) section was present at memory init.
   734	 *      b) section was hot-added post memory init.
   735	 * 2. deactivation of a complete hot-added section.
   736	 * 3. deactivation of a complete section from memory init.
   737	 *
   738	 * For 1, when subsection_map does not empty we will not be freeing the
   739	 * usage map, but still need to free the vmemmap range.
   740	 *
   741	 * For 2 and 3, the SPARSEMEM_VMEMMAP={y,n} cases are unified
   742	 */
   743	static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
   744			struct vmem_altmap *altmap)
   745	{
   746		struct mem_section *ms = __pfn_to_section(pfn);
   747		bool section_is_early = early_section(ms);
   748		struct page *memmap = NULL;
   749		bool empty;
   750	
   751		if (clear_subsection_map(pfn, nr_pages))
   752			return;
   753	
   754		empty = is_subsection_map_empty(ms);
   755		if (empty) {
 > 756			unsigned long section_nr = pfn_to_section_nr(pfn);
   757	
   758			/*
   759			 * Mark the section invalid so that valid_section()
   760			 * return false. This prevents code from dereferencing
   761			 * ms->usage array.
   762			 */
   763			ms->section_mem_map &= ~SECTION_HAS_MEM_MAP;
   764	
   765			/*
   766			 * When removing an early section, the usage map is kept (as the
   767			 * usage maps of other sections fall into the same page). It
   768			 * will be re-used when re-adding the section - which is then no
   769			 * longer an early section. If the usage map is PageReserved, it
   770			 * was allocated during boot.
   771			 */
   772			if (!PageReserved(virt_to_page(ms->usage))) {
   773				kfree_rcu(ms->usage, rcu);
   774				WRITE_ONCE(ms->usage, NULL);
   775			}
   776			memmap = pfn_to_page(SECTION_ALIGN_DOWN(pfn));
   777		}
   778	
   779		/*
   780		 * The memmap of early sections is always fully populated. See
   781		 * section_activate() and pfn_valid() .
   782		 */
   783		if (!section_is_early) {
   784			memmap_pages_add(-1L * (DIV_ROUND_UP(nr_pages * sizeof(struct page), PAGE_SIZE)));
   785			depopulate_section_memmap(pfn, nr_pages, altmap);
   786		} else if (memmap) {
   787			memmap_boot_pages_add(-1L * (DIV_ROUND_UP(nr_pages * sizeof(struct page),
   788								  PAGE_SIZE)));
   789			free_map_bootmem(memmap);
   790		}
   791	
   792		if (empty)
   793			ms->section_mem_map = (unsigned long)NULL;
   794	}
   795	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

                 reply	other threads:[~2026-03-08 10:32 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=202603081805.ulEmbVAI-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=david@kernel.org \
    --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.