Re: Linux Kernel build bug with AMD_IOMMU_V2=M and HSA_AMD=Y

This should have been fixed by this commit in amd-staging-drm-next: https://lore.kernel.org/patchwork/patch/1392368/ commit b8aff1f3a0b3d8434f8ccf5d3017137c29aca77b Author: Felix Kuehling Date: Mon Mar 8 22:15:42 2021 -0500 drm/amdkfd: fix build error with AMD_IOMMU_V2=m Using

Re: [PATCH] drm/amdkfd: dqm fence memory corruption

Am 2021-03-26 um 5:38 a.m. schrieb Qu Huang: > On 2021/1/28 5:50, Felix Kuehling wrote: >> Am 2021-01-27 um 7:33 a.m. schrieb Qu Huang: >>> Amdgpu driver uses 4-byte data type as DQM fence memory, >>> and transmits GPU address of fence memory to microcode >>&

Re: [PATCH] drm/amdkfd: Fix cat debugfs hang_hws file causes system crash bug

Am 2021-03-23 um 10:56 a.m. schrieb Alex Deucher: > Applied. Thanks! Thanks. I thought we fixed this before by making the file write-only. But I guess that's not sufficient to stop root from reading it: commit 2bdac179e217a0c0b548a8c60524977586621b19 Author: Felix Kuehling Date: Thu Dec

Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages

