On Sat, Jul 07, 2018 at 08:23:30PM -0300, Rodrigo Siqueira wrote:
> This patch fix the following GCC warning:
>
> intel_gvtg_test.c: In function ‘create_guest’:
> intel_gvtg_test.c:127:50: warning: ‘%s’ directive writing up to 4095
> bytes into a region of size 4077 [-Wformat-overflow=]
> [..]
> intel_gvtg_test.c:127:5: note: ‘sprintf’ output between 36 and 8226
> bytes into a destination of size 4096
> [..]
>
> This patch changes the approach for allocating memory to handle QEMU
> commands by dynamically allocate space to save the whole command.
>
> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@xxxxxxxxx>
> ---
> tools/intel_gvtg_test.c | 27 ++++++++++++++++++---------
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c
> index 659b7956..93c05e37 100644
> --- a/tools/intel_gvtg_test.c
> +++ b/tools/intel_gvtg_test.c
> @@ -120,16 +120,25 @@ static int check_tools(void)
>
> static void create_guest(void)
> {
> - char create_qcow_cmd[PATH_MAX] = {0};
> - char create_vgpu_cmd[PATH_MAX] = {0};
> - char create_instance_cmd[PATH_MAX] = {0};
> + unsigned int max_size_cmd = sysconf(_SC_ARG_MAX);
That's 2097152 on my system. Quite an overkill. I know that we have lazy
page table assigement, but memseting the whole 2GB defeats it.
The qemu invocation looks like the longest one, and we have 3
components that may take up to PATH_MAX each and some extra stuff, so
going with 4*PATH_MAX should be enough.
BTW, why do you memset it to 0 before each sprintf?
--
Cheers,
Arek
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
