[Intel-gfx] [PATCH] drm: Don't split up debug output

Thierry Reding thierry.reding at gmail.com
Mon Nov 18 11:55:39 CET 2013


On Sun, Nov 17, 2013 at 10:25:02PM +0100, Daniel Vetter wrote:
> Otherwise we risk that the 2nd part of the line ends up on a line of
> it's own, which means a kernel dmesg line without a log level. This
> then upsets the dmesg checker in piglit.
> 
> Only really happens in some of the truly nasty igt testcases which
> race cache dropping (through debugfs) with other gem operations.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
>  drivers/gpu/drm/drm_stub.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index f53d5246979c..74e0357c1c38 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -99,13 +99,19 @@ void drm_ut_debug_printk(unsigned int request_level,
>  			 const char *function_name,
>  			 const char *format, ...)
>  {
> +	struct va_format vaf;
>  	va_list args;
>  
>  	if (drm_debug & request_level) {
> -		if (function_name)
> -			printk(KERN_DEBUG "[%s:%s], ", prefix, function_name);
>  		va_start(args, format);
> -		vprintk(format, args);
> +		vaf.fmt = format;
> +		vaf.va = &args;
> +
> +		if (function_name)
> +			printk(KERN_DEBUG "[%s:%s], %pV", prefix,
> +			       function_name, &vaf);
> +		else
> +			printk(KERN_DEBUG "%pV", &vaf);
>  		va_end(args);
>  	}
>  }

According to Documentation/printk-formats.txt, usage of %pV is not
recommended unless the format string and va_list can be properly
verified for correctness.

I guess we leave it up to the compiler to do that verification using the
__printf() annotation, so I think it should be fine to use it here:

Reviewed-by: Thierry Reding <treding at nvidia.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20131118/41a49856/attachment.sig>


More information about the Intel-gfx mailing list