Re: [RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use

From: Oded Gabbay
Date: Mon Mar 14 2016 - 10:33:55 EST


On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
<linux@xxxxxxxxxxxxxxxxxx> wrote:
> Passing overlapping source and destination buffers to snprintf
> formally has undefined behaviour and is rather fragile. While the
> rather special case of passing the output buffer as the argument
> corresponding to a leading "%s" in the format string currently works
> with the kernel's printf implementation, that won't necessarily always
> be the case (it's also needlessly inefficient, though that doesn't
> matter much for sysfs files). Moreover, it might give the false
> impression that other ways of overlapping source and destination
> buffers would be ok.
>
> The standard way of appending to a buffer with snprintf is to keep
> track of the current string length (and thus also the remaining
> available space). Using scnprintf ensures that the 'ret' variable will
> always be strictly less than PAGE_SIZE, so we'll never pass a negative
> buffer size to scnprintf, and we'll return the proper length to the
> upper sysfs layer, whether truncation has happened or not.
>
> Signed-off-by: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>

I saw there were some different opinions on this.
Have the fixes to the other drivers been taken ?

Oded