public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Cc: "Oded Gabbay" <oded.gabbay@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"David Airlie" <airlied@linux.ie>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences
Date: Wed, 10 Jan 2018 17:26:05 -0500	[thread overview]
Message-ID: <413c85ee-aca0-fd86-4792-0d620b9251e2@amd.com> (raw)
In-Reply-To: <20180110155849.Horde.DDGbi3ysasL2eHmvZ4k8adb@gator4166.hostgator.com>

Yeah, this looks good to me.

Regards,
  Felix


On 2018-01-10 04:58 PM, Gustavo A. R. Silva wrote:
> Hi Felix,
>
> Quoting Felix Kuehling <felix.kuehling@amd.com>:
>
>> Hi Gustavo,
>>
>> Thanks for catching that. When returning a fault, I think you also need
>> to srcu_read_unlock(&kfd_processes_srcu, idx).
>>
>> However, instead of returning an error, I think I'd prefer to skip PDDs
>> that can't be found with continue statements. That way others would
>> still suspend and resume successfully. Maybe just print a WARN_ON for
>> PDDs that aren't found, because that's an unexpected situation,
>> currently. Maybe in the future it could be normal thing if we ever
>> support GPU hotplug.
>>
>
> I got it. In that case, what do you think about the following patch
> instead?
>
> index a22fb071..4ff5f0f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -461,7 +461,8 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
>         hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
>                 mutex_lock(&p->mutex);
>                 pdd = kfd_get_process_device_data(dev, p);
> -               if (pdd->bound != PDD_BOUND_SUSPENDED) {
> +
> +               if (WARN_ON(!pdd) || pdd->bound != PDD_BOUND_SUSPENDED) {
>                         mutex_unlock(&p->mutex);
>                         continue;
>                 }
> @@ -501,6 +502,11 @@ void kfd_unbind_processes_from_device(struct
> kfd_dev *dev)
>                 mutex_lock(&p->mutex);
>                 pdd = kfd_get_process_device_data(dev, p);
>
> +               if (WARN_ON(!pdd)) {
> +                       mutex_unlock(&p->mutex);
> +                       continue;
> +               }
> +
>                 if (pdd->bound == PDD_BOUND)
>                         pdd->bound = PDD_BOUND_SUSPENDED;
>                 mutex_unlock(&p->mutex);
>
>
> Thank you for the feedback.
> -- 
> Gustavo
>
>> Regards,
>>   Felix
>>
>>
>> On 2018-01-10 11:50 AM, Gustavo A. R. Silva wrote:
>>> In case kfd_get_process_device_data returns null, there are some
>>> null pointer dereferences in functions kfd_bind_processes_to_device
>>> and kfd_unbind_processes_from_device.
>>>
>>> Fix this by null checking pdd before dereferencing it.
>>>
>>> Addresses-Coverity-ID: 1463794 ("Dereference null return value")
>>> Addresses-Coverity-ID: 1463772 ("Dereference null return value")
>>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>>> ---
>>>  drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12 ++++++++++++
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> index a22fb071..29d51d5 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
>>> @@ -461,6 +461,13 @@ int kfd_bind_processes_to_device(struct kfd_dev
>>> *dev)
>>>      hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
>>>          mutex_lock(&p->mutex);
>>>          pdd = kfd_get_process_device_data(dev, p);
>>> +
>>> +        if (!pdd) {
>>> +            pr_err("Process device data doesn't exist\n");
>>> +            mutex_unlock(&p->mutex);
>>> +            return -EFAULT;
>>> +        }
>>> +
>>>          if (pdd->bound != PDD_BOUND_SUSPENDED) {
>>>              mutex_unlock(&p->mutex);
>>>              continue;
>>> @@ -501,6 +508,11 @@ void kfd_unbind_processes_from_device(struct
>>> kfd_dev *dev)
>>>          mutex_lock(&p->mutex);
>>>          pdd = kfd_get_process_device_data(dev, p);
>>>
>>> +        if (!pdd) {
>>> +            mutex_unlock(&p->mutex);
>>> +            return;
>>> +        }
>>> +
>>>          if (pdd->bound == PDD_BOUND)
>>>              pdd->bound = PDD_BOUND_SUSPENDED;
>>>          mutex_unlock(&p->mutex);
>
>
>
>
>
>

      reply	other threads:[~2018-01-10 22:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 16:50 [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences Gustavo A. R. Silva
2018-01-10 18:33 ` Felix Kuehling
2018-01-10 21:58   ` Gustavo A. R. Silva
2018-01-10 22:26     ` Felix Kuehling [this message]

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=413c85ee-aca0-fd86-4792-0d620b9251e2@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=garsilva@embeddedor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oded.gabbay@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox