From: John Hubbard <jhubbard@nvidia.com>
To: Ralph Campbell <rcampbell@nvidia.com>,
Jerome Glisse <jglisse@redhat.com>,
David Airlie <airlied@linux.ie>, Ben Skeggs <bskeggs@redhat.com>,
"Jason Gunthorpe" <jgg@mellanox.com>
Cc: <nouveau@lists.freedesktop.org>, <linux-mm@kvack.org>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/nouveau/dmem: missing mutex_lock in error path
Date: Fri, 14 Jun 2019 10:48:13 -0700 [thread overview]
Message-ID: <6e412091-faf4-64b6-bcd8-95193b11a6ec@nvidia.com> (raw)
In-Reply-To: <f67784db-dada-c827-f231-35549fc046dc@nvidia.com>
On 6/14/19 10:39 AM, Ralph Campbell wrote:
> On 6/13/19 5:49 PM, John Hubbard wrote:
>> On 6/13/19 5:11 PM, Ralph Campbell wrote:
...
>> Actually, the pre-existing code is a little concerning. Your change preserves
>> the behavior, but it seems questionable to be doing a "return 0" (whether
>> via the above break, or your change) when it's in this partially allocated
>> state. It's reporting success when it only allocates part of what was requested,
>> and it doesn't fill in the pages array either.
>>
>>
>>
>>> + return 0;
>>> return ret;
>>> }
>>> + mutex_lock(&drm->dmem->mutex);
>>> continue;
>>> }
>>>
>>
>> The above comment is about pre-existing potential problems, but your patch itself
>> looks correct, so:
>>
>> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
>>
>>
>> thanks,
>>
> The crash was the NULL pointer bug in Christoph's patch #10.
> I sent a separate reply for that.
>
> Below is the console output I got, then I made the changes just based on
> code inspection. Do you think I should include it in the change log?
Yes, I think it's good to have it in there. If you look at git log,
you'll see that it's common to include the symptoms, including the
backtrace. It helps people see if they are hitting the same problem,
for one thing.
>
> As for the "return 0", If you follow the call chain,
> nouveau_dmem_pages_alloc() is only ever called for one page so this
> currently "works" but I agree it is a bit of a time bomb. There are a
> number of other bugs that I can see that need fixing but I think those
> should be separate patches.
>
Yes of course. I called it out for the benefit of the email list, not to
say that your patch needs any changes.
thanks,
--
John Hubbard
NVIDIA
prev parent reply other threads:[~2019-06-14 17:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 0:11 Ralph Campbell
2019-06-14 0:24 ` Jason Gunthorpe
2019-06-14 0:49 ` John Hubbard
2019-06-14 17:39 ` Ralph Campbell
2019-06-14 17:48 ` John Hubbard [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=6e412091-faf4-64b6-bcd8-95193b11a6ec@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=airlied@linux.ie \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@mellanox.com \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rcampbell@nvidia.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