Messages in this thread | | | From | Oded Gabbay <> | Date | Mon, 14 Mar 2016 16:33:18 +0200 | Subject | Re: [RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use |
| |
On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes <linux@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@rasmusvillemoes.dk>
I saw there were some different opinions on this. Have the fixes to the other drivers been taken ?
Oded
| |