The use of kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid.
Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read().
Cc: "Venkataramanan, Anirudh" anirudh.venkataramanan@intel.com Suggested-by: Ira Weiny ira.weiny@intel.com Signed-off-by: Fabio M. De Francesco fmdefrancesco@gmail.com --- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index d33fec488713..bdb4c0e0736b 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -869,11 +869,11 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char __user *buf,
page = rdev->gart.pages[p]; if (page) { - ptr = kmap(page); + ptr = kmap_local_page(page); ptr += off;
r = copy_to_user(buf, ptr, cur_size); - kunmap(rdev->gart.pages[p]); + kunmap_local(ptr); } else r = clear_user(buf, cur_size);
On Thu, Oct 13, 2022 at 11:07:14PM +0200, Fabio M. De Francesco wrote:
The use of kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid.
Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read().
Cc: "Venkataramanan, Anirudh" anirudh.venkataramanan@intel.com Suggested-by: Ira Weiny ira.weiny@intel.com Signed-off-by: Fabio M. De Francesco fmdefrancesco@gmail.com
Reviewed-by: Kees Cook keescook@chromium.org
Am 13.10.22 um 23:07 schrieb Fabio M. De Francesco:
The use of kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid.
Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read().
Cc: "Venkataramanan, Anirudh" anirudh.venkataramanan@intel.com Suggested-by: Ira Weiny ira.weiny@intel.com Signed-off-by: Fabio M. De Francesco fmdefrancesco@gmail.com
Reviewed-by: Christian König christian.koenig@amd.com
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index d33fec488713..bdb4c0e0736b 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -869,11 +869,11 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char __user *buf, page = rdev->gart.pages[p]; if (page) {
ptr = kmap(page);
ptr = kmap_local_page(page); ptr += off;r = copy_to_user(buf, ptr, cur_size);
kunmap(rdev->gart.pages[p]);
kunmap_local(ptr);
Applied. Thanks!
On Fri, Oct 14, 2022 at 3:03 AM Christian König christian.koenig@amd.com wrote:
Am 13.10.22 um 23:07 schrieb Fabio M. De Francesco:
The use of kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as the mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available.
With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and still valid.
Therefore, replace kmap() with kmap_local_page() in radeon_ttm_gtt_read().
Cc: "Venkataramanan, Anirudh" anirudh.venkataramanan@intel.com Suggested-by: Ira Weiny ira.weiny@intel.com Signed-off-by: Fabio M. De Francesco fmdefrancesco@gmail.com
Reviewed-by: Christian König christian.koenig@amd.com
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index d33fec488713..bdb4c0e0736b 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -869,11 +869,11 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char __user *buf,
page = rdev->gart.pages[p]; if (page) {
ptr = kmap(page);
ptr = kmap_local_page(page); ptr += off; r = copy_to_user(buf, ptr, cur_size);
kunmap(rdev->gart.pages[p]);
kunmap_local(ptr); } else r = clear_user(buf, cur_size);
On lunedì 17 ottobre 2022 18:52:10 CET Alex Deucher wrote:
Applied. Thanks!
Many thanks to you!
However, about a week ago, I received a report saying that this patch is "Not Applicable".
That email was also referring to another patch, for which I'll reply in its own thread.
That report has a link to https://patchwork.linuxtv.org/project/linux-media/ patch/20221013210714.16320-1-fmdefrancesco@gmail.com/
Can you please let me understand why, despite it was applied, this patch later shifted "State" to "Not Applicable"?
Thanks,
Fabio
On Wed, Nov 02, 2022 at 12:11:53AM +0100, Fabio M. De Francesco wrote:
On lunedì 17 ottobre 2022 18:52:10 CET Alex Deucher wrote:
Applied. Thanks!
Many thanks to you!
However, about a week ago, I received a report saying that this patch is "Not Applicable".
That email was also referring to another patch, for which I'll reply in its own thread.
That report has a link to https://patchwork.linuxtv.org/project/linux-media/ patch/20221013210714.16320-1-fmdefrancesco@gmail.com/
Can you please let me understand why, despite it was applied, this patch later shifted "State" to "Not Applicable"?
The kernel has multiple patchwork instances, so you got an "N/A" from linux-media, but it was applied to the drm tree. (Yes, confusing. :P)
linaro-mm-sig@lists.linaro.org
-
Alex Deucher -
Christian König -
Fabio M. De Francesco -
Kees Cook