[PATCH i-g-t v4] Fix memory access issue due to variable block scope

Kamil Konieczny kamil.konieczny at linux.intel.com
Wed Mar 27 18:43:30 UTC 2024


Hi Peter,
On 2024-03-27 at 07:59:27 +0100, Peter Senna Tschudin wrote:

One nit about subject, as you can see on patchwork
https://patchwork.freedesktop.org/project/igt/series/?ordering=-last_updated

we use test name as prefix for a patch, so instead of:

[PATCH i-g-t v4] Fix memory access issue due to variable block

it should be:

[PATCH i-g-t v4] tests/intel/gem_exec_capture: Fix many-* subtests

> 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.

Yes, this way it works but I still think it would be better
to use function for it.

> 
> Signed-off-by: Peter Senna Tschudin <me at 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); \

Yes, it is a fix for a problem but something strange is
happening here, imho we need to debug it more.

>  				break; \
>               } \
>               e = &saved.engine; \
>       		igt_assert(e); \

Two above lines are not needed, 'e' will always be != NULL.

Regards,
Kamil

> -		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
> 


More information about the igt-dev mailing list