All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Felix Kuehling <felix.kuehling@amd.com>
Cc: "David Airlie" <airlied@linux.ie>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	kernel-janitors@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	"Ramesh Errabolu" <Ramesh.Errabolu@amd.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH] drm/amdkfd: potential crash in kfd_create_indirect_link_prop()
Date: Mon, 15 Aug 2022 14:23:59 +0300	[thread overview]
Message-ID: <20220815112358.GA3460@kadam> (raw)
In-Reply-To: <8fe840db-ccba-0dae-23fe-d08db0b35167@amd.com>

On Fri, Aug 12, 2022 at 05:10:51PM -0400, Felix Kuehling wrote:
> On 2022-08-12 02:20, Dan Carpenter wrote:
> > This code has two bugs.  If kfd_topology_device_by_proximity_domain()
> > failed on the first iteration through the loop then "cpu_link" is
> > uninitialized and should not be dereferenced.
> > 
> > The second bug is that we cannot dereference a list iterator when it
> > points to the list head.  In other words, if we exit the
> > list_for_each_entry() loop exits without hitting a break then "cpu_link"
> > is not a valid pointer and should not be dereferenced.
> > 
> > Fix both of these problems by setting "cpu_link" to NULL when it is invalid
> > and non-NULL when it is valid.  That makes it easier to test for
> > valid vs invalid.
> > 
> > Fixes: 0f28cca87e9a ("drm/amdkfd: Extend KFD device topology to surface peer-to-peer links")
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > I reported these in June but never heard back.
> 
> I thought Ramesh implemented a fix for this:
> https://lore.kernel.org/all/20220706183302.1719795-1-Ramesh.Errabolu@amd.com/
> 
> You commented on a version of his patch:
> https://lore.kernel.org/all/20220629161241.GM11460@kadam/

Oh, Sorry!  I appologize for forgetting that.

> 
> Did this get lost somehow? Anyway, your patch looks good to me and I'm going
> to apply it to amd-staging-drm-next now.
> 
> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>

Looking at Ramesh's patch now, he added a continue if
kfd_topology_device_by_proximity_domain() failed.  That is a behavior
change, but it might also be a bug fix.

My patch does not change the behavior except for eliminating the crash
so I stand by my patch, but adding the continue might be a good thing to
do as a separate step.  I don't know the code well enough to say one way
or the other.

regards,
dan carpenter


WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Felix Kuehling <felix.kuehling@amd.com>
Cc: "Ramesh Errabolu" <Ramesh.Errabolu@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	amd-gfx@lists.freedesktop.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] drm/amdkfd: potential crash in kfd_create_indirect_link_prop()
Date: Mon, 15 Aug 2022 14:23:59 +0300	[thread overview]
Message-ID: <20220815112358.GA3460@kadam> (raw)
In-Reply-To: <8fe840db-ccba-0dae-23fe-d08db0b35167@amd.com>

On Fri, Aug 12, 2022 at 05:10:51PM -0400, Felix Kuehling wrote:
> On 2022-08-12 02:20, Dan Carpenter wrote:
> > This code has two bugs.  If kfd_topology_device_by_proximity_domain()
> > failed on the first iteration through the loop then "cpu_link" is
> > uninitialized and should not be dereferenced.
> > 
> > The second bug is that we cannot dereference a list iterator when it
> > points to the list head.  In other words, if we exit the
> > list_for_each_entry() loop exits without hitting a break then "cpu_link"
> > is not a valid pointer and should not be dereferenced.
> > 
> > Fix both of these problems by setting "cpu_link" to NULL when it is invalid
> > and non-NULL when it is valid.  That makes it easier to test for
> > valid vs invalid.
> > 
> > Fixes: 0f28cca87e9a ("drm/amdkfd: Extend KFD device topology to surface peer-to-peer links")
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > I reported these in June but never heard back.
> 
> I thought Ramesh implemented a fix for this:
> https://lore.kernel.org/all/20220706183302.1719795-1-Ramesh.Errabolu@amd.com/
> 
> You commented on a version of his patch:
> https://lore.kernel.org/all/20220629161241.GM11460@kadam/

Oh, Sorry!  I appologize for forgetting that.

> 
> Did this get lost somehow? Anyway, your patch looks good to me and I'm going
> to apply it to amd-staging-drm-next now.
> 
> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>

Looking at Ramesh's patch now, he added a continue if
kfd_topology_device_by_proximity_domain() failed.  That is a behavior
change, but it might also be a bug fix.

My patch does not change the behavior except for eliminating the crash
so I stand by my patch, but adding the continue might be a good thing to
do as a separate step.  I don't know the code well enough to say one way
or the other.

regards,
dan carpenter


  reply	other threads:[~2022-08-15 11:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12  6:20 [PATCH] drm/amdkfd: potential crash in kfd_create_indirect_link_prop() Dan Carpenter
2022-08-12  6:20 ` Dan Carpenter
2022-08-12 21:10 ` Felix Kuehling
2022-08-12 21:10   ` Felix Kuehling
2022-08-15 11:23   ` Dan Carpenter [this message]
2022-08-15 11:23     ` 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=20220815112358.GA3460@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=Ramesh.Errabolu@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=felix.kuehling@amd.com \
    --cc=kernel-janitors@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 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.