[RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use
Oded Gabbay
oded.gabbay at gmail.com
Mon Mar 14 14:33:18 UTC 2016
On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
<linux at rasmusvillemoes.dk> 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 at rasmusvillemoes.dk>
I saw there were some different opinions on this.
Have the fixes to the other drivers been taken ?
Oded
More information about the dri-devel
mailing list