All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Alexander Antonov <alexander.antonov@linux.intel.com>,
	13145886936@163.com, tglx@linutronix.de, bp@alien8.de,
	x86@kernel.org
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	gushengxian <gushengxian@yulong.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] x86: eas should not be NULL when it is referenced
Date: Fri, 25 Jun 2021 10:11:32 -0400	[thread overview]
Message-ID: <7d4862ae-7ac6-11e8-5c8d-74610eabd5b5@linux.intel.com> (raw)
In-Reply-To: <f3e4b37b-ff84-ac4f-ff56-f03313a22cda@linux.intel.com>



On 6/25/2021 9:33 AM, Alexander Antonov wrote:
> Hello Kan,
>> On 6/24/2021 3:03 PM, Liang, Kan wrote:
>>> I think the NULL pointer dereference of eas should not happen, 
>>> because die is -1 if eas is NULL. But the whole error handling path 
>>> looks fragile.
>>>
>>> We already fixed one issue caused by it in commit ID f797f05d917f 
>>> ("perf/x86/intel/uncore: Fix for iio mapping on Skylake Server")
>>> https://lore.kernel.org/lkml/160149233331.7002.10919231011379055356.tip-bot2@tip-bot2/ 
>>>
>>>
>>> Maybe something as below?
>>>
>>>  From 3de81ba3b04262ef3346297d82f6c4ffb4af7029 Mon Sep 17 00:00:00 2001
>>> From: Kan Liang <kan.liang@linux.intel.com>
>>> Date: Thu, 24 Jun 2021 11:17:57 -0700
>>> Subject: [PATCH] perf/x86/intel/uncore: Clean up error handling path 
>>> of iio mapping
>>>
>>> The error handling path of iio mapping looks fragile. We already fixed
>>> one issue caused by it, commit ID f797f05d917f ("perf/x86/intel/uncore:
>>> Fix for iio mapping on Skylake Server"). Clean up the error handling
>>> path and make the code robust.
> I didn't catch why does the current error handling path look fragile?
> Are there cases when it works incorrect?
>


I don't think it causes any severe problem for now, e.g., crash, because 
current code checks die before the dereference.
But I think it violates the Linux kernel coding style (one err bug) and 
may bring potential issues.

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

Thanks,
Kan

> Thanks,
> Alexander
>>>
>>> Reported-by: gushengxian <gushengxian@yulong.com>
>>> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
>>> ---
>>>   arch/x86/events/intel/uncore_snbep.c | 6 ++++--
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/events/intel/uncore_snbep.c 
>>> b/arch/x86/events/intel/uncore_snbep.c
>>> index 7622762..6d4a5a9 100644
>>> --- a/arch/x86/events/intel/uncore_snbep.c
>>> +++ b/arch/x86/events/intel/uncore_snbep.c
>>> @@ -3802,11 +3802,11 @@ pmu_iio_set_mapping(struct intel_uncore_type 
>>> *type, struct attribute_group *ag)
>>>       /* One more for NULL. */
>>>       attrs = kcalloc((uncore_max_dies() + 1), sizeof(*attrs), 
>>> GFP_KERNEL);
>>>       if (!attrs)
>>> -        goto err;
>>> +        goto clear_topology;
>>>
>>>       eas = kcalloc(uncore_max_dies(), sizeof(*eas), GFP_KERNEL);
>>>       if (!eas)
>>> -        goto err;
>>> +        goto clear_attrs;
>>>
>>>       for (die = 0; die < uncore_max_dies(); die++) {
>>>           sprintf(buf, "die%ld", die);
>>> @@ -3827,7 +3827,9 @@ pmu_iio_set_mapping(struct intel_uncore_type 
>>> *type, struct attribute_group *ag)
>>>       for (; die >= 0; die--)
>>>           kfree(eas[die].attr.attr.name);
>>>       kfree(eas);
>>> +clear_attrs:
>>>       kfree(attrs);
>>> +clear_topology:
>>>       kfree(type->topology);
>>>   clear_attr_update:
>>>       type->attr_update = NULL;

  reply	other threads:[~2021-06-25 14:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24  7:04 [PATCH] x86: eas should not be NULL when it is referenced 13145886936
2021-06-24  7:24 ` Peter Zijlstra
2021-06-24 19:03 ` Liang, Kan
2021-06-24 19:06   ` Liang, Kan
2021-06-25 13:33     ` Alexander Antonov
2021-06-25 14:11       ` Liang, Kan [this message]
2021-06-25 14:26         ` Alexander Antonov
2021-07-05  7:53   ` [tip: perf/urgent] perf/x86/intel/uncore: Clean up error handling path of iio mapping tip-bot2 for Kan Liang

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=7d4862ae-7ac6-11e8-5c8d-74610eabd5b5@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=13145886936@163.com \
    --cc=alexander.antonov@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=gushengxian@yulong.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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 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.