All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: liuyuntao <liuyuntao10@huawei.com>
Cc: mike.kravetz@oracle.com, akpm@linux-foundation.org,
	baolin.wang@linux.alibaba.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, yaozhenguo1@gmail.com
Subject: Re: [PATCH] hugetlb: clean up potential spectre issue warnings
Date: Fri, 18 Feb 2022 09:52:10 +0300	[thread overview]
Message-ID: <20220218065210.GD2467@kadam> (raw)
In-Reply-To: <20220218034025.17687-1-liuyuntao10@huawei.com>

On Fri, Feb 18, 2022 at 11:40:25AM +0800, liuyuntao wrote:
> On 17 Feb 2022 15:42:18 -0800, Mike Kravetz wrote:
> > Recently introduced code allows numa nodes to be specified on the
> > kernel command line for hugetlb allocations or CMA reservations.  The
> > node values are user specified and used as indicies into arrays.  This
> > generated the following smatch warnings:
> > 
> > mm/hugetlb.c:4170 hugepages_setup() warn: potential spectre issue 'default_hugepages_in_node' [w]
> > mm/hugetlb.c:4172 hugepages_setup() warn: potential spectre issue 'parsed_hstate->max_huge_pages_node' [w]
> > mm/hugetlb.c:6898 cmdline_parse_hugetlb_cma() warn: potential spectre issue 'hugetlb_cma_size_in_node' [w] (local cap)
> > 
> > Clean up by using array_index_nospec to sanitize array indicies.
> > 
> > Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> > ---
> >  mm/hugetlb.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 1f0cca036f7f..6b14d0791cb4 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -31,6 +31,7 @@
> >  #include <linux/llist.h>
> >  #include <linux/cma.h>
> >  #include <linux/migrate.h>
> > +#include <linux/nospec.h>
> >  
> >  #include <asm/page.h>
> >  #include <asm/pgalloc.h>
> > @@ -4161,7 +4162,7 @@ static int __init hugepages_setup(char *s)
> >  			}
> >  			if (tmp >= nr_online_nodes)
> >  				goto invalid;
> > -			node = tmp;
> > +			node = array_index_nospec(tmp, nr_online_nodes);
> >  			p += count + 1;
> >  			/* Parse hugepages */
> >  			if (sscanf(p, "%lu%n", &tmp, &count) != 1)
> > @@ -6889,9 +6890,9 @@ static int __init cmdline_parse_hugetlb_cma(char *p)
> >  			break;
> >  
> >  		if (s[count] == ':') {
> > -			nid = tmp;
> > -			if (nid < 0 || nid >= MAX_NUMNODES)
> > +			if (tmp < 0 || tmp >= MAX_NUMNODES)
> 
> Here tmp is unsigned, no need to check if less than 0.
> Do we really have any automated checking? lol
> 

Smatch ignores checks for negative when it's part of a clamp test.  In
this situation the check for negative is obviously harmless so a warning
is a false positive.

If you wrote it the other way:

		if (tmp >= MAX_NUMNODES || tmp < 0)

then Smatch would print a warning because I try not to get involved with
style debates but I really don't like that style...  :P

regards,
dan carpenter


  reply	other threads:[~2022-02-18  6:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17 23:42 [PATCH] hugetlb: clean up potential spectre issue warnings Mike Kravetz
2022-02-18  3:40 ` liuyuntao
2022-02-18  6:52   ` Dan Carpenter [this message]
2022-02-18 17:14   ` Mike Kravetz

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=20220218065210.GD2467@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuyuntao10@huawei.com \
    --cc=mike.kravetz@oracle.com \
    --cc=yaozhenguo1@gmail.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.