Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Senna Tschudin <me@petersenna.com>
To: igt-dev@lists.freedesktop.org, kamil.konieczny@linux.intel.com,
	andi.shyti@linux.intel.com
Subject: [PATCH i-g-t v4] Fix memory access issue due to variable block scope
Date: Wed, 27 Mar 2024 07:59:27 +0100	[thread overview]
Message-ID: <20240327065928.5522-1-me@petersenna.com> (raw)

This patch fixes the tests many-4k-incremental and many-4k-zero from
gem_exec_capture that are currently failing with an invalid file
descriptor error.

tests/intel/gem_exec_capture.c
    many(), userptr(), capture_invisible()
        find_first_available_engine()
            for_each_ctx_engine()
                for_each_ctx_cfg_engine()

find_first_available_engine() expects a struct intel_execution_engine2
*e as parameter. for_each_ctx_cfg_engine() allocates a struct
intel_engine_data ed inside a for loop and then update e to point to an
element of ed.

The problem is that ed has the block scope of the for loop, and trying
to access its content through e after the for loop has ended creates
undefined behavior.

This patch updates e to point to the same content at a different memory
region, to avoid the block scope of ed.

v4: Move `saved = configure_hangs(fd, e, ctx->id);` to inside the for
loop where it is safe to use 'e'. This is because 'e' points to an
element of a variable that is defined with the block scope of the for
loop.

Signed-off-by: Peter Senna Tschudin <me@petersenna.com>
---
 tests/intel/gem_exec_capture.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/intel/gem_exec_capture.c b/tests/intel/gem_exec_capture.c
index 57b178f3e..f7b10bdd4 100644
--- a/tests/intel/gem_exec_capture.c
+++ b/tests/intel/gem_exec_capture.c
@@ -665,10 +665,12 @@ static bool needs_recoverable_ctx(int fd)
 		ctx = intel_ctx_create_all_physical(fd); \
 		igt_assert(ctx); \
 		for_each_ctx_engine(fd, ctx, e) \
-			for_each_if(gem_class_can_store_dword(fd, e->class)) \
+			for_each_if(gem_class_can_store_dword(fd, e->class)) { \
+				saved = configure_hangs(fd, e, ctx->id); \
 				break; \
+			}  \
+		e = &saved.engine; \
 		igt_assert(e); \
-		saved = configure_hangs(fd, e, ctx->id); \
 	} while(0)
 
 static void many(int fd, int dir, uint64_t size, unsigned int flags)
-- 
2.44.0


             reply	other threads:[~2024-03-27  6:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27  6:59 Peter Senna Tschudin [this message]
2024-03-27  7:51 ` ✓ CI.xeBAT: success for Fix memory access issue due to variable block scope (rev4) Patchwork
2024-03-27  7:59 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-03-27 18:43 ` [PATCH i-g-t v4] Fix memory access issue due to variable block scope Kamil Konieczny
2024-03-28  6:55   ` Peter Senna Tschudin
2024-03-28  7:10     ` Peter Senna Tschudin
2024-03-28  6:27 ` ✗ GitLab.Pipeline: warning for Fix memory access issue due to variable block scope (rev5) Patchwork
2024-03-28  7:03 ` ✓ CI.xeBAT: success " Patchwork
2024-03-28 12:42 ` [PATCH i-g-t v5] tests/intel/gem_exec_capture: Fix many-* subtests Peter Senna Tschudin
2024-03-28 15:49   ` Kamil Konieczny
2024-03-30 14:26     ` Peter Senna Tschudin
2024-03-28 18:59 ` ✗ Fi.CI.BAT: failure for Fix memory access issue due to variable block scope (rev6) Patchwork
2024-03-30 14:19 ` [PATCH i-g-t v6 1/2] tests/intel/gem_exec_capture: Fix many-* subtests Peter Senna Tschudin
2024-03-30 14:19   ` [PATCH i-g-t v6 2/2] Skip the test when no engines are found Peter Senna Tschudin
2024-04-02 16:17     ` Kamil Konieczny
2024-04-03 13:58       ` Peter Senna Tschudin
2024-04-02 16:06   ` [PATCH i-g-t v6 1/2] tests/intel/gem_exec_capture: Fix many-* subtests Kamil Konieczny
2024-03-30 15:02 ` ✓ CI.xeBAT: success for Fix memory access issue due to variable block scope (rev7) Patchwork
2024-03-30 15:03 ` ✗ Fi.CI.BAT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240327065928.5522-1-me@petersenna.com \
    --to=me@petersenna.com \
    --cc=andi.shyti@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=kamil.konieczny@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox