All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Naresh Kamboju <naresh.kamboju@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm <linux-mm@kvack.org>,
	open list <linux-kernel@vger.kernel.org>,
	regressions@lists.linux.dev,
	Nathan Chancellor <nathan@kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	David Hildenbrand <david@redhat.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	James Houghton <jthoughton@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Miaohe Lin <linmiaohe@huawei.com>, Michal Hocko <mhocko@suse.com>,
	Mina Almasry <almasrymina@google.com>,
	Naoya Horiguchi <naoya.horiguchi@linux.dev>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Peter Xu <peterx@redhat.com>,
	Prakash Sangappa <prakash.sangappa@oracle.com>
Subject: Re: [next] x86: fs/hugetlbfs/inode.c:673:16: error: variable 'm_index' is uninitialized when used here [-Werror,-Wuninitialized]
Date: Thu, 25 Aug 2022 09:56:15 -0700	[thread overview]
Message-ID: <Ywepr7C2X20ZvLdn@monkey> (raw)
In-Reply-To: <CA+G9fYsHVdu0toduQqk6vsR8Z8mOVzZ9-_p3O5fjQ5mOpSxsDA@mail.gmail.com>

On 08/25/22 16:13, Naresh Kamboju wrote:
> The x86_64 and i386 clang builds failed due to these warnings / errors
> on Linux next-20220825.
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> fs/hugetlbfs/inode.c:673:16: error: variable 'm_index' is
> uninitialized when used here [-Werror,-Wuninitialized]
>                                                 m_start, m_index, truncate_op);
>                                                          ^~~~~~~
> fs/hugetlbfs/inode.c:651:26: note: initialize the variable 'm_index'

Thanks!  That really should be 'index' and not 'm_index'.  The variable
m_index was used in a previous version of the code and should have been
deleted.  Depending on the uninitialized value of m_index, this could
cause long delays as the called routine checks the range m_start to m_index.

Andrew, how would you like to address in your tree?  The following patch
can be applied on top of the original (next commit fcc0d3d00d74 "hugetlb:
handle truncate racing with page faults").  Or, I could squash and
resend the original, or resend the entire series.


From 99aae359c3a744e6718045d2f24b55c84bed4d56 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz@oracle.com>
Date: Thu, 25 Aug 2022 09:49:08 -0700
Subject: [PATCH] hugetlb: fix/remove uninitialized variable in
 remove_inode_hugepages

Code introduced for the routine remove_inode_hugepages by patch "hugetlb:
handle truncate racing with page faults", incorrectly uses a variable
m_index.  This is a remnant from a previous version of the code when
under development.  Use the correct variable 'index' and remove
'm_index' from the routine.

Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 fs/hugetlbfs/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 52d9b390389b..2f1d6da1bafb 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -648,7 +648,7 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
 	const pgoff_t start = lstart >> huge_page_shift(h);
 	const pgoff_t end = lend >> huge_page_shift(h);
 	pgoff_t m_end = lm_end >> huge_page_shift(h);
-	pgoff_t m_start, m_index;
+	pgoff_t m_start;
 	struct folio_batch fbatch;
 	struct folio *folio;
 	pgoff_t next, index;
@@ -670,7 +670,7 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
 			 * due to a race with fault code.
 			 */
 			freed += fault_lock_inode_indicies(h, inode, mapping,
-						m_start, m_index, truncate_op);
+						m_start, index, truncate_op);
 
 			/*
 			 * Remove folio that was part of folio_batch.
-- 
2.37.1


  parent reply	other threads:[~2022-08-25 16:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 10:43 [next] x86: fs/hugetlbfs/inode.c:673:16: error: variable 'm_index' is uninitialized when used here [-Werror,-Wuninitialized] Naresh Kamboju
2022-08-25 16:10 ` Nathan Chancellor
2022-08-25 16:56 ` Mike Kravetz [this message]
2022-08-26  1:21   ` Andrew Morton

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=Ywepr7C2X20ZvLdn@monkey \
    --to=mike.kravetz@oracle.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=axelrasmussen@google.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=jthoughton@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=naoya.horiguchi@linux.dev \
    --cc=naresh.kamboju@linaro.org \
    --cc=nathan@kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterx@redhat.com \
    --cc=prakash.sangappa@oracle.com \
    --cc=regressions@lists.linux.dev \
    --cc=songmuchun@bytedance.com \
    /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.