* [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-14 19:40 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-14 19:40 UTC (permalink / raw)
To: intel-gfx, dri-devel, amd-gfx
Cc: alexander.deucher, Arunpravin, matthew.auld, christian.koenig
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-14 19:40 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-14 19:40 UTC (permalink / raw)
To: intel-gfx, dri-devel, amd-gfx
Cc: alexander.deucher, Arunpravin, matthew.auld, christian.koenig
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-14 19:40 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-14 19:40 UTC (permalink / raw)
To: intel-gfx, dri-devel, amd-gfx
Cc: alexander.deucher, Arunpravin, matthew.auld, daniel, christian.koenig
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
- if (order-- == min_order) {
+ if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
--
2.25.1
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix a infinite loop condition when order becomes 0
2022-03-14 19:40 ` [Intel-gfx] " Arunpravin
(?)
(?)
@ 2022-03-15 1:11 ` Patchwork
-1 siblings, 0 replies; 32+ messages in thread
From: Patchwork @ 2022-03-15 1:11 UTC (permalink / raw)
To: Arunpravin; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 7386 bytes --]
== Series Details ==
Series: drm: Fix a infinite loop condition when order becomes 0
URL : https://patchwork.freedesktop.org/series/101360/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363 -> Patchwork_22563
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/index.html
Participating hosts (48 -> 44)
------------------------------
Additional (2): bat-adlm-1 fi-kbl-8809g
Missing (6): fi-hsw-4200u fi-bsw-cyan fi-icl-u2 fi-kbl-guc fi-ctg-p8600 fi-bdw-samus
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22563:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ringfill@basic-all:
- {bat-dg2-9}: [PASS][1] -> [DMESG-WARN][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/bat-dg2-9/igt@gem_ringfill@basic-all.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-dg2-9/igt@gem_ringfill@basic-all.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [PASS][3] -> [DMESG-WARN][4] +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/bat-adlp-6/igt@kms_busy@basic@flip.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-adlp-6/igt@kms_busy@basic@flip.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- {bat-adlm-1}: NOTRUN -> [INCOMPLETE][5]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-adlm-1/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html
Known issues
------------
Here are the changes found in Patchwork_22563 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-8809g: NOTRUN -> [DMESG-WARN][6] ([i915#4962]) +1 similar issue
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-kbl-8809g/igt@gem_exec_suspend@basic-s0@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-kbl-8809g/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-kbl-8809g/igt@gem_lmem_swapping@random-engines.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-8809g: NOTRUN -> [SKIP][9] ([fdo#109271]) +55 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-kbl-8809g/igt@i915_pm_rpm@basic-rte.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-6: [PASS][10] -> [FAIL][11] ([i915#4032])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/bat-dg1-6/igt@i915_pm_rps@basic-api.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-dg1-6/igt@i915_pm_rps@basic-api.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-8809g: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-kbl-8809g/igt@kms_chamelium@hdmi-edid-read.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
- fi-bwr-2160: [PASS][13] -> [FAIL][14] ([i915#2122])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-8809g: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/fi-kbl-8809g/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
#### Possible fixes ####
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: [FAIL][16] ([i915#5323]) -> [PASS][17]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/bat-rpls-2/igt@i915_pm_rpm@module-reload.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-rpls-2/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live@gt_engines:
- {bat-rpls-2}: [DMESG-WARN][18] ([i915#4391]) -> [PASS][19] +2 similar issues
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/bat-rpls-2/igt@i915_selftest@live@gt_engines.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-rpls-2/igt@i915_selftest@live@gt_engines.html
* igt@kms_busy@basic@modeset:
- {bat-adlp-6}: [DMESG-WARN][20] -> [PASS][21]
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/bat-adlp-6/igt@kms_busy@basic@modeset.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/bat-adlp-6/igt@kms_busy@basic@modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#4032]: https://gitlab.freedesktop.org/drm/intel/issues/4032
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4962]: https://gitlab.freedesktop.org/drm/intel/issues/4962
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#5323]: https://gitlab.freedesktop.org/drm/intel/issues/5323
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* Linux: CI_DRM_11363 -> Patchwork_22563
CI-20190529: 20190529
CI_DRM_11363: a7b049602879c25e8d54c3f547d3cdad03230e5b @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6380: 5d9ef79ab61fc4e9abc8b565f298e0515265e616 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22563: 5365678b71828461ff1f25cf91cbd6d7361a384a @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5365678b7182 drm: Fix a infinite loop condition when order becomes 0
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/index.html
[-- Attachment #2: Type: text/html, Size: 7748 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Fix a infinite loop condition when order becomes 0
2022-03-14 19:40 ` [Intel-gfx] " Arunpravin
` (2 preceding siblings ...)
(?)
@ 2022-03-15 5:36 ` Patchwork
-1 siblings, 0 replies; 32+ messages in thread
From: Patchwork @ 2022-03-15 5:36 UTC (permalink / raw)
To: Arunpravin; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30279 bytes --]
== Series Details ==
Series: drm: Fix a infinite loop condition when order becomes 0
URL : https://patchwork.freedesktop.org/series/101360/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22563_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_22563_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22563_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
------------------------------
Missing (1): shard-dg1
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22563_full:
### IGT changes ###
#### Possible regressions ####
* igt@i915_pm_dc@dc5-psr:
- shard-skl: NOTRUN -> [CRASH][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@i915_pm_dc@dc5-psr.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_softpin@allocator-evict@rcs0:
- {shard-rkl}: [PASS][2] -> [INCOMPLETE][3]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-1/igt@gem_softpin@allocator-evict@rcs0.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/igt@gem_softpin@allocator-evict@rcs0.html
* igt@gem_userptr_blits@create-destroy-sync:
- {shard-rkl}: ([PASS][4], [PASS][5]) -> [DMESG-FAIL][6]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/igt@gem_userptr_blits@create-destroy-sync.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-2/igt@gem_userptr_blits@create-destroy-sync.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/igt@gem_userptr_blits@create-destroy-sync.html
Known issues
------------
Here are the changes found in Patchwork_22563_full that come from known issues:
### CI changes ###
#### Possible fixes ####
* boot:
- {shard-rkl}: ([PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [FAIL][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) ([i915#5131]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/boot.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/boot.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/boot.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/boot.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/boot.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/boot.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/boot.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/boot.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-2/boot.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-2/boot.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-2/boot.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-1/boot.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-1/boot.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-1/boot.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/boot.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/boot.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/boot.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/boot.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/boot.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/boot.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/boot.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/boot.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/boot.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/boot.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-4/boot.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-2/boot.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-2/boot.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-2/boot.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/boot.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/boot.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/boot.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/boot.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/boot.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/boot.html
### IGT changes ###
#### Issues hit ####
* igt@gem_ccs@block-copy-compressed:
- shard-tglb: NOTRUN -> [SKIP][48] ([i915#5325])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-tglb2/igt@gem_ccs@block-copy-compressed.html
* igt@gem_create@create-massive:
- shard-skl: NOTRUN -> [DMESG-WARN][49] ([i915#4991])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl1/igt@gem_create@create-massive.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][50] -> [FAIL][51] ([i915#232])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-tglb6/igt@gem_eio@kms.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-tglb2/igt@gem_eio@kms.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: [PASS][52] -> [INCOMPLETE][53] ([i915#4547])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-skl6/igt@gem_exec_capture@pi@rcs0.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl7/igt@gem_exec_capture@pi@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][54] -> [FAIL][55] ([i915#2846])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-glk1/igt@gem_exec_fair@basic-deadline.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-glk8/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][56] -> [FAIL][57] ([i915#2842])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-tglb8/igt@gem_exec_fair@basic-flow@rcs0.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][58] ([i915#2842])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb1/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][59] -> [FAIL][60] ([i915#2842]) +1 similar issue
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-kbl6/igt@gem_exec_fair@basic-pace@vecs0.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html
- shard-iclb: [PASS][61] -> [FAIL][62] ([i915#2842])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb8/igt@gem_exec_fair@basic-pace@vecs0.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb5/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][63] ([fdo#109271] / [i915#2190])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl1/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#4613])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl7/igt@gem_lmem_swapping@heavy-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-skl: NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#4613]) +2 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@gem_lmem_swapping@parallel-random-engines.html
* igt@gem_pxp@create-protected-buffer:
- shard-iclb: NOTRUN -> [SKIP][66] ([i915#4270])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@gem_pxp@create-protected-buffer.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][67] -> [FAIL][68] ([i915#454])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb5/igt@i915_pm_dc@dc6-psr.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
- shard-skl: [PASS][69] -> [FAIL][70] ([i915#454])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-skl8/igt@i915_pm_dc@dc6-psr.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl1/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_dc@dc9-dpms:
- shard-iclb: [PASS][71] -> [SKIP][72] ([i915#4281])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb6/igt@i915_pm_dc@dc9-dpms.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb3/igt@i915_pm_dc@dc9-dpms.html
* igt@i915_pm_rpm@system-suspend:
- shard-kbl: [PASS][73] -> [INCOMPLETE][74] ([i915#151])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-kbl6/igt@i915_pm_rpm@system-suspend.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-kbl4/igt@i915_pm_rpm@system-suspend.html
* igt@kms_big_fb@4-tiled-32bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][75] ([i915#5286])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_big_fb@4-tiled-32bpp-rotate-270.html
* igt@kms_big_fb@linear-32bpp-rotate-0:
- shard-glk: [PASS][76] -> [DMESG-WARN][77] ([i915#118])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-glk2/igt@kms_big_fb@linear-32bpp-rotate-0.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-glk3/igt@kms_big_fb@linear-32bpp-rotate-0.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-skl: NOTRUN -> [SKIP][78] ([fdo#109271] / [i915#3777]) +1 similar issue
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl10/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][79] ([i915#3743]) +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][80] ([fdo#109271] / [i915#3777]) +1 similar issue
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl1/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][81] ([fdo#109271] / [i915#3886]) +7 similar issues
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#3886]) +4 similar issues
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl7/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-iclb: NOTRUN -> [SKIP][83] ([fdo#109278] / [i915#3886])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium@vga-edid-read:
- shard-apl: NOTRUN -> [SKIP][84] ([fdo#109271] / [fdo#111827]) +6 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl7/igt@kms_chamelium@vga-edid-read.html
* igt@kms_color_chamelium@pipe-b-ctm-0-25:
- shard-skl: NOTRUN -> [SKIP][85] ([fdo#109271] / [fdo#111827]) +5 similar issues
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@kms_color_chamelium@pipe-b-ctm-0-25.html
* igt@kms_color_chamelium@pipe-b-ctm-0-5:
- shard-iclb: NOTRUN -> [SKIP][86] ([fdo#109284] / [fdo#111827])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_color_chamelium@pipe-b-ctm-0-5.html
* igt@kms_content_protection@srm:
- shard-apl: NOTRUN -> [TIMEOUT][87] ([i915#1319])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl1/igt@kms_content_protection@srm.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-kbl: [PASS][88] -> [DMESG-WARN][89] ([i915#180])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-kbl3/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-kbl7/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_cursor_crc@pipe-d-cursor-64x21-rapid-movement:
- shard-apl: NOTRUN -> [SKIP][90] ([fdo#109271]) +114 similar issues
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl1/igt@kms_cursor_crc@pipe-d-cursor-64x21-rapid-movement.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- shard-iclb: NOTRUN -> [SKIP][91] ([fdo#109278]) +3 similar issues
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_dp_tiled_display@basic-test-pattern:
- shard-iclb: NOTRUN -> [SKIP][92] ([i915#426])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_dp_tiled_display@basic-test-pattern.html
* igt@kms_draw_crc@draw-method-xrgb2101010-render-4tiled:
- shard-iclb: NOTRUN -> [SKIP][93] ([i915#5287])
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_draw_crc@draw-method-xrgb2101010-render-4tiled.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-apl: [PASS][94] -> [DMESG-WARN][95] ([i915#180]) +2 similar issues
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip@flip-vs-suspend@a-dp1:
- shard-apl: NOTRUN -> [DMESG-WARN][96] ([i915#180]) +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl7/igt@kms_flip@flip-vs-suspend@a-dp1.html
* igt@kms_flip@flip-vs-suspend@a-edp1:
- shard-iclb: [PASS][97] -> [DMESG-WARN][98] ([i915#2867])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb5/igt@kms_flip@flip-vs-suspend@a-edp1.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb8/igt@kms_flip@flip-vs-suspend@a-edp1.html
* igt@kms_frontbuffer_tracking@fbc-2p-shrfb-fliptrack-mmap-gtt:
- shard-iclb: NOTRUN -> [SKIP][99] ([fdo#109280]) +2 similar issues
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-2p-shrfb-fliptrack-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-skl: NOTRUN -> [SKIP][100] ([fdo#109271]) +148 similar issues
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt.html
* igt@kms_hdr@static-toggle-suspend:
- shard-iclb: NOTRUN -> [SKIP][101] ([i915#3555])
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_hdr@static-toggle-suspend.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-skl: NOTRUN -> [FAIL][102] ([fdo#108145] / [i915#265]) +1 similar issue
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb.html
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale:
- shard-iclb: [PASS][103] -> [SKIP][104] ([i915#5235]) +2 similar issues
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb8/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-skl: NOTRUN -> [SKIP][105] ([fdo#109271] / [i915#658])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl8/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
* igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: [PASS][106] -> [SKIP][107] ([fdo#109441]) +1 similar issue
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@kms_psr@psr2_primary_mmap_gtt.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-glk: NOTRUN -> [SKIP][108] ([fdo#109271])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-glk4/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_sysfs_edid_timing:
- shard-apl: NOTRUN -> [FAIL][109] ([IGT#2])
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl7/igt@kms_sysfs_edid_timing.html
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-skl: [PASS][110] -> [INCOMPLETE][111] ([i915#2828])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-skl9/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl3/igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-apl: NOTRUN -> [SKIP][112] ([fdo#109271] / [i915#533]) +1 similar issue
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl8/igt@kms_vblank@pipe-d-wait-idle.html
* igt@prime_nv_api@i915_nv_import_twice:
- shard-iclb: NOTRUN -> [SKIP][113] ([fdo#109291])
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@prime_nv_api@i915_nv_import_twice.html
* igt@sysfs_clients@fair-3:
- shard-skl: NOTRUN -> [SKIP][114] ([fdo#109271] / [i915#2994])
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl9/igt@sysfs_clients@fair-3.html
* igt@sysfs_clients@split-10:
- shard-apl: NOTRUN -> [SKIP][115] ([fdo#109271] / [i915#2994])
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl6/igt@sysfs_clients@split-10.html
#### Possible fixes ####
* igt@gem_ctx_persistence@many-contexts:
- {shard-rkl}: [FAIL][116] ([i915#2410]) -> ([PASS][117], [PASS][118])
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-2/igt@gem_ctx_persistence@many-contexts.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/igt@gem_ctx_persistence@many-contexts.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-4/igt@gem_ctx_persistence@many-contexts.html
* igt@gem_eio@suspend:
- {shard-rkl}: ([PASS][119], [FAIL][120]) ([i915#5115]) -> [PASS][121]
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-1/igt@gem_eio@suspend.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/igt@gem_eio@suspend.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/igt@gem_eio@suspend.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [TIMEOUT][122] ([i915#2481] / [i915#3070]) -> [PASS][123]
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb4/igt@gem_eio@unwedge-stress.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb6/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [SKIP][124] ([i915#4525]) -> [PASS][125]
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-iclb3/igt@gem_exec_balancer@parallel-balancer.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-iclb4/igt@gem_exec_balancer@parallel-balancer.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [FAIL][126] ([i915#2842]) -> [PASS][127]
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-tglb7/igt@gem_exec_fair@basic-none-share@rcs0.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-tglb5/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][128] ([i915#2842]) -> [PASS][129] +4 similar issues
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-kbl3/igt@gem_exec_fair@basic-none@vcs0.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-kbl1/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_fence@syncobj-import:
- shard-skl: [FAIL][130] -> [PASS][131]
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-skl2/igt@gem_exec_fence@syncobj-import.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-skl6/igt@gem_exec_fence@syncobj-import.html
* igt@gem_softpin@allocator-evict-all-engines:
- shard-glk: [FAIL][132] ([i915#4171]) -> [PASS][133]
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-glk4/igt@gem_softpin@allocator-evict-all-engines.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-glk5/igt@gem_softpin@allocator-evict-all-engines.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [DMESG-WARN][134] ([i915#180]) -> [PASS][135] +4 similar issues
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-apl7/igt@gem_softpin@noreloc-s3.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-apl1/igt@gem_softpin@noreloc-s3.html
* igt@gem_workarounds@suspend-resume-fd:
- {shard-rkl}: ([FAIL][136], [PASS][137]) ([fdo#103375]) -> [PASS][138]
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/igt@gem_workarounds@suspend-resume-fd.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/igt@gem_workarounds@suspend-resume-fd.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-1/igt@gem_workarounds@suspend-resume-fd.html
* igt@i915_pm_backlight@fade_with_suspend:
- {shard-rkl}: [SKIP][139] ([i915#3012]) -> [PASS][140]
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@i915_pm_backlight@fade_with_suspend.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@i915_pm_backlight@fade_with_suspend.html
* igt@i915_pm_dc@dc5-psr:
- {shard-rkl}: ([PASS][141], [SKIP][142]) ([i915#658]) -> [PASS][143]
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/igt@i915_pm_dc@dc5-psr.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/igt@i915_pm_dc@dc5-psr.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@i915_pm_dc@dc5-psr.html
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- {shard-rkl}: [SKIP][144] ([i915#1397]) -> [PASS][145]
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@i915_pm_rpm@modeset-lpsp-stress-no-wait.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@i915_pm_rpm@modeset-lpsp-stress-no-wait.html
* igt@kms_big_fb@linear-8bpp-rotate-0:
- {shard-rkl}: [SKIP][146] ([i915#1845] / [i915#4098]) -> [PASS][147] +11 similar issues
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@kms_big_fb@linear-8bpp-rotate-0.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_big_fb@linear-8bpp-rotate-0.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- {shard-rkl}: ([PASS][148], [SKIP][149]) ([i915#1845] / [i915#4098]) -> [PASS][150] +1 similar issue
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_color@pipe-b-ctm-blue-to-red:
- {shard-rkl}: [SKIP][151] ([i915#1149] / [i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][152]
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@kms_color@pipe-b-ctm-blue-to-red.html
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_color@pipe-b-ctm-blue-to-red.html
* igt@kms_concurrent@pipe-a:
- {shard-rkl}: [SKIP][153] ([i915#1845] / [i915#4070] / [i915#4098]) -> [PASS][154] +1 similar issue
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@kms_concurrent@pipe-a.html
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_concurrent@pipe-a.html
* igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen:
- {shard-rkl}: [SKIP][155] ([fdo#112022] / [i915#4070]) -> [PASS][156] +1 similar issue
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen.html
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen.html
* igt@kms_cursor_edge_walk@pipe-a-128x128-left-edge:
- {shard-rkl}: [SKIP][157] ([i915#1849] / [i915#4070] / [i915#4098]) -> [PASS][158] +2 similar issues
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@kms_cursor_edge_walk@pipe-a-128x128-left-edge.html
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_cursor_edge_walk@pipe-a-128x128-left-edge.html
* igt@kms_cursor_edge_walk@pipe-a-64x64-top-edge:
- {shard-rkl}: ([PASS][159], [SKIP][160]) ([i915#4070] / [i915#4098]) -> [PASS][161] +1 similar issue
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-6/igt@kms_cursor_edge_walk@pipe-a-64x64-top-edge.html
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-4/igt@kms_cursor_edge_walk@pipe-a-64x64-top-edge.html
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_cursor_edge_walk@pipe-a-64x64-top-edge.html
* igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
- {shard-rkl}: [SKIP][162] ([fdo#111825] / [i915#4070]) -> [PASS][163]
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-5/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-6/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
- shard-snb: [SKIP][164] ([fdo#109271]) -> [PASS][165] +1 similar issue
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-snb4/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
[165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-snb4/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
* igt@kms_cursor_legacy@pipe-c-single-bo:
- {shard-rkl}: [SKIP][166] ([i915#4070]) -> [PASS][167]
[166]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11363/shard-rkl-2/igt@kms_cursor_legacy@pipe-c-single-bo.html
[167]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/shard-rkl-5/igt@kms_cursor_legacy@pipe-c-single-b
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22563/index.html
[-- Attachment #2: Type: text/html, Size: 33391 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-14 19:40 ` [Intel-gfx] " Arunpravin
(?)
@ 2022-03-15 8:19 ` Paul Menzel
-1 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 8:19 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 14.03.22 um 20:40 schrieb Arunpravin:
> handle a situation in the condition order-- == min_order,
> when order = 0, leading to order = -1, it now won't exit
> the loop. To avoid this problem, added a order check in
> the same condition, (i.e) when order is 0, we return
> -ENOSPC
>
> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Please use your full name.
> ---
> drivers/gpu/drm/drm_buddy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 72f52f293249..5ab66aaf2bbd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
In what tree is that file?
> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> if (!IS_ERR(block))
> break;
>
> - if (order-- == min_order) {
> + if (!order || order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 8:19 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 8:19 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, amd-gfx, dri-devel, daniel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 14.03.22 um 20:40 schrieb Arunpravin:
> handle a situation in the condition order-- == min_order,
> when order = 0, leading to order = -1, it now won't exit
> the loop. To avoid this problem, added a order check in
> the same condition, (i.e) when order is 0, we return
> -ENOSPC
>
> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Please use your full name.
> ---
> drivers/gpu/drm/drm_buddy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 72f52f293249..5ab66aaf2bbd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
In what tree is that file?
> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> if (!IS_ERR(block))
> break;
>
> - if (order-- == min_order) {
> + if (!order || order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 8:19 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 8:19 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 14.03.22 um 20:40 schrieb Arunpravin:
> handle a situation in the condition order-- == min_order,
> when order = 0, leading to order = -1, it now won't exit
> the loop. To avoid this problem, added a order check in
> the same condition, (i.e) when order is 0, we return
> -ENOSPC
>
> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Please use your full name.
> ---
> drivers/gpu/drm/drm_buddy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 72f52f293249..5ab66aaf2bbd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
In what tree is that file?
> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> if (!IS_ERR(block))
> break;
>
> - if (order-- == min_order) {
> + if (!order || order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-15 8:19 ` Paul Menzel
(?)
@ 2022-03-15 9:01 ` Arunpravin
-1 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-15 9:01 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 1:49 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 14.03.22 um 20:40 schrieb Arunpravin:
>> handle a situation in the condition order-- == min_order,
>> when order = 0, leading to order = -1, it now won't exit
>> the loop. To avoid this problem, added a order check in
>> the same condition, (i.e) when order is 0, we return
>> -ENOSPC
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>
> Please use your full name.
okay
>
>> ---
>> drivers/gpu/drm/drm_buddy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 72f52f293249..5ab66aaf2bbd 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>
> In what tree is that file?
>
drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>> if (!IS_ERR(block))
>> break;
>>
>> - if (order-- == min_order) {
>> + if (!order || order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 9:01 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-15 9:01 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 1:49 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 14.03.22 um 20:40 schrieb Arunpravin:
>> handle a situation in the condition order-- == min_order,
>> when order = 0, leading to order = -1, it now won't exit
>> the loop. To avoid this problem, added a order check in
>> the same condition, (i.e) when order is 0, we return
>> -ENOSPC
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>
> Please use your full name.
okay
>
>> ---
>> drivers/gpu/drm/drm_buddy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 72f52f293249..5ab66aaf2bbd 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>
> In what tree is that file?
>
drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>> if (!IS_ERR(block))
>> break;
>>
>> - if (order-- == min_order) {
>> + if (!order || order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 9:01 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-15 9:01 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, amd-gfx, dri-devel, daniel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 1:49 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 14.03.22 um 20:40 schrieb Arunpravin:
>> handle a situation in the condition order-- == min_order,
>> when order = 0, leading to order = -1, it now won't exit
>> the loop. To avoid this problem, added a order check in
>> the same condition, (i.e) when order is 0, we return
>> -ENOSPC
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>
> Please use your full name.
okay
>
>> ---
>> drivers/gpu/drm/drm_buddy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 72f52f293249..5ab66aaf2bbd 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>
> In what tree is that file?
>
drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>> if (!IS_ERR(block))
>> break;
>>
>> - if (order-- == min_order) {
>> + if (!order || order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-15 9:01 ` [Intel-gfx] " Arunpravin
(?)
@ 2022-03-15 9:05 ` Paul Menzel
-1 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 9:05 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 15.03.22 um 10:01 schrieb Arunpravin:
> On 15/03/22 1:49 pm, Paul Menzel wrote:
>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>> handle a situation in the condition order-- == min_order,
>>> when order = 0, leading to order = -1, it now won't exit
>>> the loop. To avoid this problem, added a order check in
>>> the same condition, (i.e) when order is 0, we return
>>> -ENOSPC
>>>
>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>
>> Please use your full name.
> okay
You might also configure that in your email program.
>>> ---
>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>> index 72f52f293249..5ab66aaf2bbd 100644
>>> --- a/drivers/gpu/drm/drm_buddy.c
>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>
>> In what tree is that file?
>>
> drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
> drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>
>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>> if (!IS_ERR(block))
>>> break;
>>>
>>> - if (order-- == min_order) {
>>> + if (!order || order-- == min_order) {
>>> err = -ENOSPC;
>>> goto err_free;
>>> }
Thank you for the hint. So the whole function is:
do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);
do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);
if (!IS_ERR(block))
break;
if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);
mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(&block->link, &allocated);
pages -= BIT(order);
if (!pages)
break;
} while (1);
Was the BUG_ON triggered for your case?
BUG_ON(order < min_order);
Please give more details.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 9:05 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 9:05 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 15.03.22 um 10:01 schrieb Arunpravin:
> On 15/03/22 1:49 pm, Paul Menzel wrote:
>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>> handle a situation in the condition order-- == min_order,
>>> when order = 0, leading to order = -1, it now won't exit
>>> the loop. To avoid this problem, added a order check in
>>> the same condition, (i.e) when order is 0, we return
>>> -ENOSPC
>>>
>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>
>> Please use your full name.
> okay
You might also configure that in your email program.
>>> ---
>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>> index 72f52f293249..5ab66aaf2bbd 100644
>>> --- a/drivers/gpu/drm/drm_buddy.c
>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>
>> In what tree is that file?
>>
> drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
> drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>
>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>> if (!IS_ERR(block))
>>> break;
>>>
>>> - if (order-- == min_order) {
>>> + if (!order || order-- == min_order) {
>>> err = -ENOSPC;
>>> goto err_free;
>>> }
Thank you for the hint. So the whole function is:
do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);
do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);
if (!IS_ERR(block))
break;
if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);
mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(&block->link, &allocated);
pages -= BIT(order);
if (!pages)
break;
} while (1);
Was the BUG_ON triggered for your case?
BUG_ON(order < min_order);
Please give more details.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 9:05 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 9:05 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, dri-devel, amd-gfx, daniel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 15.03.22 um 10:01 schrieb Arunpravin:
> On 15/03/22 1:49 pm, Paul Menzel wrote:
>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>> handle a situation in the condition order-- == min_order,
>>> when order = 0, leading to order = -1, it now won't exit
>>> the loop. To avoid this problem, added a order check in
>>> the same condition, (i.e) when order is 0, we return
>>> -ENOSPC
>>>
>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>
>> Please use your full name.
> okay
You might also configure that in your email program.
>>> ---
>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>> index 72f52f293249..5ab66aaf2bbd 100644
>>> --- a/drivers/gpu/drm/drm_buddy.c
>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>
>> In what tree is that file?
>>
> drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
> drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/
>
>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>> if (!IS_ERR(block))
>>> break;
>>>
>>> - if (order-- == min_order) {
>>> + if (!order || order-- == min_order) {
>>> err = -ENOSPC;
>>> goto err_free;
>>> }
Thank you for the hint. So the whole function is:
do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);
do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);
if (!IS_ERR(block))
break;
if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);
mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(&block->link, &allocated);
pages -= BIT(order);
if (!pages)
break;
} while (1);
Was the BUG_ON triggered for your case?
BUG_ON(order < min_order);
Please give more details.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-14 19:40 ` [Intel-gfx] " Arunpravin
(?)
@ 2022-03-15 11:31 ` Matthew Auld
-1 siblings, 0 replies; 32+ messages in thread
From: Matthew Auld @ 2022-03-15 11:31 UTC (permalink / raw)
To: Arunpravin, intel-gfx, dri-devel, amd-gfx
Cc: alexander.deucher, christian.koenig
On 14/03/2022 19:40, Arunpravin wrote:
> handle a situation in the condition order-- == min_order,
> when order = 0, leading to order = -1, it now won't exit
> the loop. To avoid this problem, added a order check in
> the same condition, (i.e) when order is 0, we return
> -ENOSPC
>
> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Hmm, it sounded like we were instead going to go with the round_up(size,
min_page_size), or check and bail if the size is misaligned, in which
case we don't need this, AFAICT.
> ---
> drivers/gpu/drm/drm_buddy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 72f52f293249..5ab66aaf2bbd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> if (!IS_ERR(block))
> break;
>
> - if (order-- == min_order) {
> + if (!order || order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 11:31 ` Matthew Auld
0 siblings, 0 replies; 32+ messages in thread
From: Matthew Auld @ 2022-03-15 11:31 UTC (permalink / raw)
To: Arunpravin, intel-gfx, dri-devel, amd-gfx
Cc: alexander.deucher, christian.koenig
On 14/03/2022 19:40, Arunpravin wrote:
> handle a situation in the condition order-- == min_order,
> when order = 0, leading to order = -1, it now won't exit
> the loop. To avoid this problem, added a order check in
> the same condition, (i.e) when order is 0, we return
> -ENOSPC
>
> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Hmm, it sounded like we were instead going to go with the round_up(size,
min_page_size), or check and bail if the size is misaligned, in which
case we don't need this, AFAICT.
> ---
> drivers/gpu/drm/drm_buddy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 72f52f293249..5ab66aaf2bbd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> if (!IS_ERR(block))
> break;
>
> - if (order-- == min_order) {
> + if (!order || order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 11:31 ` Matthew Auld
0 siblings, 0 replies; 32+ messages in thread
From: Matthew Auld @ 2022-03-15 11:31 UTC (permalink / raw)
To: Arunpravin, intel-gfx, dri-devel, amd-gfx
Cc: alexander.deucher, christian.koenig, daniel
On 14/03/2022 19:40, Arunpravin wrote:
> handle a situation in the condition order-- == min_order,
> when order = 0, leading to order = -1, it now won't exit
> the loop. To avoid this problem, added a order check in
> the same condition, (i.e) when order is 0, we return
> -ENOSPC
>
> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Hmm, it sounded like we were instead going to go with the round_up(size,
min_page_size), or check and bail if the size is misaligned, in which
case we don't need this, AFAICT.
> ---
> drivers/gpu/drm/drm_buddy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index 72f52f293249..5ab66aaf2bbd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
> if (!IS_ERR(block))
> break;
>
> - if (order-- == min_order) {
> + if (!order || order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-15 9:05 ` [Intel-gfx] " Paul Menzel
(?)
@ 2022-03-15 15:42 ` Arunpravin
-1 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-15 15:42 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 2:35 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 10:01 schrieb Arunpravin:
>
>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>
>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>> handle a situation in the condition order-- == min_order,
>>>> when order = 0, leading to order = -1, it now won't exit
>>>> the loop. To avoid this problem, added a order check in
>>>> the same condition, (i.e) when order is 0, we return
>>>> -ENOSPC
>>>>
>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>
>>> Please use your full name.
>> okay
>
> You might also configure that in your email program.
yes
>
>>>> ---
>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>
>>> In what tree is that file?
>>>
>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
>>
>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>> if (!IS_ERR(block))
>>>> break;
>>>>
>>>> - if (order-- == min_order) {
>>>> + if (!order || order-- == min_order) {
>>>> err = -ENOSPC;
>>>> goto err_free;
>>>> }
>
> Thank you for the hint. So the whole function is:
>
> do {
> order = min(order, (unsigned int)fls(pages) - 1);
> BUG_ON(order > mm->max_order);
> BUG_ON(order < min_order);
>
> do {
> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
> /* Allocate traversing within the range */
> block = alloc_range_bias(mm, start, end, order);
> else
> /* Allocate from freelist */
> block = alloc_from_freelist(mm, order, flags);
>
> if (!IS_ERR(block))
> break;
>
> if (order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
> } while (1);
>
> mark_allocated(block);
> mm->avail -= drm_buddy_block_size(mm, block);
> kmemleak_update_trace(block);
> list_add_tail(&block->link, &allocated);
>
> pages -= BIT(order);
>
> if (!pages)
> break;
> } while (1);
>
> Was the BUG_ON triggered for your case?
>
> BUG_ON(order < min_order);
no, this BUG_ON is not triggered for this bug
>
> Please give more details.
there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Thanks,
Arun
>
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 15:42 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-15 15:42 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, dri-devel, amd-gfx, daniel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 2:35 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 10:01 schrieb Arunpravin:
>
>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>
>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>> handle a situation in the condition order-- == min_order,
>>>> when order = 0, leading to order = -1, it now won't exit
>>>> the loop. To avoid this problem, added a order check in
>>>> the same condition, (i.e) when order is 0, we return
>>>> -ENOSPC
>>>>
>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>
>>> Please use your full name.
>> okay
>
> You might also configure that in your email program.
yes
>
>>>> ---
>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>
>>> In what tree is that file?
>>>
>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
>>
>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>> if (!IS_ERR(block))
>>>> break;
>>>>
>>>> - if (order-- == min_order) {
>>>> + if (!order || order-- == min_order) {
>>>> err = -ENOSPC;
>>>> goto err_free;
>>>> }
>
> Thank you for the hint. So the whole function is:
>
> do {
> order = min(order, (unsigned int)fls(pages) - 1);
> BUG_ON(order > mm->max_order);
> BUG_ON(order < min_order);
>
> do {
> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
> /* Allocate traversing within the range */
> block = alloc_range_bias(mm, start, end, order);
> else
> /* Allocate from freelist */
> block = alloc_from_freelist(mm, order, flags);
>
> if (!IS_ERR(block))
> break;
>
> if (order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
> } while (1);
>
> mark_allocated(block);
> mm->avail -= drm_buddy_block_size(mm, block);
> kmemleak_update_trace(block);
> list_add_tail(&block->link, &allocated);
>
> pages -= BIT(order);
>
> if (!pages)
> break;
> } while (1);
>
> Was the BUG_ON triggered for your case?
>
> BUG_ON(order < min_order);
no, this BUG_ON is not triggered for this bug
>
> Please give more details.
there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Thanks,
Arun
>
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 15:42 ` Arunpravin
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin @ 2022-03-15 15:42 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 2:35 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 10:01 schrieb Arunpravin:
>
>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>
>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>> handle a situation in the condition order-- == min_order,
>>>> when order = 0, leading to order = -1, it now won't exit
>>>> the loop. To avoid this problem, added a order check in
>>>> the same condition, (i.e) when order is 0, we return
>>>> -ENOSPC
>>>>
>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>
>>> Please use your full name.
>> okay
>
> You might also configure that in your email program.
yes
>
>>>> ---
>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>
>>> In what tree is that file?
>>>
>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
>>
>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>> if (!IS_ERR(block))
>>>> break;
>>>>
>>>> - if (order-- == min_order) {
>>>> + if (!order || order-- == min_order) {
>>>> err = -ENOSPC;
>>>> goto err_free;
>>>> }
>
> Thank you for the hint. So the whole function is:
>
> do {
> order = min(order, (unsigned int)fls(pages) - 1);
> BUG_ON(order > mm->max_order);
> BUG_ON(order < min_order);
>
> do {
> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
> /* Allocate traversing within the range */
> block = alloc_range_bias(mm, start, end, order);
> else
> /* Allocate from freelist */
> block = alloc_from_freelist(mm, order, flags);
>
> if (!IS_ERR(block))
> break;
>
> if (order-- == min_order) {
> err = -ENOSPC;
> goto err_free;
> }
> } while (1);
>
> mark_allocated(block);
> mm->avail -= drm_buddy_block_size(mm, block);
> kmemleak_update_trace(block);
> list_add_tail(&block->link, &allocated);
>
> pages -= BIT(order);
>
> if (!pages)
> break;
> } while (1);
>
> Was the BUG_ON triggered for your case?
>
> BUG_ON(order < min_order);
no, this BUG_ON is not triggered for this bug
>
> Please give more details.
there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Thanks,
Arun
>
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-15 15:42 ` Arunpravin
(?)
@ 2022-03-15 15:44 ` Paul Menzel
-1 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 15:44 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 15.03.22 um 16:42 schrieb Arunpravin:
> On 15/03/22 2:35 pm, Paul Menzel wrote:
>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>
>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>
>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>> handle a situation in the condition order-- == min_order,
>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>> the loop. To avoid this problem, added a order check in
>>>>> the same condition, (i.e) when order is 0, we return
>>>>> -ENOSPC
>>>>>
>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>
>>>> Please use your full name.
>>> okay
>>
>> You might also configure that in your email program.
> yes
Not done yet though. ;-)
>>>>> ---
>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>
>>>> In what tree is that file?
>>>>
>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
Thank Outlook. Now everybody feels safe.
>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>> if (!IS_ERR(block))
>>>>> break;
>>>>>
>>>>> - if (order-- == min_order) {
>>>>> + if (!order || order-- == min_order) {
>>>>> err = -ENOSPC;
>>>>> goto err_free;
>>>>> }
>>
>> Thank you for the hint. So the whole function is:
>>
>> do {
>> order = min(order, (unsigned int)fls(pages) - 1);
>> BUG_ON(order > mm->max_order);
>> BUG_ON(order < min_order);
>>
>> do {
>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>> /* Allocate traversing within the range */
>> block = alloc_range_bias(mm, start, end, order);
>> else
>> /* Allocate from freelist */
>> block = alloc_from_freelist(mm, order, flags);
>>
>> if (!IS_ERR(block))
>> break;
>>
>> if (order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>> } while (1);
>>
>> mark_allocated(block);
>> mm->avail -= drm_buddy_block_size(mm, block);
>> kmemleak_update_trace(block);
>> list_add_tail(&block->link, &allocated);
>>
>> pages -= BIT(order);
>>
>> if (!pages)
>> break;
>> } while (1);
>>
>> Was the BUG_ON triggered for your case?
>>
>> BUG_ON(order < min_order);
> no, this BUG_ON is not triggered for this bug
>>
>> Please give more details.
>
> there is a chance when there is no space to allocate, order value
> decrements and reaches to 0 at one point, here we should exit the loop,
> otherwise, further order value decrements to -1 and do..while loop
> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Sorry, I do not see it. How can that be with order ≥ min_order and the
check `order-- == min_order`? Is min_order 0? Please explain that in the
next commit message.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 15:44 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 15:44 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 15.03.22 um 16:42 schrieb Arunpravin:
> On 15/03/22 2:35 pm, Paul Menzel wrote:
>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>
>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>
>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>> handle a situation in the condition order-- == min_order,
>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>> the loop. To avoid this problem, added a order check in
>>>>> the same condition, (i.e) when order is 0, we return
>>>>> -ENOSPC
>>>>>
>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>
>>>> Please use your full name.
>>> okay
>>
>> You might also configure that in your email program.
> yes
Not done yet though. ;-)
>>>>> ---
>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>
>>>> In what tree is that file?
>>>>
>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
Thank Outlook. Now everybody feels safe.
>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>> if (!IS_ERR(block))
>>>>> break;
>>>>>
>>>>> - if (order-- == min_order) {
>>>>> + if (!order || order-- == min_order) {
>>>>> err = -ENOSPC;
>>>>> goto err_free;
>>>>> }
>>
>> Thank you for the hint. So the whole function is:
>>
>> do {
>> order = min(order, (unsigned int)fls(pages) - 1);
>> BUG_ON(order > mm->max_order);
>> BUG_ON(order < min_order);
>>
>> do {
>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>> /* Allocate traversing within the range */
>> block = alloc_range_bias(mm, start, end, order);
>> else
>> /* Allocate from freelist */
>> block = alloc_from_freelist(mm, order, flags);
>>
>> if (!IS_ERR(block))
>> break;
>>
>> if (order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>> } while (1);
>>
>> mark_allocated(block);
>> mm->avail -= drm_buddy_block_size(mm, block);
>> kmemleak_update_trace(block);
>> list_add_tail(&block->link, &allocated);
>>
>> pages -= BIT(order);
>>
>> if (!pages)
>> break;
>> } while (1);
>>
>> Was the BUG_ON triggered for your case?
>>
>> BUG_ON(order < min_order);
> no, this BUG_ON is not triggered for this bug
>>
>> Please give more details.
>
> there is a chance when there is no space to allocate, order value
> decrements and reaches to 0 at one point, here we should exit the loop,
> otherwise, further order value decrements to -1 and do..while loop
> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Sorry, I do not see it. How can that be with order ≥ min_order and the
check `order-- == min_order`? Is min_order 0? Please explain that in the
next commit message.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-15 15:44 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-15 15:44 UTC (permalink / raw)
To: Arunpravin.PaneerSelvam
Cc: intel-gfx, amd-gfx, dri-devel, daniel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunpravin,
Am 15.03.22 um 16:42 schrieb Arunpravin:
> On 15/03/22 2:35 pm, Paul Menzel wrote:
>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>
>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>
>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>> handle a situation in the condition order-- == min_order,
>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>> the loop. To avoid this problem, added a order check in
>>>>> the same condition, (i.e) when order is 0, we return
>>>>> -ENOSPC
>>>>>
>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>
>>>> Please use your full name.
>>> okay
>>
>> You might also configure that in your email program.
> yes
Not done yet though. ;-)
>>>>> ---
>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>
>>>> In what tree is that file?
>>>>
>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3D&reserved=0
>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3D&reserved=0
Thank Outlook. Now everybody feels safe.
>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>> if (!IS_ERR(block))
>>>>> break;
>>>>>
>>>>> - if (order-- == min_order) {
>>>>> + if (!order || order-- == min_order) {
>>>>> err = -ENOSPC;
>>>>> goto err_free;
>>>>> }
>>
>> Thank you for the hint. So the whole function is:
>>
>> do {
>> order = min(order, (unsigned int)fls(pages) - 1);
>> BUG_ON(order > mm->max_order);
>> BUG_ON(order < min_order);
>>
>> do {
>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>> /* Allocate traversing within the range */
>> block = alloc_range_bias(mm, start, end, order);
>> else
>> /* Allocate from freelist */
>> block = alloc_from_freelist(mm, order, flags);
>>
>> if (!IS_ERR(block))
>> break;
>>
>> if (order-- == min_order) {
>> err = -ENOSPC;
>> goto err_free;
>> }
>> } while (1);
>>
>> mark_allocated(block);
>> mm->avail -= drm_buddy_block_size(mm, block);
>> kmemleak_update_trace(block);
>> list_add_tail(&block->link, &allocated);
>>
>> pages -= BIT(order);
>>
>> if (!pages)
>> break;
>> } while (1);
>>
>> Was the BUG_ON triggered for your case?
>>
>> BUG_ON(order < min_order);
> no, this BUG_ON is not triggered for this bug
>>
>> Please give more details.
>
> there is a chance when there is no space to allocate, order value
> decrements and reaches to 0 at one point, here we should exit the loop,
> otherwise, further order value decrements to -1 and do..while loop
> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
Sorry, I do not see it. How can that be with order ≥ min_order and the
check `order-- == min_order`? Is min_order 0? Please explain that in the
next commit message.
Kind regards,
Paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-15 15:44 ` [Intel-gfx] " Paul Menzel
(?)
@ 2022-03-16 6:49 ` Arunpravin Paneer Selvam
-1 siblings, 0 replies; 32+ messages in thread
From: Arunpravin Paneer Selvam @ 2022-03-16 6:49 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 9:14 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 16:42 schrieb Arunpravin:
>
>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>
>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>
>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>
>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>> handle a situation in the condition order-- == min_order,
>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>> the loop. To avoid this problem, added a order check in
>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>> -ENOSPC
>>>>>>
>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>
>>>>> Please use your full name.
>>>> okay
>>>
>>> You might also configure that in your email program.
>> yes
>
> Not done yet though. ;-)
>
done in v2 :)
>>>>>> ---
>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>
>>>>> In what tree is that file?
>>>>>
>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3D&reserved=0
>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3D&reserved=0
>
> Thank Outlook. Now everybody feels safe.
>
>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>> if (!IS_ERR(block))
>>>>>> break;
>>>>>>
>>>>>> - if (order-- == min_order) {
>>>>>> + if (!order || order-- == min_order) {
>>>>>> err = -ENOSPC;
>>>>>> goto err_free;
>>>>>> }
>>>
>>> Thank you for the hint. So the whole function is:
>>>
>>> do {
>>> order = min(order, (unsigned int)fls(pages) - 1);
>>> BUG_ON(order > mm->max_order);
>>> BUG_ON(order < min_order);
>>>
>>> do {
>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>> /* Allocate traversing within the range */
>>> block = alloc_range_bias(mm, start, end, order);
>>> else
>>> /* Allocate from freelist */
>>> block = alloc_from_freelist(mm, order, flags);
>>>
>>> if (!IS_ERR(block))
>>> break;
>>>
>>> if (order-- == min_order) {
>>> err = -ENOSPC;
>>> goto err_free;
>>> }
>>> } while (1);
>>>
>>> mark_allocated(block);
>>> mm->avail -= drm_buddy_block_size(mm, block);
>>> kmemleak_update_trace(block);
>>> list_add_tail(&block->link, &allocated);
>>>
>>> pages -= BIT(order);
>>>
>>> if (!pages)
>>> break;
>>> } while (1);
>>>
>>> Was the BUG_ON triggered for your case?
>>>
>>> BUG_ON(order < min_order);
>> no, this BUG_ON is not triggered for this bug
>>>
>>> Please give more details.
>>
>> there is a chance when there is no space to allocate, order value
>> decrements and reaches to 0 at one point, here we should exit the loop,
>> otherwise, further order value decrements to -1 and do..while loop
>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>
> Sorry, I do not see it. How can that be with order ≥ min_order and the
> check `order-- == min_order`? Is min_order 0? Please explain that in the
> next commit message.
>
please check v2, yes when min_order is 0, the above said situation may
occur.And, since the order is unsigned int, I think it will not trigger
the BUG_ON(order < min_order) when order becomes -1. Hence I think we
needed a check !order to exit the loop.
Regards,
Arun
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-16 6:49 ` Arunpravin Paneer Selvam
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin Paneer Selvam @ 2022-03-16 6:49 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, amd-gfx, dri-devel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 9:14 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 16:42 schrieb Arunpravin:
>
>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>
>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>
>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>
>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>> handle a situation in the condition order-- == min_order,
>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>> the loop. To avoid this problem, added a order check in
>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>> -ENOSPC
>>>>>>
>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>
>>>>> Please use your full name.
>>>> okay
>>>
>>> You might also configure that in your email program.
>> yes
>
> Not done yet though. ;-)
>
done in v2 :)
>>>>>> ---
>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>
>>>>> In what tree is that file?
>>>>>
>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3D&reserved=0
>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3D&reserved=0
>
> Thank Outlook. Now everybody feels safe.
>
>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>> if (!IS_ERR(block))
>>>>>> break;
>>>>>>
>>>>>> - if (order-- == min_order) {
>>>>>> + if (!order || order-- == min_order) {
>>>>>> err = -ENOSPC;
>>>>>> goto err_free;
>>>>>> }
>>>
>>> Thank you for the hint. So the whole function is:
>>>
>>> do {
>>> order = min(order, (unsigned int)fls(pages) - 1);
>>> BUG_ON(order > mm->max_order);
>>> BUG_ON(order < min_order);
>>>
>>> do {
>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>> /* Allocate traversing within the range */
>>> block = alloc_range_bias(mm, start, end, order);
>>> else
>>> /* Allocate from freelist */
>>> block = alloc_from_freelist(mm, order, flags);
>>>
>>> if (!IS_ERR(block))
>>> break;
>>>
>>> if (order-- == min_order) {
>>> err = -ENOSPC;
>>> goto err_free;
>>> }
>>> } while (1);
>>>
>>> mark_allocated(block);
>>> mm->avail -= drm_buddy_block_size(mm, block);
>>> kmemleak_update_trace(block);
>>> list_add_tail(&block->link, &allocated);
>>>
>>> pages -= BIT(order);
>>>
>>> if (!pages)
>>> break;
>>> } while (1);
>>>
>>> Was the BUG_ON triggered for your case?
>>>
>>> BUG_ON(order < min_order);
>> no, this BUG_ON is not triggered for this bug
>>>
>>> Please give more details.
>>
>> there is a chance when there is no space to allocate, order value
>> decrements and reaches to 0 at one point, here we should exit the loop,
>> otherwise, further order value decrements to -1 and do..while loop
>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>
> Sorry, I do not see it. How can that be with order ≥ min_order and the
> check `order-- == min_order`? Is min_order 0? Please explain that in the
> next commit message.
>
please check v2, yes when min_order is 0, the above said situation may
occur.And, since the order is unsigned int, I think it will not trigger
the BUG_ON(order < min_order) when order becomes -1. Hence I think we
needed a check !order to exit the loop.
Regards,
Arun
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-16 6:49 ` Arunpravin Paneer Selvam
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin Paneer Selvam @ 2022-03-16 6:49 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, amd-gfx, dri-devel, daniel, alexander.deucher,
christian.koenig, matthew.auld
On 15/03/22 9:14 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 16:42 schrieb Arunpravin:
>
>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>
>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>
>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>
>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>> handle a situation in the condition order-- == min_order,
>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>> the loop. To avoid this problem, added a order check in
>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>> -ENOSPC
>>>>>>
>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>
>>>>> Please use your full name.
>>>> okay
>>>
>>> You might also configure that in your email program.
>> yes
>
> Not done yet though. ;-)
>
done in v2 :)
>>>>>> ---
>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>
>>>>> In what tree is that file?
>>>>>
>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3D&reserved=0
>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3D&reserved=0
>
> Thank Outlook. Now everybody feels safe.
>
>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>> if (!IS_ERR(block))
>>>>>> break;
>>>>>>
>>>>>> - if (order-- == min_order) {
>>>>>> + if (!order || order-- == min_order) {
>>>>>> err = -ENOSPC;
>>>>>> goto err_free;
>>>>>> }
>>>
>>> Thank you for the hint. So the whole function is:
>>>
>>> do {
>>> order = min(order, (unsigned int)fls(pages) - 1);
>>> BUG_ON(order > mm->max_order);
>>> BUG_ON(order < min_order);
>>>
>>> do {
>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>> /* Allocate traversing within the range */
>>> block = alloc_range_bias(mm, start, end, order);
>>> else
>>> /* Allocate from freelist */
>>> block = alloc_from_freelist(mm, order, flags);
>>>
>>> if (!IS_ERR(block))
>>> break;
>>>
>>> if (order-- == min_order) {
>>> err = -ENOSPC;
>>> goto err_free;
>>> }
>>> } while (1);
>>>
>>> mark_allocated(block);
>>> mm->avail -= drm_buddy_block_size(mm, block);
>>> kmemleak_update_trace(block);
>>> list_add_tail(&block->link, &allocated);
>>>
>>> pages -= BIT(order);
>>>
>>> if (!pages)
>>> break;
>>> } while (1);
>>>
>>> Was the BUG_ON triggered for your case?
>>>
>>> BUG_ON(order < min_order);
>> no, this BUG_ON is not triggered for this bug
>>>
>>> Please give more details.
>>
>> there is a chance when there is no space to allocate, order value
>> decrements and reaches to 0 at one point, here we should exit the loop,
>> otherwise, further order value decrements to -1 and do..while loop
>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>
> Sorry, I do not see it. How can that be with order ≥ min_order and the
> check `order-- == min_order`? Is min_order 0? Please explain that in the
> next commit message.
>
please check v2, yes when min_order is 0, the above said situation may
occur.And, since the order is unsigned int, I think it will not trigger
the BUG_ON(order < min_order) when order becomes -1. Hence I think we
needed a check !order to exit the loop.
Regards,
Arun
>
> Kind regards,
>
> Paul
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-16 6:49 ` [Intel-gfx] " Arunpravin Paneer Selvam
(?)
@ 2022-03-16 6:58 ` Paul Menzel
-1 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-16 6:58 UTC (permalink / raw)
To: Arunpravin Paneer Selvam
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunprivin,
Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
> On 15/03/22 9:14 pm, Paul Menzel wrote:
>> Am 15.03.22 um 16:42 schrieb Arunpravin:
>>
>>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>>
>>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>>
>>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>>
>>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>>> handle a situation in the condition order-- == min_order,
>>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>>> the loop. To avoid this problem, added a order check in
>>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>>> -ENOSPC
>>>>>>>
>>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>>
>>>>>> Please use your full name.
>>>>> okay
>>>>
>>>> You might also configure that in your email program.
>>> yes
>>
>> Not done yet though. ;-)
>>
> done in v2 :)
>>>>>>> ---
>>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>>
>>>>>> In what tree is that file?
>>>>>>
>>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3D&reserved=0
>>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3D&reserved=0
>>
>> Thank Outlook. Now everybody feels safe.
>>
>>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>>> if (!IS_ERR(block))
>>>>>>> break;
>>>>>>>
>>>>>>> - if (order-- == min_order) {
>>>>>>> + if (!order || order-- == min_order) {
>>>>>>> err = -ENOSPC;
>>>>>>> goto err_free;
>>>>>>> }
>>>>
>>>> Thank you for the hint. So the whole function is:
>>>>
>>>> do {
>>>> order = min(order, (unsigned int)fls(pages) - 1);
>>>> BUG_ON(order > mm->max_order);
>>>> BUG_ON(order < min_order);
>>>>
>>>> do {
>>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>>> /* Allocate traversing within the range */
>>>> block = alloc_range_bias(mm, start, end, order);
>>>> else
>>>> /* Allocate from freelist */
>>>> block = alloc_from_freelist(mm, order, flags);
>>>>
>>>> if (!IS_ERR(block))
>>>> break;
>>>>
>>>> if (order-- == min_order) {
>>>> err = -ENOSPC;
>>>> goto err_free;
>>>> }
>>>> } while (1);
>>>>
>>>> mark_allocated(block);
>>>> mm->avail -= drm_buddy_block_size(mm, block);
>>>> kmemleak_update_trace(block);
>>>> list_add_tail(&block->link, &allocated);
>>>>
>>>> pages -= BIT(order);
>>>>
>>>> if (!pages)
>>>> break;
>>>> } while (1);
>>>>
>>>> Was the BUG_ON triggered for your case?
>>>>
>>>> BUG_ON(order < min_order);
>>> no, this BUG_ON is not triggered for this bug
>>>>
>>>> Please give more details.
>>>
>>> there is a chance when there is no space to allocate, order value
>>> decrements and reaches to 0 at one point, here we should exit the loop,
>>> otherwise, further order value decrements to -1 and do..while loop
>>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>>
>> Sorry, I do not see it. How can that be with order ≥ min_order and the
>> check `order-- == min_order`? Is min_order 0? Please explain that in the
>> next commit message.
>>
> please check v2, yes when min_order is 0, the above said situation may
> occur.And, since the order is unsigned int, I think it will not trigger
> the BUG_ON(order < min_order) when order becomes -1. Hence I think we
> needed a check !order to exit the loop.
Thank you for clarifying this. I still do not understand it though. With
order = fls(pages) - 1;
min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
is zorder` always non-negative? Let’s assume it is. Also, can min_order
get “negative” (wraps around)?
I would add BUG_ON statements for these cases?
BUG_ON(fls(pages) - 1 < 1);
BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);
Assuming “negative” is not possible, your case can only happen if
`order` and `min_order` are 0, right? If `order` is greater than 0, and
`min_order` is 0, the first BUG_ON in the while loop would be hit. If
`order` is 0 and `min_order` is greater than 0, everything should work
as the condition in `if (order-- == min_order)` is going to be true
eventually.
Could you please analyze this more. The current patch looks more like
papering over something, or I am missing something.
Kind regards,
Paul
PS: The commit message summary of your v2 should also be updated.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-16 6:58 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-16 6:58 UTC (permalink / raw)
To: Arunpravin Paneer Selvam
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunprivin,
Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
> On 15/03/22 9:14 pm, Paul Menzel wrote:
>> Am 15.03.22 um 16:42 schrieb Arunpravin:
>>
>>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>>
>>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>>
>>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>>
>>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>>> handle a situation in the condition order-- == min_order,
>>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>>> the loop. To avoid this problem, added a order check in
>>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>>> -ENOSPC
>>>>>>>
>>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>>
>>>>>> Please use your full name.
>>>>> okay
>>>>
>>>> You might also configure that in your email program.
>>> yes
>>
>> Not done yet though. ;-)
>>
> done in v2 :)
>>>>>>> ---
>>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>>
>>>>>> In what tree is that file?
>>>>>>
>>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3D&reserved=0
>>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3D&reserved=0
>>
>> Thank Outlook. Now everybody feels safe.
>>
>>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>>> if (!IS_ERR(block))
>>>>>>> break;
>>>>>>>
>>>>>>> - if (order-- == min_order) {
>>>>>>> + if (!order || order-- == min_order) {
>>>>>>> err = -ENOSPC;
>>>>>>> goto err_free;
>>>>>>> }
>>>>
>>>> Thank you for the hint. So the whole function is:
>>>>
>>>> do {
>>>> order = min(order, (unsigned int)fls(pages) - 1);
>>>> BUG_ON(order > mm->max_order);
>>>> BUG_ON(order < min_order);
>>>>
>>>> do {
>>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>>> /* Allocate traversing within the range */
>>>> block = alloc_range_bias(mm, start, end, order);
>>>> else
>>>> /* Allocate from freelist */
>>>> block = alloc_from_freelist(mm, order, flags);
>>>>
>>>> if (!IS_ERR(block))
>>>> break;
>>>>
>>>> if (order-- == min_order) {
>>>> err = -ENOSPC;
>>>> goto err_free;
>>>> }
>>>> } while (1);
>>>>
>>>> mark_allocated(block);
>>>> mm->avail -= drm_buddy_block_size(mm, block);
>>>> kmemleak_update_trace(block);
>>>> list_add_tail(&block->link, &allocated);
>>>>
>>>> pages -= BIT(order);
>>>>
>>>> if (!pages)
>>>> break;
>>>> } while (1);
>>>>
>>>> Was the BUG_ON triggered for your case?
>>>>
>>>> BUG_ON(order < min_order);
>>> no, this BUG_ON is not triggered for this bug
>>>>
>>>> Please give more details.
>>>
>>> there is a chance when there is no space to allocate, order value
>>> decrements and reaches to 0 at one point, here we should exit the loop,
>>> otherwise, further order value decrements to -1 and do..while loop
>>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>>
>> Sorry, I do not see it. How can that be with order ≥ min_order and the
>> check `order-- == min_order`? Is min_order 0? Please explain that in the
>> next commit message.
>>
> please check v2, yes when min_order is 0, the above said situation may
> occur.And, since the order is unsigned int, I think it will not trigger
> the BUG_ON(order < min_order) when order becomes -1. Hence I think we
> needed a check !order to exit the loop.
Thank you for clarifying this. I still do not understand it though. With
order = fls(pages) - 1;
min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
is zorder` always non-negative? Let’s assume it is. Also, can min_order
get “negative” (wraps around)?
I would add BUG_ON statements for these cases?
BUG_ON(fls(pages) - 1 < 1);
BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);
Assuming “negative” is not possible, your case can only happen if
`order` and `min_order` are 0, right? If `order` is greater than 0, and
`min_order` is 0, the first BUG_ON in the while loop would be hit. If
`order` is 0 and `min_order` is greater than 0, everything should work
as the condition in `if (order-- == min_order)` is going to be true
eventually.
Could you please analyze this more. The current patch looks more like
papering over something, or I am missing something.
Kind regards,
Paul
PS: The commit message summary of your v2 should also be updated.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-16 6:58 ` Paul Menzel
0 siblings, 0 replies; 32+ messages in thread
From: Paul Menzel @ 2022-03-16 6:58 UTC (permalink / raw)
To: Arunpravin Paneer Selvam
Cc: intel-gfx, dri-devel, amd-gfx, daniel, alexander.deucher,
christian.koenig, matthew.auld
Dear Arunprivin,
Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
> On 15/03/22 9:14 pm, Paul Menzel wrote:
>> Am 15.03.22 um 16:42 schrieb Arunpravin:
>>
>>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>>
>>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>>
>>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>>
>>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>>> handle a situation in the condition order-- == min_order,
>>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>>> the loop. To avoid this problem, added a order check in
>>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>>> -ENOSPC
>>>>>>>
>>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>>
>>>>>> Please use your full name.
>>>>> okay
>>>>
>>>> You might also configure that in your email program.
>>> yes
>>
>> Not done yet though. ;-)
>>
> done in v2 :)
>>>>>>> ---
>>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>>
>>>>>> In what tree is that file?
>>>>>>
>>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3D&reserved=0
>>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3D&reserved=0
>>
>> Thank Outlook. Now everybody feels safe.
>>
>>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>>> if (!IS_ERR(block))
>>>>>>> break;
>>>>>>>
>>>>>>> - if (order-- == min_order) {
>>>>>>> + if (!order || order-- == min_order) {
>>>>>>> err = -ENOSPC;
>>>>>>> goto err_free;
>>>>>>> }
>>>>
>>>> Thank you for the hint. So the whole function is:
>>>>
>>>> do {
>>>> order = min(order, (unsigned int)fls(pages) - 1);
>>>> BUG_ON(order > mm->max_order);
>>>> BUG_ON(order < min_order);
>>>>
>>>> do {
>>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>>> /* Allocate traversing within the range */
>>>> block = alloc_range_bias(mm, start, end, order);
>>>> else
>>>> /* Allocate from freelist */
>>>> block = alloc_from_freelist(mm, order, flags);
>>>>
>>>> if (!IS_ERR(block))
>>>> break;
>>>>
>>>> if (order-- == min_order) {
>>>> err = -ENOSPC;
>>>> goto err_free;
>>>> }
>>>> } while (1);
>>>>
>>>> mark_allocated(block);
>>>> mm->avail -= drm_buddy_block_size(mm, block);
>>>> kmemleak_update_trace(block);
>>>> list_add_tail(&block->link, &allocated);
>>>>
>>>> pages -= BIT(order);
>>>>
>>>> if (!pages)
>>>> break;
>>>> } while (1);
>>>>
>>>> Was the BUG_ON triggered for your case?
>>>>
>>>> BUG_ON(order < min_order);
>>> no, this BUG_ON is not triggered for this bug
>>>>
>>>> Please give more details.
>>>
>>> there is a chance when there is no space to allocate, order value
>>> decrements and reaches to 0 at one point, here we should exit the loop,
>>> otherwise, further order value decrements to -1 and do..while loop
>>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>>
>> Sorry, I do not see it. How can that be with order ≥ min_order and the
>> check `order-- == min_order`? Is min_order 0? Please explain that in the
>> next commit message.
>>
> please check v2, yes when min_order is 0, the above said situation may
> occur.And, since the order is unsigned int, I think it will not trigger
> the BUG_ON(order < min_order) when order becomes -1. Hence I think we
> needed a check !order to exit the loop.
Thank you for clarifying this. I still do not understand it though. With
order = fls(pages) - 1;
min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
is zorder` always non-negative? Let’s assume it is. Also, can min_order
get “negative” (wraps around)?
I would add BUG_ON statements for these cases?
BUG_ON(fls(pages) - 1 < 1);
BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);
Assuming “negative” is not possible, your case can only happen if
`order` and `min_order` are 0, right? If `order` is greater than 0, and
`min_order` is 0, the first BUG_ON in the while loop would be hit. If
`order` is 0 and `min_order` is greater than 0, everything should work
as the condition in `if (order-- == min_order)` is going to be true
eventually.
Could you please analyze this more. The current patch looks more like
papering over something, or I am missing something.
Kind regards,
Paul
PS: The commit message summary of your v2 should also be updated.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
2022-03-16 6:58 ` [Intel-gfx] " Paul Menzel
(?)
@ 2022-03-21 6:15 ` Arunpravin Paneer Selvam
-1 siblings, 0 replies; 32+ messages in thread
From: Arunpravin Paneer Selvam @ 2022-03-21 6:15 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
On 16/03/22 12:28 pm, Paul Menzel wrote:
> Dear Arunprivin,
>
>
> Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
>
>> On 15/03/22 9:14 pm, Paul Menzel wrote:
>
>>> Am 15.03.22 um 16:42 schrieb Arunpravin:
>>>
>>>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>>>
>>>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>>>
>>>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>>>
>>>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>>>> handle a situation in the condition order-- == min_order,
>>>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>>>> the loop. To avoid this problem, added a order check in
>>>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>>>> -ENOSPC
>>>>>>>>
>>>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>>>
>>>>>>> Please use your full name.
>>>>>> okay
>>>>>
>>>>> You might also configure that in your email program.
>>>> yes
>>>
>>> Not done yet though. ;-)
>>>
>> done in v2 :)
>>>>>>>> ---
>>>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>>>
>>>>>>> In what tree is that file?
>>>>>>>
>>>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7Carunpravin.paneerselvam%40amd.com%7C439b31d360ef495ab13408da071a6e1f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637830107357395422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Z8KNmbUXmhk0xA8z7yHJN2j%2BRJ5VwpuMXww21mrC8x8%3D&reserved=0
>>>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7Carunpravin.paneerselvam%40amd.com%7C439b31d360ef495ab13408da071a6e1f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637830107357395422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Mwqy6NVTiR%2FoHFpLvXnQdE95kHoJJUEiig0Juz37ATQ%3D&reserved=0
>>>
>>> Thank Outlook. Now everybody feels safe.
>>>
>>>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>>>> if (!IS_ERR(block))
>>>>>>>> break;
>>>>>>>>
>>>>>>>> - if (order-- == min_order) {
>>>>>>>> + if (!order || order-- == min_order) {
>>>>>>>> err = -ENOSPC;
>>>>>>>> goto err_free;
>>>>>>>> }
>>>>>
>>>>> Thank you for the hint. So the whole function is:
>>>>>
>>>>> do {
>>>>> order = min(order, (unsigned int)fls(pages) - 1);
>>>>> BUG_ON(order > mm->max_order);
>>>>> BUG_ON(order < min_order);
>>>>>
>>>>> do {
>>>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>>>> /* Allocate traversing within the range */
>>>>> block = alloc_range_bias(mm, start, end, order);
>>>>> else
>>>>> /* Allocate from freelist */
>>>>> block = alloc_from_freelist(mm, order, flags);
>>>>>
>>>>> if (!IS_ERR(block))
>>>>> break;
>>>>>
>>>>> if (order-- == min_order) {
>>>>> err = -ENOSPC;
>>>>> goto err_free;
>>>>> }
>>>>> } while (1);
>>>>>
>>>>> mark_allocated(block);
>>>>> mm->avail -= drm_buddy_block_size(mm, block);
>>>>> kmemleak_update_trace(block);
>>>>> list_add_tail(&block->link, &allocated);
>>>>>
>>>>> pages -= BIT(order);
>>>>>
>>>>> if (!pages)
>>>>> break;
>>>>> } while (1);
>>>>>
>>>>> Was the BUG_ON triggered for your case?
>>>>>
>>>>> BUG_ON(order < min_order);
>>>> no, this BUG_ON is not triggered for this bug
>>>>>
>>>>> Please give more details.
>>>>
>>>> there is a chance when there is no space to allocate, order value
>>>> decrements and reaches to 0 at one point, here we should exit the loop,
>>>> otherwise, further order value decrements to -1 and do..while loop
>>>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>>>
>>> Sorry, I do not see it. How can that be with order ≥ min_order and the
>>> check `order-- == min_order`? Is min_order 0? Please explain that in the
>>> next commit message.
>>>
>> please check v2, yes when min_order is 0, the above said situation may
>> occur.And, since the order is unsigned int, I think it will not trigger
>> the BUG_ON(order < min_order) when order becomes -1. Hence I think we
>> needed a check !order to exit the loop.
>
> Thank you for clarifying this. I still do not understand it though. With
>
> order = fls(pages) - 1;
> min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
>
> is zorder` always non-negative? Let’s assume it is. Also, can min_order
> get “negative” (wraps around)?
>
> I would add BUG_ON statements for these cases?
>
> BUG_ON(fls(pages) - 1 < 1);
> BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);
>
> Assuming “negative” is not possible, your case can only happen if
> `order` and `min_order` are 0, right? If `order` is greater than 0, and
> `min_order` is 0, the first BUG_ON in the while loop would be hit. If
> `order` is 0 and `min_order` is greater than 0, everything should work
> as the condition in `if (order-- == min_order)` is going to be true
> eventually.
>
> Could you please analyze this more. The current patch looks more like
> papering over something, or I am missing something.
>
Thanks for the analysis, Matthew suggested to add a simple check, I have
sent the patch for the review.
Regards,
Arun
>
> Kind regards,
>
> Paul
>
>
> PS: The commit message summary of your v2 should also be updated.
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-21 6:15 ` Arunpravin Paneer Selvam
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin Paneer Selvam @ 2022-03-21 6:15 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, dri-devel, amd-gfx, alexander.deucher,
christian.koenig, matthew.auld
On 16/03/22 12:28 pm, Paul Menzel wrote:
> Dear Arunprivin,
>
>
> Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
>
>> On 15/03/22 9:14 pm, Paul Menzel wrote:
>
>>> Am 15.03.22 um 16:42 schrieb Arunpravin:
>>>
>>>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>>>
>>>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>>>
>>>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>>>
>>>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>>>> handle a situation in the condition order-- == min_order,
>>>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>>>> the loop. To avoid this problem, added a order check in
>>>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>>>> -ENOSPC
>>>>>>>>
>>>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>>>
>>>>>>> Please use your full name.
>>>>>> okay
>>>>>
>>>>> You might also configure that in your email program.
>>>> yes
>>>
>>> Not done yet though. ;-)
>>>
>> done in v2 :)
>>>>>>>> ---
>>>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>>>
>>>>>>> In what tree is that file?
>>>>>>>
>>>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7Carunpravin.paneerselvam%40amd.com%7C439b31d360ef495ab13408da071a6e1f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637830107357395422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Z8KNmbUXmhk0xA8z7yHJN2j%2BRJ5VwpuMXww21mrC8x8%3D&reserved=0
>>>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7Carunpravin.paneerselvam%40amd.com%7C439b31d360ef495ab13408da071a6e1f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637830107357395422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Mwqy6NVTiR%2FoHFpLvXnQdE95kHoJJUEiig0Juz37ATQ%3D&reserved=0
>>>
>>> Thank Outlook. Now everybody feels safe.
>>>
>>>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>>>> if (!IS_ERR(block))
>>>>>>>> break;
>>>>>>>>
>>>>>>>> - if (order-- == min_order) {
>>>>>>>> + if (!order || order-- == min_order) {
>>>>>>>> err = -ENOSPC;
>>>>>>>> goto err_free;
>>>>>>>> }
>>>>>
>>>>> Thank you for the hint. So the whole function is:
>>>>>
>>>>> do {
>>>>> order = min(order, (unsigned int)fls(pages) - 1);
>>>>> BUG_ON(order > mm->max_order);
>>>>> BUG_ON(order < min_order);
>>>>>
>>>>> do {
>>>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>>>> /* Allocate traversing within the range */
>>>>> block = alloc_range_bias(mm, start, end, order);
>>>>> else
>>>>> /* Allocate from freelist */
>>>>> block = alloc_from_freelist(mm, order, flags);
>>>>>
>>>>> if (!IS_ERR(block))
>>>>> break;
>>>>>
>>>>> if (order-- == min_order) {
>>>>> err = -ENOSPC;
>>>>> goto err_free;
>>>>> }
>>>>> } while (1);
>>>>>
>>>>> mark_allocated(block);
>>>>> mm->avail -= drm_buddy_block_size(mm, block);
>>>>> kmemleak_update_trace(block);
>>>>> list_add_tail(&block->link, &allocated);
>>>>>
>>>>> pages -= BIT(order);
>>>>>
>>>>> if (!pages)
>>>>> break;
>>>>> } while (1);
>>>>>
>>>>> Was the BUG_ON triggered for your case?
>>>>>
>>>>> BUG_ON(order < min_order);
>>>> no, this BUG_ON is not triggered for this bug
>>>>>
>>>>> Please give more details.
>>>>
>>>> there is a chance when there is no space to allocate, order value
>>>> decrements and reaches to 0 at one point, here we should exit the loop,
>>>> otherwise, further order value decrements to -1 and do..while loop
>>>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>>>
>>> Sorry, I do not see it. How can that be with order ≥ min_order and the
>>> check `order-- == min_order`? Is min_order 0? Please explain that in the
>>> next commit message.
>>>
>> please check v2, yes when min_order is 0, the above said situation may
>> occur.And, since the order is unsigned int, I think it will not trigger
>> the BUG_ON(order < min_order) when order becomes -1. Hence I think we
>> needed a check !order to exit the loop.
>
> Thank you for clarifying this. I still do not understand it though. With
>
> order = fls(pages) - 1;
> min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
>
> is zorder` always non-negative? Let’s assume it is. Also, can min_order
> get “negative” (wraps around)?
>
> I would add BUG_ON statements for these cases?
>
> BUG_ON(fls(pages) - 1 < 1);
> BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);
>
> Assuming “negative” is not possible, your case can only happen if
> `order` and `min_order` are 0, right? If `order` is greater than 0, and
> `min_order` is 0, the first BUG_ON in the while loop would be hit. If
> `order` is 0 and `min_order` is greater than 0, everything should work
> as the condition in `if (order-- == min_order)` is going to be true
> eventually.
>
> Could you please analyze this more. The current patch looks more like
> papering over something, or I am missing something.
>
Thanks for the analysis, Matthew suggested to add a simple check, I have
sent the patch for the review.
Regards,
Arun
>
> Kind regards,
>
> Paul
>
>
> PS: The commit message summary of your v2 should also be updated.
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] drm: Fix a infinite loop condition when order becomes 0
@ 2022-03-21 6:15 ` Arunpravin Paneer Selvam
0 siblings, 0 replies; 32+ messages in thread
From: Arunpravin Paneer Selvam @ 2022-03-21 6:15 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-gfx, dri-devel, amd-gfx, daniel, alexander.deucher,
christian.koenig, matthew.auld
On 16/03/22 12:28 pm, Paul Menzel wrote:
> Dear Arunprivin,
>
>
> Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
>
>> On 15/03/22 9:14 pm, Paul Menzel wrote:
>
>>> Am 15.03.22 um 16:42 schrieb Arunpravin:
>>>
>>>> On 15/03/22 2:35 pm, Paul Menzel wrote:
>>>
>>>>> Am 15.03.22 um 10:01 schrieb Arunpravin:
>>>>>
>>>>>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>>>>>
>>>>>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
>>>>>>>> handle a situation in the condition order-- == min_order,
>>>>>>>> when order = 0, leading to order = -1, it now won't exit
>>>>>>>> the loop. To avoid this problem, added a order check in
>>>>>>>> the same condition, (i.e) when order is 0, we return
>>>>>>>> -ENOSPC
>>>>>>>>
>>>>>>>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>>>>>>>
>>>>>>> Please use your full name.
>>>>>> okay
>>>>>
>>>>> You might also configure that in your email program.
>>>> yes
>>>
>>> Not done yet though. ;-)
>>>
>> done in v2 :)
>>>>>>>> ---
>>>>>>>> drivers/gpu/drm/drm_buddy.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>>>>>>>> index 72f52f293249..5ab66aaf2bbd 100644
>>>>>>>> --- a/drivers/gpu/drm/drm_buddy.c
>>>>>>>> +++ b/drivers/gpu/drm/drm_buddy.c
>>>>>>>
>>>>>>> In what tree is that file?
>>>>>>>
>>>>>> drm-tip - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2F&data=04%7C01%7Carunpravin.paneerselvam%40amd.com%7C439b31d360ef495ab13408da071a6e1f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637830107357395422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Z8KNmbUXmhk0xA8z7yHJN2j%2BRJ5VwpuMXww21mrC8x8%3D&reserved=0
>>>>>> drm-misc-next - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2F&data=04%7C01%7Carunpravin.paneerselvam%40amd.com%7C439b31d360ef495ab13408da071a6e1f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637830107357395422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Mwqy6NVTiR%2FoHFpLvXnQdE95kHoJJUEiig0Juz37ATQ%3D&reserved=0
>>>
>>> Thank Outlook. Now everybody feels safe.
>>>
>>>>>>>> @@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
>>>>>>>> if (!IS_ERR(block))
>>>>>>>> break;
>>>>>>>>
>>>>>>>> - if (order-- == min_order) {
>>>>>>>> + if (!order || order-- == min_order) {
>>>>>>>> err = -ENOSPC;
>>>>>>>> goto err_free;
>>>>>>>> }
>>>>>
>>>>> Thank you for the hint. So the whole function is:
>>>>>
>>>>> do {
>>>>> order = min(order, (unsigned int)fls(pages) - 1);
>>>>> BUG_ON(order > mm->max_order);
>>>>> BUG_ON(order < min_order);
>>>>>
>>>>> do {
>>>>> if (flags & DRM_BUDDY_RANGE_ALLOCATION)
>>>>> /* Allocate traversing within the range */
>>>>> block = alloc_range_bias(mm, start, end, order);
>>>>> else
>>>>> /* Allocate from freelist */
>>>>> block = alloc_from_freelist(mm, order, flags);
>>>>>
>>>>> if (!IS_ERR(block))
>>>>> break;
>>>>>
>>>>> if (order-- == min_order) {
>>>>> err = -ENOSPC;
>>>>> goto err_free;
>>>>> }
>>>>> } while (1);
>>>>>
>>>>> mark_allocated(block);
>>>>> mm->avail -= drm_buddy_block_size(mm, block);
>>>>> kmemleak_update_trace(block);
>>>>> list_add_tail(&block->link, &allocated);
>>>>>
>>>>> pages -= BIT(order);
>>>>>
>>>>> if (!pages)
>>>>> break;
>>>>> } while (1);
>>>>>
>>>>> Was the BUG_ON triggered for your case?
>>>>>
>>>>> BUG_ON(order < min_order);
>>>> no, this BUG_ON is not triggered for this bug
>>>>>
>>>>> Please give more details.
>>>>
>>>> there is a chance when there is no space to allocate, order value
>>>> decrements and reaches to 0 at one point, here we should exit the loop,
>>>> otherwise, further order value decrements to -1 and do..while loop
>>>> doesn't exit. Hence added a check to exit the loop if order value becomes 0.
>>>
>>> Sorry, I do not see it. How can that be with order ≥ min_order and the
>>> check `order-- == min_order`? Is min_order 0? Please explain that in the
>>> next commit message.
>>>
>> please check v2, yes when min_order is 0, the above said situation may
>> occur.And, since the order is unsigned int, I think it will not trigger
>> the BUG_ON(order < min_order) when order becomes -1. Hence I think we
>> needed a check !order to exit the loop.
>
> Thank you for clarifying this. I still do not understand it though. With
>
> order = fls(pages) - 1;
> min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
>
> is zorder` always non-negative? Let’s assume it is. Also, can min_order
> get “negative” (wraps around)?
>
> I would add BUG_ON statements for these cases?
>
> BUG_ON(fls(pages) - 1 < 1);
> BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);
>
> Assuming “negative” is not possible, your case can only happen if
> `order` and `min_order` are 0, right? If `order` is greater than 0, and
> `min_order` is 0, the first BUG_ON in the while loop would be hit. If
> `order` is 0 and `min_order` is greater than 0, everything should work
> as the condition in `if (order-- == min_order)` is going to be true
> eventually.
>
> Could you please analyze this more. The current patch looks more like
> papering over something, or I am missing something.
>
Thanks for the analysis, Matthew suggested to add a simple check, I have
sent the patch for the review.
Regards,
Arun
>
> Kind regards,
>
> Paul
>
>
> PS: The commit message summary of your v2 should also be updated.
>
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2022-03-21 6:05 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-14 19:40 [PATCH] drm: Fix a infinite loop condition when order becomes 0 Arunpravin
2022-03-14 19:40 ` Arunpravin
2022-03-14 19:40 ` [Intel-gfx] " Arunpravin
2022-03-15 1:11 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-03-15 5:36 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-15 8:19 ` [PATCH] " Paul Menzel
2022-03-15 8:19 ` [Intel-gfx] " Paul Menzel
2022-03-15 8:19 ` Paul Menzel
2022-03-15 9:01 ` Arunpravin
2022-03-15 9:01 ` Arunpravin
2022-03-15 9:01 ` [Intel-gfx] " Arunpravin
2022-03-15 9:05 ` Paul Menzel
2022-03-15 9:05 ` Paul Menzel
2022-03-15 9:05 ` [Intel-gfx] " Paul Menzel
2022-03-15 15:42 ` Arunpravin
2022-03-15 15:42 ` [Intel-gfx] " Arunpravin
2022-03-15 15:42 ` Arunpravin
2022-03-15 15:44 ` Paul Menzel
2022-03-15 15:44 ` Paul Menzel
2022-03-15 15:44 ` [Intel-gfx] " Paul Menzel
2022-03-16 6:49 ` Arunpravin Paneer Selvam
2022-03-16 6:49 ` Arunpravin Paneer Selvam
2022-03-16 6:49 ` [Intel-gfx] " Arunpravin Paneer Selvam
2022-03-16 6:58 ` Paul Menzel
2022-03-16 6:58 ` Paul Menzel
2022-03-16 6:58 ` [Intel-gfx] " Paul Menzel
2022-03-21 6:15 ` Arunpravin Paneer Selvam
2022-03-21 6:15 ` Arunpravin Paneer Selvam
2022-03-21 6:15 ` [Intel-gfx] " Arunpravin Paneer Selvam
2022-03-15 11:31 ` Matthew Auld
2022-03-15 11:31 ` Matthew Auld
2022-03-15 11:31 ` [Intel-gfx] " Matthew Auld
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.