This caused a regression in kfdtest in a large-buffer stress test after memory allocation for user pages fails: [17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16 [17359.543746] BUG: kernel NULL pointer dereference, address: [17359.551494] #PF: supervisor

Re: [PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

On 2021-03-09 11:50 a.m., Felix Kuehling wrote: Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link against the exported functions. If the GPU driver is built-in but the IOMMU driver is a loadable module, the kfd_iommu.c file is indeed built but does not work: x86_64-linux-ld

[PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

by the amdkfd driver. Output a warning if they are not, because that may not be what the user was expecting. Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional") Reported-by: Arnd Bergmann Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_i

Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

Am 2021-03-09 um 3:58 a.m. schrieb Arnd Bergmann: > On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote: >> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link >> against the exported functions. If the GPU driver is built-in but the >> IOMMU driver

[PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

by the amdkfd driver. Output a warning if they are not, because that may not be what the user was expecting. Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional") Reported-by: Arnd Bergmann Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_io

Re: [PATCH] [variant b] drm/amdkfd: fix build error with missing AMD_IOMMU_V2

Am 2021-03-08 um 3:45 p.m. schrieb Arnd Bergmann: > From: Arnd Bergmann > > Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link > against the exported functions. If the GPU driver is built-in but the > IOMMU driver is a loadable module, the kfd_iommu.c file is indeed > built

Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2

Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann: > On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote: >> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: >>> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling >>> wrote: >>>> The driver build should work

Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2

Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann: > On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote: >> The driver build should work without IOMMUv2. In amdkfd/Makefile, we >> have this condition: >> >> ifneq ($(CONFIG_AMD_IOMMU_V2),) >> AMDKFD_FILES += $(

Re: [PATCH] drm/amdkfd: fix build error with missing AMD_IOMMU_V2

The driver build should work without IOMMUv2. In amdkfd/Makefile, we have this condition: ifneq ($(CONFIG_AMD_IOMMU_V2),) AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o endif In amdkfd/kfd_iommu.h we define inline stubs of the functions that are causing your link-failures if IOMMU_V2 is not enabled:

Re: [PATCH] drm/amdkfd: dqm fence memory corruption

Am 2021-01-27 um 7:33 a.m. schrieb Qu Huang: > Amdgpu driver uses 4-byte data type as DQM fence memory, > and transmits GPU address of fence memory to microcode > through query status PM4 message. However, query status > PM4 message definition and microcode processing are all > processed according

Re: [PATCH v2] drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu()

ting to out-of-bounds memory. > > Fixes: b7b6c38529c9 ("drm/amdkfd: Calculate CPU VCRAT size dynamically (v2)") > Suggested-by: Felix Kuehling > Signed-off-by: Jeremy Cline Thanks. I'll apply this patch. Reviewed-by: Felix Kuehling > --- > drivers/gpu/drm/amd/amdkf

Re: [PATCH] drm/amdkfd: Fix out-of-bounds read in kdf_create_vcrat_image_cpu()

Am 2021-01-08 um 11:31 a.m. schrieb Jeremy Cline: > KASAN reported a slab-out-of-bounds read of size 1 in > kdf_create_vcrat_image_cpu(). > > This occurs when, for example, when on an x86_64 with a single NUMA node > because kfd_fill_iolink_info_for_cpu() is a no-op, but afterwards the >

Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

ack     function if CRAT is broken.     v5: refine acpi crat good but no iommu support case, and rename the     title.     v6: fix the issue of dGPU initialized firstly, just modify the report     value in the node_show().     Signed-off-by: Huang Rui     Reviewed-by: Felix Kuehling    

Re: [PATCH v3 1/2] drm/amdkfd: Move the ignore_crat check before the CRAT table get

Am 2020-11-12 um 10:11 p.m. schrieb Hanjun Guo: > If the ignore_crat is set to non-zero value, it's no point getting > the CRAT table, so just move the ignore_crat check before we get the > CRAT table. > > Signed-off-by: Hanjun Guo Thank you! I applied the patches. Regards,   Felix > --- >

Re: [PATCH] drm/amdkfd: replace idr_init() by idr_init_base()

On 2020-11-04 10:13 a.m., Deepak R Varma wrote: idr_init() uses base 0 which is an invalid identifier. The new function idr_init_base allows IDR to set the ID lookup from base 1. This avoids all lookups that otherwise starts from 0 since 0 is always unused. I disagree. We call idr_alloc with

Re: [PATCH v2 -next] drm/amdkfd: Fix -Wunused-const-variable warning

ven_device_info = { > ^ > > As Huang Rui suggested, Raven already has the fallback path, > so it should be out of IOMMU v2 flag. > > Suggested-by: Huang Rui > Signed-off-by: YueHaibing Reviewed-by: Felix Kuehling I applied yo

Re: [PATCH 0/2] iommu/amd: Fix IOMMUv2 devices when SME is active

tialize on Raven when SME is active? There is a global >> checking function for that, so that shouldn't be hard to do. >> > Sure. How about the attached patch? The patch is Acked-by: Felix Kuehling Thanks,   Felix > > Alex >

Re: [PATCH 0/2] iommu/amd: Fix IOMMUv2 devices when SME is active

Am 2020-08-28 um 9:46 a.m. schrieb jroe...@suse.de: > On Wed, Aug 26, 2020 at 03:25:58PM +, Deucher, Alexander wrote: >>> Alex, do you know if anyone has tested amdgpu on an APU with SME >>> enabled? Is this considered something we support? >> It's not something we've tested. I'm not even

Re: [PATCH v2 1/2] drm/amdkfd: Move the ignore_crat check before the CRAT table get

Am 2020-08-26 um 4:29 a.m. schrieb Hanjun Guo: > If the ignore_crat is set to non-zero value, it's no point getting > the CRAT table, so just move the ignore_crat check before we get the > CRAT table. > > Signed-off-by: Hanjun Guo > --- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +- >

Re: [PATCH 0/2] iommu/amd: Fix IOMMUv2 devices when SME is active

[+Ray] Thanks for the heads up. Currently KFD won't work on APUs when IOMMUv2 is disabled. But Ray is working on fallbacks that will allow KFD to work on APUs even without IOMMUv2, similar to our dGPUs. Along with changes in ROCm user mode, those fallbacks are necessary for making ROCm on APUs

Re: [PATCH] drm/amdkfd: Put ACPI table after using it

Hi Hanjun, Sorry for the late reply. Thank you for the patch and the explanation. This seems to have been broken since the first version of KFD in 2014. See one suggestion inline. Am 2020-07-22 um 5:48 a.m. schrieb Hanjun Guo: > The acpi_get_table() should be coupled with acpi_put_table() if >

Re: [PATCH v5 01/12] iommu: Change type of pasid to u32

Am 2020-07-02 um 3:10 p.m. schrieb Fenghua Yu: > Hi, Felix, Thomas, Joerg and maintainers, > > On Tue, Jun 30, 2020 at 10:12:38PM -0400, Felix Kuehling wrote: >> Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu: >> You didn't change the return types of amdgpu_pasid_alloc a

Re: [PATCH v5 01/12] iommu: Change type of pasid to u32

Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu: > PASID is defined as a few different types in iommu including "int", > "u32", and "unsigned int". To be consistent and to match with uapi > definitions, define PASID and its variations (e.g. max PASID) as "u32". > "u32" is also shorter and a little

Re: [PATCH v2] drm/amd: fix potential memleak in err branch

anch this memory not free. If use > kmemleak, this path maybe catched. > These changes are to add kobject_put in kobject_init_and_add > failed branch, fix potential memleak. > > Signed-off-by: Bernard Zhao The patch is Reviewed-by: Felix Kuehling I'll apply it to amd-staging-drm-

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter: > On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote: >> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: >>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: >>>>> I still have my doubts

Re: [PATCH] drm/amd: fix potential memleak in err branch

Hi Bernard, I just applied a patch from another contributor for the kfd_topology part of this. See https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next=fc0fe8138309fee303bd12991f12b23f01bbf58c Please rebase your patch on that. I believe that should only leave the fixes in

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

Am 2020-06-19 um 3:55 p.m. schrieb Jason Gunthorpe: > On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote: >> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe: >>> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote: >>>> On Fri, Jun 19, 2

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe: > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote: >> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote: >>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote: >>> The madness is only that device B's

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher: > On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote: >> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote: >>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote: >>> The madness is only that device B's mmu

Re: [PATCH] drm/amdkfd: Fix reference count leaks.

is Reviewed-by: Felix Kuehling I'm applying the patch to our amd-staging-drm-next branch. Regards,   Felix --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: >>> I still have my doubts about allowing fence waiting from within shrinkers. >>> IMO ideally they should use a trywait approach, in order to allow memory >>> allocation during

Re: [PATCH][next] drm/amdkfd: fix a dereference of pdd before it is null checked

check") Fixes: 522b89c63370 ("drm/amdkfd: Track SDMA utilization per process") Signed-off-by: Colin Ian King Reviewed-by: Felix Kuehling I applied the patch to our internal amd-staging-drm-next. Regards,   Felix --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +++--

Re: [PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

ee one comment inline. With that fixed, the patch is Reviewed-by: Felix Kuehling > --- > drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++-- > 1 file changed, 19 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c > b/driv

Re: [PATCH] drm/amdkfd: fix typing in (*hqd_destroy)

the same. Anyway, this patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> > --- > drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h > b/d

Re: [PATCH] drm/amdkfd: fix typing in (*hqd_destroy)

his by using 'enum kfd_preempt_type' for (*hqd_destroy) too. > > Signed-off-by: Luc Van Oostenryck Interesting. I'm surprised I never saw a compiler warning about a function pointer type mismatch. I guess C isn't picky about integer types as long as the size is the same. Anyway, this patch is Rev

Re: AMD graphics performance regression in 4.15 and later

[+Philip] On 2018-04-20 10:47 AM, Michel Dänzer wrote: > On 2018-04-11 11:37 AM, Christian König wrote: >> Am 11.04.2018 um 06:00 schrieb Gabriel C: >>> 2018-04-09 11:42 GMT+02:00 Christian König >>> : Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: > Hi

Re: AMD graphics performance regression in 4.15 and later

[+Philip] On 2018-04-20 10:47 AM, Michel Dänzer wrote: > On 2018-04-11 11:37 AM, Christian König wrote: >> Am 11.04.2018 um 06:00 schrieb Gabriel C: >>> 2018-04-09 11:42 GMT+02:00 Christian König >>> : Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: > Hi Christian, > > Thanks for

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

same patch [1] and its still required. > > Cheers, > Anders > [1] https://patchwork.kernel.org/patch/10340885/ Yes, looks good. I think this probably broke when we relaxed the dependency on iommuv2. Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix > >&

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

ned-off-by: Arnd Bergmann >> >> Acked-by: Christian König , but I would wait on >> what Felix says to that. > Tested-by: Anders Roxell > > Randy sent the same patch [1] and its still required. > > Cheers, > Anders > [1] https://patchwork.kernel.org/patch/1034088

Re: [PATCHv2] drm/amdkfd: Remove vla

sizeof(uint32_t))]; > + if (dev->device_info->ih_ring_entry_size > (8 * sizeof(uint32_t))) { > + dev_err(kfd_chardev(), "Ring entry too small\n"); When the ring entry size really is too small, this will potentially flood the kernel log. Maybe a

Re: [PATCHv2] drm/amdkfd: Remove vla

uint32_t))]; > + if (dev->device_info->ih_ring_entry_size > (8 * sizeof(uint32_t))) { > + dev_err(kfd_chardev(), "Ring entry too small\n"); When the ring entry size really is too small, this will potentially flood the kernel log. Maybe a WARN_ONCE would be more h

Re: [PATCH] drm/amdkfd: Remove vla

Thanks Christian for catching that. I'm working on a patch series to upstream Vega10 support, about 95% done. It will add this ASIC info for Vega10: static const struct kfd_device_info vega10_device_info = { .asic_family = CHIP_VEGA10, .max_pasid_bits = 16, .max_no_of_hqd

Re: [PATCH] drm/amdkfd: Remove vla

Thanks Christian for catching that. I'm working on a patch series to upstream Vega10 support, about 95% done. It will add this ASIC info for Vega10: static const struct kfd_device_info vega10_device_info = { .asic_family = CHIP_VEGA10, .max_pasid_bits = 16, .max_no_of_hqd

Re: [PATCH -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

This patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> On 2018-03-29 10:25 PM, Wei Yongjun wrote: > Fixes the following sparse warning: > > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning: > symbol 'kfd_dev_is_large_bar' was not declared. Should it be stat

Re: [PATCH -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

This patch is Reviewed-by: Felix Kuehling On 2018-03-29 10:25 PM, Wei Yongjun wrote: > Fixes the following sparse warning: > > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning: > symbol 'kfd_dev_is_large_bar' was not declared. Should it be static? > > Signed-o

Re: [PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

Thanks for catching that. I'd use -ENODEV to match what is done a few lines below for peer_pdd. With that fixed, this patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix On 2018-03-29 10:25 PM, Wei Yongjun wrote: > Passing NULL pointer to PTR_ERR will result

Re: [PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

Thanks for catching that. I'd use -ENODEV to match what is done a few lines below for peer_pdd. With that fixed, this patch is Reviewed-by: Felix Kuehling Regards,   Felix On 2018-03-29 10:25 PM, Wei Yongjun wrote: > Passing NULL pointer to PTR_ERR will result in return value of 0 > indi

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Looks good. This change is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards,   Felix On 2018-01-18 07:39 PM, Gustavo A. R. Silva wrote: > Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element. > > This issue was detected with the help of Coccinelle.

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Looks good. This change is Reviewed-by: Felix Kuehling Regards,   Felix On 2018-01-18 07:39 PM, Gustavo A. R. Silva wrote: > Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gust

Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences

Yeah, this looks good to me. Regards,   Felix On 2018-01-10 04:58 PM, Gustavo A. R. Silva wrote: > Hi Felix, > > Quoting Felix Kuehling <felix.kuehl...@amd.com>: > >> Hi Gustavo, >> >> Thanks for catching that. When returning a fault, I think you also need &g

Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences

Yeah, this looks good to me. Regards,   Felix On 2018-01-10 04:58 PM, Gustavo A. R. Silva wrote: > Hi Felix, > > Quoting Felix Kuehling : > >> Hi Gustavo, >> >> Thanks for catching that. When returning a fault, I think you also need >> to srcu_read_unlock(

Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences

Hi Gustavo, Thanks for catching that. When returning a fault, I think you also need to srcu_read_unlock(_processes_srcu, idx). However, instead of returning an error, I think I'd prefer to skip PDDs that can't be found with continue statements. That way others would still suspend and resume

Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences

Hi Gustavo, Thanks for catching that. When returning a fault, I think you also need to srcu_read_unlock(_processes_srcu, idx). However, instead of returning an error, I think I'd prefer to skip PDDs that can't be found with continue statements. That way others would still suspend and resume

Re: [PATCH] drm/amdgpu: use %pap format string for phys_addr_t

This commit is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Thanks,   Felix On 2018-01-08 07:53 AM, Arnd Bergmann wrote: > The newly added get_local_mem_info() function prints a phys_addr_t > using 0x%llx, which is wrong on most 32-bit systems, as shown by > this warni

Re: [PATCH] drm/amdgpu: use %pap format string for phys_addr_t

This commit is Reviewed-by: Felix Kuehling Thanks,   Felix On 2018-01-08 07:53 AM, Arnd Bergmann wrote: > The newly added get_local_mem_info() function prints a phys_addr_t > using 0x%llx, which is wrong on most 32-bit systems, as shown by > this warning: > > drivers/gpu

Re: [PATCH 1/3] drm/amdgpu/display: provide ASSERT macros unconditionally

On 2017-11-02 07:26 AM, Arnd Bergmann wrote: > It seems impossible to build this driver without setting either > CONFIG_DEBUG_KERNEL or CONFIG_DEBUG_DRIVER: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h: In function > 'set_reg_field_value_ex': >

Re: [PATCH 1/3] drm/amdgpu/display: provide ASSERT macros unconditionally

On 2017-11-02 07:26 AM, Arnd Bergmann wrote: > It seems impossible to build this driver without setting either > CONFIG_DEBUG_KERNEL or CONFIG_DEBUG_DRIVER: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h: In function > 'set_reg_field_value_ex': >

Re: arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'

Looks like we need to include sched.h before mmu_context.h to make the Alpha build happy. Regards,   Felix On 2017-09-16 09:50 PM, kbuild test robot wrote: > Hi Felix, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >

Re: arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'

Looks like we need to include sched.h before mmu_context.h to make the Alpha build happy. Regards,   Felix On 2017-09-16 09:50 PM, kbuild test robot wrote: > Hi Felix, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >

Re: [PATCH] lib: Closed hash table with low overhead

On 2017-09-15 05:14 PM, Andrew Morton wrote: > On Mon, 28 Aug 2017 21:53:10 -0400 Felix Kuehling <felix.kuehl...@amd.com> > wrote: > >> This adds a statically sized closed hash table implementation with >> low memory and CPU overhead. The API is inspired by kfifo

Re: [PATCH] lib: Closed hash table with low overhead

On 2017-09-15 05:14 PM, Andrew Morton wrote: > On Mon, 28 Aug 2017 21:53:10 -0400 Felix Kuehling > wrote: > >> This adds a statically sized closed hash table implementation with >> low memory and CPU overhead. The API is inspired by kfifo. >> >> Storing,

[PATCH] lib: Closed hash table with low overhead

and entries relocated to speed up future lookups. Signed-off-by: Felix Kuehling <felix.kuehl...@amd.com> Acked-by: Christian König <christian.koe...@amd.com> --- This is part of a larger patch series I'm working on to support demand-paging on AMD Vega10 and similar AMD GPUs. Vega10 generates a f

[PATCH] lib: Closed hash table with low overhead

and entries relocated to speed up future lookups. Signed-off-by: Felix Kuehling Acked-by: Christian König --- This is part of a larger patch series I'm working on to support demand-paging on AMD Vega10 and similar AMD GPUs. Vega10 generates a flood of page fault events in its interrupt ring buffer

Re: [PATCH][drm-next] drm/amdgpu: remove duplicate return statement

I must have added that accidentally when cherry-picking an internal patch for upstreaming. Thanks for catching it. Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> Regards, Felix On 2017-08-23 09:17 AM, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com

Re: [PATCH][drm-next] drm/amdgpu: remove duplicate return statement

I must have added that accidentally when cherry-picking an internal patch for upstreaming. Thanks for catching it. Reviewed-by: Felix Kuehling Regards, Felix On 2017-08-23 09:17 AM, Colin King wrote: > From: Colin Ian King > > Remove a redundant identical return statement, it h

[PATCH] kernel: Export mm_access

access policies. Signed-off-by: Harish Kasiviswanathan <harish.kasiviswanat...@amd.com> Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> --- Current KFD with AMD discrete GPU support is not yet upstream, but we are working on getting it upstream for 4.13 or 4.14 depending on how we

[PATCH] kernel: Export mm_access

Kasiviswanathan Reviewed-by: Felix Kuehling --- Current KFD with AMD discrete GPU support is not yet upstream, but we are working on getting it upstream for 4.13 or 4.14 depending on how we line up with Dave Airlie's merge windows. For reference, recent releases of ROCm (AMD's Radeon Open Compute

Re: Enabling peer to peer device transactions for PCIe devices

On 16-11-25 12:20 PM, Serguei Sagalovitch wrote: > >> A white list may end up being rather complicated if it has to cover >> different CPU generations and system architectures. I feel this is a >> decision user space could easily make. >> >> Logan > I agreed that it is better to leave up to user

Re: Enabling peer to peer device transactions for PCIe devices

On 16-11-25 12:20 PM, Serguei Sagalovitch wrote: > >> A white list may end up being rather complicated if it has to cover >> different CPU generations and system architectures. I feel this is a >> decision user space could easily make. >> >> Logan > I agreed that it is better to leave up to user

Re: Enabling peer to peer device transactions for PCIe devices

On 16-11-25 03:40 PM, Christian König wrote: > Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe: >> This assumes the commands are fairly short lived of course, the >> expectation of the mmu notifiers is that a flush is reasonably prompt > > Correct, this is another problem. GFX command submissions

Re: Enabling peer to peer device transactions for PCIe devices

On 16-11-25 03:40 PM, Christian König wrote: > Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe: >> This assumes the commands are fairly short lived of course, the >> expectation of the mmu notifiers is that a flush is reasonably prompt > > Correct, this is another problem. GFX command submissions

Re: Lockdep incorrectly complaining about circular dependencies involving read-locks

On 16-01-21 05:20 PM, Felix Kuehling wrote: > I'm running into circular lock dependencies reported by lockdep that > involve read-locks and should not be flagged as deadlocks at all. I > wrote a very simple test function that demonstrates the problem: [snip] > It sets up a circular loc

Re: Lockdep incorrectly complaining about circular dependencies involving read-locks

On 16-01-21 05:20 PM, Felix Kuehling wrote: > I'm running into circular lock dependencies reported by lockdep that > involve read-locks and should not be flagged as deadlocks at all. I > wrote a very simple test function that demonstrates the problem: [snip] > It sets up a circular loc

Lockdep incorrectly complaining about circular dependencies involving read-locks

I'm running into circular lock dependencies reported by lockdep that involve read-locks and should not be flagged as deadlocks at all. I wrote a very simple test function that demonstrates the problem: > static void test_lockdep(void) > { > struct mutex fktest_m; > struct rw_semaphore

Lockdep incorrectly complaining about circular dependencies involving read-locks

I'm running into circular lock dependencies reported by lockdep that involve read-locks and should not be flagged as deadlocks at all. I wrote a very simple test function that demonstrates the problem: > static void test_lockdep(void) > { > struct mutex fktest_m; > struct rw_semaphore