public inbox for [email protected]
 help / color / mirror / Atom feed
From: kernel test robot <[email protected]>
To: Mike Kravetz <[email protected]>
Cc: [email protected], [email protected],
	Ammar Faizi <[email protected]>,
	GNU/Weeb Mailing List <[email protected]>,
	[email protected],
	Andrew Morton <[email protected]>,
	Linux Memory Management List <[email protected]>
Subject: [ammarfaizi2-block:akpm/mm/mm-unstable 272/276] fs/hugetlbfs/inode.c:562:16: warning: variable 'm_index' is uninitialized when used here
Date: Thu, 25 Aug 2022 10:26:28 +0800	[thread overview]
Message-ID: <[email protected]> (raw)

tree:   https://github.com/ammarfaizi2/linux-block akpm/mm/mm-unstable
head:   73129b786c0eca5be67491a5e893e13b75133a62
commit: fcc0d3d00d74b012c36d52128687ab9d197d3f0d [272/276] hugetlb: handle truncate racing with page faults
config: arm64-randconfig-r014-20220823 (https://download.01.org/0day-ci/archive/20220825/[email protected]/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project d00e97df0fe8c67f694c4d027297f4382ce72b38)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://github.com/ammarfaizi2/linux-block/commit/fcc0d3d00d74b012c36d52128687ab9d197d3f0d
        git remote add ammarfaizi2-block https://github.com/ammarfaizi2/linux-block
        git fetch --no-tags ammarfaizi2-block akpm/mm/mm-unstable
        git checkout fcc0d3d00d74b012c36d52128687ab9d197d3f0d
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm64 SHELL=/bin/bash fs/hugetlbfs/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <[email protected]>

All warnings (new ones prefixed by >>):

>> fs/hugetlbfs/inode.c:562:16: warning: variable 'm_index' is uninitialized when used here [-Wuninitialized]
                                                   m_start, m_index, truncate_op);
                                                            ^~~~~~~
   fs/hugetlbfs/inode.c:540:26: note: initialize the variable 'm_index' to silence this warning
           pgoff_t m_start, m_index;
                                   ^
                                    = 0
   1 warning generated.


vim +/m_index +562 fs/hugetlbfs/inode.c

   502	
   503	/*
   504	 * remove_inode_hugepages handles two distinct cases: truncation and hole
   505	 * punch.  There are subtle differences in operation for each case.
   506	 *
   507	 * truncation is indicated by end of range being LLONG_MAX
   508	 *	In this case, we first scan the range and release found pages.
   509	 *	After releasing pages, hugetlb_unreserve_pages cleans up region/reserve
   510	 *	maps and global counts.  Page faults can race with truncation.
   511	 *	During faults, hugetlb_no_page() checks i_size before page allocation,
   512	 *	and again after	obtaining page table lock.  It will 'back out'
   513	 *	allocations in the truncated range.
   514	 * hole punch is indicated if end is not LLONG_MAX
   515	 *	In the hole punch case we scan the range and release found pages.
   516	 *	Only when releasing a page is the associated region/reserve map
   517	 *	deleted.  The region/reserve map for ranges without associated
   518	 *	pages are not modified.  Page faults can race with hole punch.
   519	 *	This is indicated if we find a mapped page.
   520	 * Note: If the passed end of range value is beyond the end of file, but
   521	 * not LLONG_MAX this routine still performs a hole punch operation.
   522	 *
   523	 * Since page faults can race with this routine, care must be taken as both
   524	 * modify huge page reservation data.  To somewhat synchronize these operations
   525	 * the hugetlb fault mutex is taken for EVERY index in the range to be hole
   526	 * punched or truncated.  In this way, we KNOW either:
   527	 * - fault code has added a page beyond i_size, and we will remove here
   528	 * - fault code will see updated i_size and not add a page beyond
   529	 * The parameter 'lm__end' indicates the offset of the end of hole or file
   530	 * before truncation.  For hole punch lm_end == lend.
   531	 */
   532	static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
   533					   loff_t lend, loff_t lm_end)
   534	{
   535		struct hstate *h = hstate_inode(inode);
   536		struct address_space *mapping = &inode->i_data;
   537		const pgoff_t start = lstart >> huge_page_shift(h);
   538		const pgoff_t end = lend >> huge_page_shift(h);
   539		pgoff_t m_end = lm_end >> huge_page_shift(h);
   540		pgoff_t m_start, m_index;
   541		struct folio_batch fbatch;
   542		struct folio *folio;
   543		pgoff_t next, index;
   544		unsigned int i;
   545		long freed = 0;
   546		u32 hash;
   547		bool truncate_op = (lend == LLONG_MAX);
   548	
   549		folio_batch_init(&fbatch);
   550		next = m_start = start;
   551		while (filemap_get_folios(mapping, &next, end - 1, &fbatch)) {
   552			for (i = 0; i < folio_batch_count(&fbatch); ++i) {
   553				folio = fbatch.folios[i];
   554	
   555				index = folio->index;
   556				/*
   557				 * Take fault mutex for missing folios before index,
   558				 * while checking folios that might have been added
   559				 * due to a race with fault code.
   560				 */
   561				freed += fault_lock_inode_indicies(h, inode, mapping,
 > 562							m_start, m_index, truncate_op);
   563	
   564				/*
   565				 * Remove folio that was part of folio_batch.
   566				 */
   567				hash = hugetlb_fault_mutex_hash(mapping, index);
   568				mutex_lock(&hugetlb_fault_mutex_table[hash]);
   569				if (remove_inode_single_folio(h, inode, mapping, folio,
   570								index, truncate_op))
   571					freed++;
   572				mutex_unlock(&hugetlb_fault_mutex_table[hash]);
   573			}
   574			folio_batch_release(&fbatch);
   575			cond_resched();
   576		}
   577	
   578		/*
   579		 * Take fault mutex for missing folios at end of range while checking
   580		 * for folios that might have been added due to a race with fault code.
   581		 */
   582		freed += fault_lock_inode_indicies(h, inode, mapping, m_start, m_end,
   583							truncate_op);
   584	
   585		if (truncate_op)
   586			(void)hugetlb_unreserve_pages(inode, start, LONG_MAX, freed);
   587	}
   588	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

                 reply	other threads:[~2022-08-25  2:27 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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox