From: Luben Tuikov <luben.tuikov@amd.com>
To: "Christian König" <christian.koenig@amd.com>,
"AMD Graphics" <amd-gfx@lists.freedesktop.org>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>, James Zhu <James.Zhu@amd.com>
Subject: Re: [PATCH] drm/amdgpu: Fix minmax error
Date: Fri, 25 Nov 2022 03:33:36 -0500 [thread overview]
Message-ID: <52eed51e-e234-aa36-3d74-3a4f39bb1dad@amd.com> (raw)
In-Reply-To: <fc5238a2-b30d-579e-ec7d-3686238f8b12@amd.com>
On 2022-11-25 02:59, Christian König wrote:
> Am 25.11.22 um 08:56 schrieb Luben Tuikov:
>> On 2022-11-25 02:45, Christian König wrote:
>>>
>>> Am 24.11.22 um 22:19 schrieb Luben Tuikov:
>>>> Fix minmax compilation error by using min_t()/max_t(), of the assignment type.
>>>>
>>>> Cc: James Zhu <James.Zhu@amd.com>
>>>> Cc: Felix Kuehling <Felix.Kuehling@amd.com>
>>>> Fixes: 58170a7a002ad6 ("drm/amdgpu: fix stall on CPU when allocate large system memory")
>>>> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
>>>> ---
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c | 10 +++++++---
>>>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
>>>> index 8a2e5716d8dba2..d22d14b0ef0c84 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
>>>> @@ -191,14 +191,18 @@ int amdgpu_hmm_range_get_pages(struct mmu_interval_notifier *notifier,
>>>> hmm_range->dev_private_owner = owner;
>>>>
>>>> do {
>>>> - hmm_range->end = min(hmm_range->start + MAX_WALK_BYTE, end);
>>>> + hmm_range->end = min_t(typeof(hmm_range->end),
>>>> + hmm_range->start + MAX_WALK_BYTE,
>>>> + end);
>>> Since end is a local variable I would strongly prefer to just have it
>>> use the correct type for it.
>>>
>>> Otherwise we might end up using something which doesn't work on all
>>> architectures.
>> They all appear to be "unsigned long". I thought, since we assign to
>> hmm_range->end, we use that type.
>
> Mhm, then why does the compiler complain here?
Right... so MAX_WALK_BYTE is 2^36 ULL (diabolically defined as 64ULL<<30 :-) ),
and this is why the minmax check complains.
So, since the left-hand expression is unsigned long,
i.e.,
hmm_range->end = min(hmm_range->start + MAX_WALK_BYTE, end);
is,
unsigned long = min(unsigned long long, unsigned long);
The compiler complains.
I'd really prefer MAX_WALK_BYTE be less than or equal to ULONG_MAX,
and be defined as <literal>UL. I mean, why is everything in struct hmm_range
"unsigned long", but we set a high limit of 10_0000_0000h for an end, and
compare it to "end" to find the smaller? If our "end" could potentially
be 10_0000_0000h then shouldn't the members in struct hmm_range be
unsigned long long as well?
And for the timeout, we have the (now) obvious,
timeout = max((hmm_range->end - hmm_range->start) >> 29, 1ULL);
and I don't know why we necessarily need a "1ULL", when 1UL would do just fine,
and then compilation passes for that statement. I can set this to 1UL, instead
of using max_t().
Regards,
Luben
>
> As far as I can see "unsigned long" is correct here, but if we somehow
> have a typecast then something is not working as expected.
>
> Is MAX_WALK_BYTE maybe of signed type?
>
>>
>> Would you prefer at the top of the function to define "timeout" and "end" as,
>> typeof(hmm_range->end) end, timeout;
>
> Well for end that might make sense, but timeout is independent of the
> hmm range.
>
> Regards,
> Christian.
>
>>
>> Regards,
>> Luben
>>
>
next prev parent reply other threads:[~2022-11-25 8:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-24 21:19 [PATCH] drm/amdgpu: Fix minmax error Luben Tuikov
2022-11-24 22:04 ` James Zhu
2022-11-25 7:45 ` Christian König
2022-11-25 7:56 ` Luben Tuikov
2022-11-25 7:59 ` Christian König
2022-11-25 8:33 ` Luben Tuikov [this message]
2022-11-25 9:57 ` Christian König
2022-11-25 19:42 ` Luben Tuikov
2022-11-25 21:03 ` James Zhu
2022-11-26 3:19 ` Luben Tuikov
-- strict thread matches above, loose matches on Subject: below --
2022-11-26 5:25 Luben Tuikov
2022-11-26 14:00 ` Christian König
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=52eed51e-e234-aa36-3d74-3a4f39bb1dad@amd.com \
--to=luben.tuikov@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=James.Zhu@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.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 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.