From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934444AbcCNOdw (ORCPT ); Mon, 14 Mar 2016 10:33:52 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:35388 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932705AbcCNOdu (ORCPT ); Mon, 14 Mar 2016 10:33:50 -0400 MIME-Version: 1.0 In-Reply-To: <1457469654-17059-2-git-send-email-linux@rasmusvillemoes.dk> References: <1457469654-17059-1-git-send-email-linux@rasmusvillemoes.dk> <1457469654-17059-2-git-send-email-linux@rasmusvillemoes.dk> From: Oded Gabbay Date: Mon, 14 Mar 2016 16:33:18 +0200 Message-ID: Subject: Re: [RFC 1/7] drm/amdkfd: avoid fragile and inefficient snprintf use To: Rasmus Villemoes Cc: Kees Cook , Andrew Morton , David Airlie , Maling list - DRI developers , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes 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 I saw there were some different opinions on this. Have the fixes to the other drivers been taken ? Oded