<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Am 21.04.22 um 04:15 schrieb Wang, Yang(Kevin):<br>
<blockquote type="cite"
cite="mid:CO6PR12MB5473F2A9C21F68886DDF140082F49@CO6PR12MB5473.namprd12.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<p
style="font-family:Arial;font-size:10pt;color:#0000FF;margin:5pt;"
align="Left">
[AMD Official Use Only]<br>
</p>
<br>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
Kuehling, Felix <a class="moz-txt-link-rfc2396E" href="mailto:Felix.Kuehling@amd.com"><Felix.Kuehling@amd.com></a><br>
<b>Sent:</b> Thursday, April 21, 2022 5:21 AM<br>
<b>To:</b> Lazar, Lijo <a class="moz-txt-link-rfc2396E" href="mailto:Lijo.Lazar@amd.com"><Lijo.Lazar@amd.com></a>; Koenig,
Christian <a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a>; Wang,
Yang(Kevin) <a class="moz-txt-link-rfc2396E" href="mailto:KevinYang.Wang@amd.com"><KevinYang.Wang@amd.com></a>; Christian König
<a class="moz-txt-link-rfc2396E" href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a>;
<a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a><br>
<b>Subject:</b> Re: [PATCH] drm/ttm: fix ttm tt init fail
when size exceeds kmalloc limit</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt">
<div class="PlainText elementToProof"><br>
On 2022-04-20 09:23, Lazar, Lijo wrote:<br>
><br>
><br>
> On 4/20/2022 6:26 PM, Christian König wrote:<br>
>> Am 20.04.22 um 14:54 schrieb Wang, Yang(Kevin):<br>
>>><br>
>>> [AMD Official Use Only]<br>
>>><br>
>>><br>
>>> Hi Chris,<br>
>>><br>
>>> 1) Change the test case to use something
larger than 1TiB.<br>
>>> sure, we can increase the size of BO and
make test pass,<br>
>>> but if user really want to allocate 1TB GTT
BO, we have no reason to <br>
>>> let it fail? right?<br>
>><br>
>> No, the reason is the underlying core kernel
doesn't allow kvmalloc <br>
>> allocations with GFP_ZERO which are large
enough to hold the array of <br>
>> allocated pages for this.<br>
>><br>
>> We are working on top of the core Linux kernel
and should *NEVER* <br>
>> ever add workarounds like what was suggested
here. ><br>
><br>
> AFAIU, for the purpose of ttm use, fallback to
vmalloc is fine.<br>
><br>
> * Please note that any use of gfp flags outside of
GFP_KERNEL is <br>
> careful to not<br>
> * fall back to vmalloc.<br>
> *<br>
<br>
That's weird, because kvcalloc does the same thing. If
that were not <br>
able to fall back to vmalloc, it would be pretty
useless.<br>
<br>
static inline __alloc_size(1, 2) void
*kvcalloc(size_t n, size_t size, gfp_t flags)<br>
{<br>
return kvmalloc_array(n, size, flags |
__GFP_ZERO);<br>
}<br>
<br>
Maybe kvcalloc is the function we TTM should be using
here anyway, <br>
instead of open-coding the kvmalloc_array call with an
extra GFP flag.<br>
<br>
Regards,<br>
Felix</div>
<div class="PlainText elementToProof"><br>
</div>
<div class="PlainText elementToProof">Yes, I agree with
your point, and in amdkfd driver code, we have the same
risk in svm_range_dma_map_dev().<br>
</div>
</span></font></div>
</div>
</blockquote>
<br>
Yes, sounds like a good idea to me as well to change that.<br>
<br>
Regards,<br>
Christian.<br>
<br>
<blockquote type="cite"
cite="mid:CO6PR12MB5473F2A9C21F68886DDF140082F49@CO6PR12MB5473.namprd12.prod.outlook.com">
<div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt">
<div class="PlainText elementToProof">
<br>
Best Regards,<br>
Kevin<br>
<br>
><br>
> Actually the current implementation documents the
behavior, but it is <br>
> deep inside the implementation to be noticeable -
at least not obvious <br>
> while using kvmalloc_array.<br>
><br>
> Thanks,<br>
> Lijo<br>
><br>
>> Regards,<br>
>> Christian.<br>
>><br>
>>> the system availed memory about 2T, but it
will still fail.<br>
>>><br>
>>> 2) Change kvmalloc to allow GFP_ZERO
allocations even in the vmalloc <br>
>>> fallback path.<br>
>>> the 5.18 kernel will add this patch to
fix this issue .<br>
>>><br>
>>> Best Regards,<br>
>>> Kevin<br>
>>>
------------------------------------------------------------------------
<br>
>>><br>
>>> *From:* Koenig, Christian
<a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a><br>
>>> *Sent:* Wednesday, April 20, 2022 8:42 PM<br>
>>> *To:* Wang, Yang(Kevin)
<a class="moz-txt-link-rfc2396E" href="mailto:KevinYang.Wang@amd.com"><KevinYang.Wang@amd.com></a>; Christian König <br>
>>> <a class="moz-txt-link-rfc2396E" href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a> <br>
>>> <a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a>;
<a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <br>
>>> <a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a><br>
>>> *Subject:* Re: [PATCH] drm/ttm: fix ttm tt
init fail when size <br>
>>> exceeds kmalloc limit<br>
>>> Hi Kevin,<br>
>>><br>
>>> yes and that is perfectly valid and
expected behavior. There is <br>
>>> absolutely no need to change anything in
TTM here.<br>
>>><br>
>>> What we could do is:<br>
>>> 1) Change the test case to use something
larger than 1TiB.<br>
>>> 2) Change kvmalloc to allow GFP_ZERO
allocations even in the vmalloc <br>
>>> fallback path.<br>
>>><br>
>>> Regards,<br>
>>> Christian.<br>
>>><br>
>>> Am 20.04.22 um 14:39 schrieb Wang,
Yang(Kevin):<br>
>>>><br>
>>>> [AMD Official Use Only]<br>
>>>><br>
>>>><br>
>>>> Hi Chirs,<br>
>>>><br>
>>>> yes, right, the amdgpu drive rwill use
amdgpu_bo_validate_size() <br>
>>>> function to verify bo size,<br>
>>>> but when driver try to allocate VRAM
domain bo fail, the amdgpu <br>
>>>> driver will fall back to allocate
domain = (GTT | VRAM) bo.<br>
>>>> please check following code, it will
cause the 2nd time to allocate <br>
>>>> bo fail during allocate 256Mb buffer to
store dma address (via <br>
>>>> kvmalloc()).<br>
>>>><br>
>>>> initial_domain = (u32)(0xffffffff &
args->in.domains);<br>
>>>> retry:<br>
>>>> r =
amdgpu_gem_object_create(adev, size,
args->in.alignment,<br>
>>>> initial_domain,<br>
>>>> flags,
ttm_bo_type_device, resv, &gobj);<br>
>>>> if (r && r !=
-ERESTARTSYS) {<br>
>>>> if (flags &
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {<br>
>>>> flags &=
~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;<br>
>>>> goto retry;<br>
>>>> }<br>
>>>><br>
>>>> if (initial_domain ==
AMDGPU_GEM_DOMAIN_VRAM) {<br>
>>>> initial_domain |=
AMDGPU_GEM_DOMAIN_GTT;<br>
>>>> goto retry;<br>
>>>> }<br>
>>>> DRM_DEBUG("Failed to allocate GEM
object (%llu, %d, %llu, %d)\n",<br>
>>>> size, initial_domain,
args->in.alignment, r);<br>
>>>> }<br>
>>>><br>
>>>> Best Regards,<br>
>>>> Kevin<br>
>>>><br>
>>>>
------------------------------------------------------------------------
<br>
>>>><br>
>>>> *From:* Christian König
<a class="moz-txt-link-rfc2396E" href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a> <br>
>>>> <<a
href="mailto:ckoenig.leichtzumerken@gmail.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:ckoenig.leichtzumerken@gmail.com</a>><br>
>>>> *Sent:* Wednesday, April 20, 2022 7:55
PM<br>
>>>> *To:* Wang, Yang(Kevin)
<a class="moz-txt-link-rfc2396E" href="mailto:KevinYang.Wang@amd.com"><KevinYang.Wang@amd.com></a> <br>
>>>> <<a
href="mailto:KevinYang.Wang@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:KevinYang.Wang@amd.com</a>>;
Koenig, Christian
<br>
>>>> <a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a> <<a
href="mailto:Christian.Koenig@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:Christian.Koenig@amd.com</a>>;
<br>
>>>> <a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a> <br>
>>>> <<a
href="mailto:dri-devel@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:dri-devel@lists.freedesktop.org</a>>
<br>
>>>> <a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a>
<br>
>>>> <<a
href="mailto:dri-devel@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:dri-devel@lists.freedesktop.org</a>>;
<br>
>>>> <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <br>
>>>> <<a
href="mailto:amd-gfx@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:amd-gfx@lists.freedesktop.org</a>>
<br>
>>>> <a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a>
<<a href="mailto:amd-gfx@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:amd-gfx@lists.freedesktop.org</a>><br>
>>>> *Subject:* Re: [PATCH] drm/ttm: fix ttm
tt init fail when size <br>
>>>> exceeds kmalloc limit<br>
>>>> Hi Kevin,<br>
>>>><br>
>>>> no, the test case should already fail
in amdgpu_bo_validate_size().<br>
>>>><br>
>>>> If we have a system with 2TiB of memory
where the test case could <br>
>>>> succeed then we should increase the
requested size to something <br>
>>>> larger.<br>
>>>><br>
>>>> And if the underlying core Linux kernel
functions don't allow <br>
>>>> allocations as large as the requested
one we should *NEVER* ever <br>
>>>> add workarounds like this.<br>
>>>><br>
>>>> It is perfectly expected that this test
case is not able to fulfill <br>
>>>> the desired allocation. That it fails
during kvmalloc is <br>
>>>> unfortunate, but not a show stopper.<br>
>>>><br>
>>>> Regards,<br>
>>>> Christian.<br>
>>>><br>
>>>><br>
>>>> Am 20.04.22 um 13:32 schrieb Wang,
Yang(Kevin):<br>
>>>>><br>
>>>>> [AMD Official Use Only]<br>
>>>>><br>
>>>>><br>
>>>>> Hi Chris,<br>
>>>>><br>
>>>>> you misunderstood background about
this case.<br>
>>>>><br>
>>>>> although we expect this test case
to fail, it should fail at the <br>
>>>>> location where the Bo actual memory
is actually allocated. now the <br>
>>>>> code logic will cause the failure
to allocate memory to store DMA <br>
>>>>> address.<br>
>>>>><br>
>>>>> e.g: the case is failed in 2TB
system ram machine, it should be <br>
>>>>> allocated successful, but it is
failed.<br>
>>>>><br>
>>>>> allocate 1TB BO, the ttm should
allocate 1TB/4k * 8 buffer to <br>
>>>>> store allocate result (page
address), this should not be failed <br>
>>>>> usually.<br>
>>>>><br>
>>>>> There is a similar fix in upstream
kernel 5.18, before this fix <br>
>>>>> entered the TTM code, this problem
existed in TTM.<br>
>>>>><br>
>>>>> kernel/git/torvalds/linux.git -
Linux kernel source tree <br>
>>>>>
<<a class="moz-txt-link-freetext" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.18-rc3&id=a421ef303008b0ceee2cfc625c3246fa7654b0ca">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.18-rc3&id=a421ef303008b0ceee2cfc625c3246fa7654b0ca</a><br>
>>>>> mm: allow !GFP_KERNEL allocations
for kvmalloc<br>
>>>>><br>
>>>>> Best Regards,<br>
>>>>> Kevin<br>
>>>>><br>
>>>>>
------------------------------------------------------------------------
<br>
>>>>><br>
>>>>> *From:* Koenig, Christian
<a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a> <br>
>>>>> <<a
href="mailto:Christian.Koenig@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:Christian.Koenig@amd.com</a>><br>
>>>>> *Sent:* Wednesday, April 20, 2022
6:53 PM<br>
>>>>> *To:* Wang, Yang(Kevin)
<a class="moz-txt-link-rfc2396E" href="mailto:KevinYang.Wang@amd.com"><KevinYang.Wang@amd.com></a> <br>
>>>>> <<a
href="mailto:KevinYang.Wang@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:KevinYang.Wang@amd.com</a>>;
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>
<br>
>>>>> <<a
href="mailto:dri-devel@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:dri-devel@lists.freedesktop.org</a>>
<br>
>>>>>
<a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a> <br>
>>>>> <<a
href="mailto:dri-devel@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:dri-devel@lists.freedesktop.org</a>>;
<br>
>>>>> <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <br>
>>>>> <<a
href="mailto:amd-gfx@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:amd-gfx@lists.freedesktop.org</a>>
<br>
>>>>>
<a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a> <br>
>>>>> <<a
href="mailto:amd-gfx@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:amd-gfx@lists.freedesktop.org</a>><br>
>>>>> *Subject:* Re: [PATCH] drm/ttm: fix
ttm tt init fail when size <br>
>>>>> exceeds kmalloc limit<br>
>>>>> Am 20.04.22 um 11:07 schrieb Wang,
Yang(Kevin):<br>
>>>>>><br>
>>>>>> [AMD Official Use Only]<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>>
------------------------------------------------------------------------
<br>
>>>>>><br>
>>>>>> *From:* Koenig, Christian
<a class="moz-txt-link-rfc2396E" href="mailto:Christian.Koenig@amd.com"><Christian.Koenig@amd.com></a> <br>
>>>>>> <<a
href="mailto:Christian.Koenig@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:Christian.Koenig@amd.com</a>><br>
>>>>>> *Sent:* Wednesday, April 20,
2022 5:00 PM<br>
>>>>>> *To:* Wang, Yang(Kevin)
<a class="moz-txt-link-rfc2396E" href="mailto:KevinYang.Wang@amd.com"><KevinYang.Wang@amd.com></a> <br>
>>>>>> <<a
href="mailto:KevinYang.Wang@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:KevinYang.Wang@amd.com</a>>;
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>
<br>
>>>>>> <<a
href="mailto:dri-devel@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:dri-devel@lists.freedesktop.org</a>>
<br>
>>>>>>
<a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a> <br>
>>>>>> <<a
href="mailto:dri-devel@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:dri-devel@lists.freedesktop.org</a>>;
<br>
>>>>>> <a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a> <br>
>>>>>> <<a
href="mailto:amd-gfx@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:amd-gfx@lists.freedesktop.org</a>>
<br>
>>>>>>
<a class="moz-txt-link-rfc2396E" href="mailto:amd-gfx@lists.freedesktop.org"><amd-gfx@lists.freedesktop.org></a> <br>
>>>>>> <<a
href="mailto:amd-gfx@lists.freedesktop.org"
data-auth="NotApplicable" moz-do-not-send="true">mailto:amd-gfx@lists.freedesktop.org</a>><br>
>>>>>> *Subject:* Re: [PATCH] drm/ttm:
fix ttm tt init fail when size <br>
>>>>>> exceeds kmalloc limit<br>
>>>>>> Am 20.04.22 um 10:56 schrieb
Yang Wang:<br>
>>>>>> > if the __GFP_ZERO is set,
the kvmalloc() can't fallback to use <br>
>>>>>> vmalloc()<br>
>>>>>><br>
>>>>>> Hui what? Why should kvmalloc()
not be able to fallback to vmalloc()<br>
>>>>>> when __GFP_ZERO is set?<br>
>>>>>><br>
>>>>>> And even that is really the
case then that sounds like a bug in <br>
>>>>>> kvmalloc().<br>
>>>>>><br>
>>>>>> Regards,<br>
>>>>>> Christian.<br>
>>>>>><br>
>>>>>> [kevin]:<br>
>>>>>> it is really test case from
libdrm amdgpu test, which try to <br>
>>>>>> allocate a big BO which will
cause ttm tt init fail.<br>
>>>>><br>
>>>>><br>
>>>>> LOL! Guys, this test case is
intended to fail!<br>
>>>>> *<br>
>>>>> *The test consists of allocating a
buffer so ridiculous large that <br>
>>>>> it should never succeed and be
rejected by the kernel driver.<br>
>>>>><br>
>>>>> This patch here is a really clear
NAK.<br>
>>>>><br>
>>>>> Regards,<br>
>>>>> Christian.<br>
>>>>><br>
>>>>>> it may be a kvmalloc() bug, and
this patch can as a workaround <br>
>>>>>> in ttm before this issue fix.<br>
>>>>>><br>
>>>>>> void *kvmalloc_node(size_t
size, gfp_t flags, int node)<br>
>>>>>> {<br>
>>>>>> ...<br>
>>>>>> if ((flags &
GFP_KERNEL) != GFP_KERNEL)<br>
>>>>>> return
kmalloc_node(size, flags, node);<br>
>>>>>> ...<br>
>>>>>> }<br>
>>>>>><br>
>>>>>> Best Regards,<br>
>>>>>> Kevin<br>
>>>>>><br>
>>>>>> > to allocate memory, when
request size is exceeds kmalloc limit, <br>
>>>>>> it will<br>
>>>>>> > cause allocate memory
fail.<br>
>>>>>> ><br>
>>>>>> > e.g: when ttm want to
create a BO with 1TB size, it maybe fail.<br>
>>>>>> ><br>
>>>>>> > Signed-off-by: Yang Wang
<a class="moz-txt-link-rfc2396E" href="mailto:KevinYang.Wang@amd.com"><KevinYang.Wang@amd.com></a> <br>
>>>>>> <<a
href="mailto:KevinYang.Wang@amd.com"
data-auth="NotApplicable" moz-do-not-send="true">mailto:KevinYang.Wang@amd.com</a>><br>
>>>>>> > ---<br>
>>>>>> >
drivers/gpu/drm/ttm/ttm_tt.c | 14 +++++++++++---<br>
>>>>>> > 1 file changed, 11
insertions(+), 3 deletions(-)<br>
>>>>>> ><br>
>>>>>> > diff --git
a/drivers/gpu/drm/ttm/ttm_tt.c <br>
>>>>>> b/drivers/gpu/drm/ttm/ttm_tt.c<br>
>>>>>> > index
79c870a3bef8..9f2f3e576b8d 100644<br>
>>>>>> > ---
a/drivers/gpu/drm/ttm/ttm_tt.c<br>
>>>>>> > +++
b/drivers/gpu/drm/ttm/ttm_tt.c<br>
>>>>>> > @@ -97,9 +97,12 @@ int
ttm_tt_create(struct ttm_buffer_object <br>
>>>>>> *bo, bool zero_alloc)<br>
>>>>>> > static int
ttm_tt_alloc_page_directory(struct ttm_tt *ttm)<br>
>>>>>> > {<br>
>>>>>> > ttm->pages =
kvmalloc_array(ttm->num_pages, sizeof(void*),<br>
>>>>>> > -
GFP_KERNEL | __GFP_ZERO);<br>
>>>>>> > + GFP_KERNEL);<br>
>>>>>> > if (!ttm->pages)<br>
>>>>>> > return
-ENOMEM;<br>
>>>>>> > +<br>
>>>>>> > +
memset(ttm->pages, 0, ttm->num_pages * sizeof(void
*));<br>
>>>>>> > +<br>
>>>>>> > return 0;<br>
>>>>>> > }<br>
>>>>>> ><br>
>>>>>> > @@ -108,10 +111,12 @@
static int <br>
>>>>>>
ttm_dma_tt_alloc_page_directory(struct ttm_tt *ttm)<br>
>>>>>> > ttm->pages =
kvmalloc_array(ttm->num_pages,<br>
>>>>>> > sizeof(*ttm->pages) +<br>
>>>>>> >
sizeof(*ttm->dma_address),<br>
>>>>>> > - GFP_KERNEL |
__GFP_ZERO);<br>
>>>>>> > + GFP_KERNEL);<br>
>>>>>> > if (!ttm->pages)<br>
>>>>>> > return
-ENOMEM;<br>
>>>>>> ><br>
>>>>>> > +
memset(ttm->pages, 0, ttm->num_pages * <br>
>>>>>> (sizeof(*ttm->pages) +
sizeof(*ttm->dma_address)));<br>
>>>>>> > +<br>
>>>>>> > ttm->dma_address
= (void *)(ttm->pages + ttm->num_pages);<br>
>>>>>> > return 0;<br>
>>>>>> > }<br>
>>>>>> > @@ -120,9 +125,12 @@
static int <br>
>>>>>>
ttm_sg_tt_alloc_page_directory(struct ttm_tt *ttm)<br>
>>>>>> > {<br>
>>>>>> > ttm->dma_address
= kvmalloc_array(ttm->num_pages,<br>
>>>>>> >
sizeof(*ttm->dma_address),<br>
>>>>>> > - GFP_KERNEL |
__GFP_ZERO);<br>
>>>>>> > + GFP_KERNEL);<br>
>>>>>> > if
(!ttm->dma_address)<br>
>>>>>> > return
-ENOMEM;<br>
>>>>>> > +<br>
>>>>>> > +
memset(ttm->dma_address, 0, ttm->num_pages * <br>
>>>>>> sizeof(*ttm->dma_address));<br>
>>>>>> > +<br>
>>>>>> > return 0;<br>
>>>>>> > }<br>
>>>>>> ><br>
>>>>>><br>
>>>>><br>
>>>><br>
>>><br>
>><br>
</div>
</span></font></div>
</div>
</blockquote>
<br>
</body>
</html>