public inbox for smatch@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: smatch@vger.kernel.org
Subject: Re: alloc_page leaks tracing
Date: Sat, 12 Mar 2022 00:12:15 +0300	[thread overview]
Message-ID: <20220311211215.GN3315@kadam> (raw)
In-Reply-To: <82B7079C-AD17-4E5E-A245-71E9ED53E5A3@linuxhacker.ru>

On Thu, Mar 10, 2022 at 04:30:42PM -0500, Oleg Drokin wrote:
> 
> Thanks, I added this and there’s still no detection.
> Example code:
> 
>         __page = alloc_page(GFP_KERNEL);
>         if (__page == NULL)
>                 return -ENOMEM;
> 
>         req = cfs_crypto_hash_init(cfs_alg, NULL, 0);
>         if (IS_ERR(req)) {
>                 CERROR("%s: unable to initialize checksum hash %s\n",
>                        tgt_name(tgt), cfs_crypto_hash_name(cfs_alg));
>                 return PTR_ERR(req);
>         }
> 
>         buffer = kmap(__page);
> 
> 
> diff --git a/check_unwind.c b/check_unwind.c
> index 569792ad..7611f377 100644
> --- a/check_unwind.c
> +++ b/check_unwind.c
> @@ -92,6 +92,11 @@ static struct ref_func_info func_table[] = {
>  
>         { "ieee80211_alloc_hw", ALLOC,  -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
>         { "ieee80211_free_hw",  RELEASE, 0, "$" },
> +       { "alloc_pages", ALLOC,  -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
> +       { "alloc_page", ALLOC,  -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
> +       { "__get_free_pages", ALLOC, -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
> +       { "free_pages", RELEASE, 0, "$" },
> +       { "__free_page", RELEASE, 0, "$" },
>  };

Hey Oleg,

Sorry, I should have tested this better...

There are two issues.  The easy issue is that apparently I didn't stop
to consider error pointers as a failure return.

The more complicated problem is that the allocation hook will only
trigger for cases where Smatch knows what the return is.  Right now
Smatch knows that alloc_pages either returns NULL, or non-NULL (but
potentially error pointers).  This is return_implies_param_key_exact()
vs return_implies_param_key().

Of course, I changed it to _exact() deliberately to silence false
positives.  I don't remember the details so I'll retest tonight and look
again on Monday.

An easy "fix" would be to add "alloc_pages 1-u64max 4096-ptr_max" so it
gets hardcoded on the next db rebuild, but that's kind of a hack as
well.

diff --git a/check_unwind.c b/check_unwind.c
index 569792ad5a57..c3015cca3374 100644
--- a/check_unwind.c
+++ b/check_unwind.c
@@ -92,6 +92,10 @@ static struct ref_func_info func_table[] = {
 
 	{ "ieee80211_alloc_hw", ALLOC,  -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
 	{ "ieee80211_free_hw",  RELEASE, 0, "$" },
+
+	{ "alloc_pages", ALLOC,  -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
+	{ "__get_free_pages", ALLOC, -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval },
+	{ "free_pages", RELEASE, 0, "$" },
 };
 
 static struct smatch_state *unmatched_state(struct sm_state *sm)
@@ -237,11 +241,14 @@ enum {
 static int success_fail_positive(struct range_list *rl)
 {
 	if (!rl)
-		return UNKNOWN;
+		return SUCCESS;
 
 	if (sval_is_negative(rl_min(rl)) && sval_is_negative(rl_max(rl)))
 		return FAIL;
 
+	if (type_is_ptr(rl_type(rl)) && is_err_or_null(rl))
+		return FAIL;
+
 	if (rl_min(rl).value == 0)
 		return SUCCESS;
 
@@ -334,7 +341,7 @@ void check_unwind(int id)
 		if (info->call_back) {
 			add_function_hook(info->name, info->call_back, info);
 		} else if (info->implies_start && info->type == ALLOC) {
-			return_implies_param_key_exact(info->name,
+			return_implies_param_key(info->name,
 					*info->implies_start,
 					*info->implies_end,
 					&return_param_alloc,

  parent reply	other threads:[~2022-03-11 22:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 17:28 alloc_page leaks tracing Oleg Drokin
2022-03-10  9:42 ` Dan Carpenter
     [not found]   ` <82B7079C-AD17-4E5E-A245-71E9ED53E5A3@linuxhacker.ru>
2022-03-11 21:12     ` Dan Carpenter [this message]
2022-03-22  8:05       ` Dan Carpenter
2022-03-25  6:48         ` Dan Carpenter

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=20220311211215.GN3315@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=green@linuxhacker.ru \
    --cc=smatch@vger.kernel.org \
    /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