On 2019-10-11 4:40 a.m., Christian König wrote:
> Am 03.10.19 um 21:44 schrieb Yang, Philip:
>> user_pages array should always be freed after validation regardless if
>> user pages are changed after bo is created because with HMM change parse
>> bo always allocate user pages array to get user pag
Am 03.10.19 um 21:44 schrieb Yang, Philip:
user_pages array should always be freed after validation regardless if
user pages are changed after bo is created because with HMM change parse
bo always allocate user pages array to get user pages for userptr bo.
Don't need to get user pages while crea
Thanks for looking at this Christian. Let me know if there's anything I
can do to help.
In the meantime, is there a workaround to avoid the memory leak other than
using a kernel from before the HMM change?
Thanks,
-Joe
On Fri, Oct 4, 2019 at 8:02 AM Koenig, Christian
wrote:
> Hi Philip,
>
> A
Hi Philip,
Am 04.10.19 um 15:40 schrieb Yang, Philip:
> Thanks Joe for the test, I will add your Tested-by.
>
> Hi Christian,
>
> May you help review? The change removes the get user pages from
> gem_userptr_ioctl, this was done if flags AMDGPU_GEM_USERPTR_VALIDATE is
> set, and delay the get user
Thanks Joe for the test, I will add your Tested-by.
Hi Christian,
May you help review? The change removes the get user pages from
gem_userptr_ioctl, this was done if flags AMDGPU_GEM_USERPTR_VALIDATE is
set, and delay the get user pages to amdgpu_cs_parser_bos, and check if
user pages are inva
I've tested applying v2 of this patch against a v5.3 tagged kernel and it
appears to fix the issue I reported.
Thanks,
-Joe
On Thu, Oct 3, 2019 at 12:07 PM Yang, Philip wrote:
> user_pages array should be freed regardless if user pages are
> invalidated after bo is created because HMM change to