Received: by 10.213.65.68 with SMTP id h4csp393499imn; Tue, 13 Mar 2018 07:43:11 -0700 (PDT) X-Google-Smtp-Source: AG47ELsGEQXoovn75bUU3tbp3Hj95yQxad5BVAvEDWIlBjPYc8QPf4MJJ2AU0zACyNLv84NWohkD X-Received: by 10.98.63.75 with SMTP id m72mr886130pfa.122.1520952191754; Tue, 13 Mar 2018 07:43:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520952191; cv=none; d=google.com; s=arc-20160816; b=gXZ/VxBuyCj3lfl9imTysC+VUXReXouBGMQeFruABLl27WI+rgAOiK4vDoQ5R3gxzy quWc8UjzEbZKES8VKz0ll6bhHOQCxZ8z24zgxIxAC6uMtHkesLY6lzsApsP0UAHyr/PZ wVnmevI3CGObZjK9OI8GezF4536ax4uq7OvbTakbkCUF7EXhHdpV4IU3ESqCIfq3OGJe pn235Sviwdb9G2IGUP/FXGYlgLkXpfMxWq99sWUR3s+u3ghTJCYNZPvBt+sD0hCEyCKP 1/2brL4t8KJNa/pUUr7Bd0kQm0xqUFK/P9SZMSKXtJchKr3dKAvc476bMwzFofNgYufD lbNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=0adenaK07cTnQxKw5onDszQfDSiCj9h3qs6sKVWsCCQ=; b=Y/26aOYThpw67cnlBpZeiox66fyAO3hFJ5pr4hyA98VOzCdrnUmtyFoY/cDTI94WC4 aHltzOD7E2eNkvxMtyNlzkeIckzRJbGAw03eGjCnQ2YE7Yh+ah8XChxXsokyC+L+YmSk Ky4/zFyIFraWDH8yraW25nalwnsuBbI4sUfU6di6epBmbNMDqQmwc6Vxc+HiauQ6+Rwe vdb3wbXuSYdMLHa2mN1dilr7z8bdr2p1LKDUxYo9ex6xNjgkXGFSYHDEyzk2z3CzVGPe 6M+0vegkQ/M/vv8QAXS9EkAHc9ekh+eGtc0FTKoOiTvRwfi7sJ3Bf4X+I8x+0ZfhTNYw mDUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=KFICzZcg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 99-v6si197780plc.601.2018.03.13.07.42.56; Tue, 13 Mar 2018 07:43:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=KFICzZcg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752257AbeCMOmB (ORCPT + 99 others); Tue, 13 Mar 2018 10:42:01 -0400 Received: from mail-lf0-f43.google.com ([209.85.215.43]:45786 "EHLO mail-lf0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764AbeCMOmA (ORCPT ); Tue, 13 Mar 2018 10:42:00 -0400 Received: by mail-lf0-f43.google.com with SMTP id h127-v6so29157381lfg.12 for ; Tue, 13 Mar 2018 07:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0adenaK07cTnQxKw5onDszQfDSiCj9h3qs6sKVWsCCQ=; b=KFICzZcgi5BahngdyZy3EmFtDRW5ZjwlgKdE+spNkX8HB5A0BrYirEp6OOJ9aWc1HI jP2qfa44nEuLzQRO2WTQsrxia/6mQBmrdmW8Si3H4mCm8+oqoRWHIkytttgQSS8BjeeD yC3pjNHv1tOznVabCyNM5X2Pg0pLbUmrzXkLg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0adenaK07cTnQxKw5onDszQfDSiCj9h3qs6sKVWsCCQ=; b=gm2x5/6KXTTmjEa1L1Bgyje5M183yzbquUMn2Yf7wQY10UOgbUSmxuVt3YnnHWviQx 0b2FNBop6s5JYc9gx4Mv+AnqHVGXudR0KYMPhr8RBJ1SrihyTlGRjbhym6Emm/OI0ddm Nj+ysBuAczblshNyikNUssQAyHpH4blS01+0CRHGQj37V1e1Ub5ImJHM1oXqbLyZSoqv cZb/6wbiSkAhr3z0b3JiFoNFfSlC0+6adZMUxC95dhsRh8XDrLMa82c7iVLtsc82+x/2 jxQKPv/hA32SlFvo07Km7cOqQMCAhH7C9ga9ob4Z4b9h2lAKhq+kgUzk+POmelYcSXS7 /DDQ== X-Gm-Message-State: AElRT7FVSgbaKl5cX1zWcwqcBTVyKX3Vh0I4g5iCoLmwicTLq4mCSgjN qofzFSyXSyIalXCdI/UFwov0pzTgXWc= X-Received: by 10.46.87.72 with SMTP id r8mr677337ljd.93.1520952118146; Tue, 13 Mar 2018 07:41:58 -0700 (PDT) Received: from [172.16.11.22] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id v4sm21072lje.53.2018.03.13.07.41.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 07:41:57 -0700 (PDT) Subject: Re: [PATCH] test_rhashtable: avoid gcc-8 -Wformat-overflow warning To: Arnd Bergmann , "David S. Miller" , Herbert Xu , Paul Blakey Cc: Martin Sebor , Florian Westphal , Phil Sutter , Tom Herbert , linux-kernel@vger.kernel.org References: <20180313132155.203220-1-arnd@arndb.de> From: Rasmus Villemoes Message-ID: <0ab7c9f6-e677-3bc9-df05-9895870a3c32@rasmusvillemoes.dk> Date: Tue, 13 Mar 2018 15:41:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180313132155.203220-1-arnd@arndb.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-03-13 14:21, Arnd Bergmann wrote: > gcc-8 warns about a code pattern that is used in the newly added > test_rhashtable code: > > lib/test_rhashtable.c: In function 'print_ht': > lib/test_rhashtable.c:511:21: error: ' > bucket[' directive writing 8 bytes into a region of size between 1 and 512 [-Werror=format-overflow=] > sprintf(buff, "%s\nbucket[%d] -> ", buff, i); > ^~~~~~~~~ > lib/test_rhashtable.c:511:4: note: 'sprintf' output between 15 and 536 bytes into a destination of size 512 > sprintf(buff, "%s\nbucket[%d] -> ", buff, i); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The problem here is using the same fixed-length buffer as input and output > of snprintf(), which for an unbounded loop has an actual potential to > overflow the buffer. The '512' byte length was apparently chosen to > be "long enough" to prevent that in practice, but without any specific > guarantees of being the smallest safe size. well, 1024 would certainly be enough, because the result is anyway passed to printk() which formats into a buffer of that size, so anything more would certainly just be thrown away... > I can see three possible ways to avoid this warning: > > - rewrite the code to use pointer arithmetic to forward the buffer, > rather than copying the buffer itself. This is a more conventional > use of sprintf(), and it avoids the warning, but is not any more > safe than the original code. > - Rewrite the function in a safe way that avoids both the potential > overflow and the warning. > - Ask the gcc developers to not warn for this pattern if we consider > the warning to be inappropriate. > > This patch implements the first of the above, as an illustration of > the problem, and the simplest workaround. If you use scnprintf() and forward the printed length you can get rid of the potential buffer overrun: len = 0; ... len += scnprintf(buf + len, sizeof(buf) - len, fmt, args...) scnprintf has the property that if you pass in a positive value, you get back something that is strictly less, so with the above pattern, we might eventually have sizeof(buf)-len==1, so all subsequent scnprintfs return 0, but we never overflow the buffer. The effect is thus the same as if you had done all the formatting with a single snprintf() call. FWIW, I sent an RFC [1] two years ago trying to get rid of all snprintf(buf, ..., "%s...", buf, ...), because I think it's too fragile (it obviously breaks horribly if anything precedes the %s with buf as its argument), but others disagreed and said that the kernel's vsnprintf() instead should be documented to support that special case of overlapping src and dst. I don't really recall what happened with the patches, perhaps some got applied, but if not, maybe gcc-8 will now warn about those places. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1096481.html > Fixes: 499ac3b60f65 ("test_rhashtable: add test case for rhltable with duplicate objects") > Cc: Martin Sebor > Signed-off-by: Arnd Bergmann > --- > My patch is untested, please try it out before applying. > --- > lib/test_rhashtable.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c > index f4000c137dbe..a0f4fb03d2de 100644 > --- a/lib/test_rhashtable.c > +++ b/lib/test_rhashtable.c > @@ -496,6 +496,7 @@ static unsigned int __init print_ht(struct rhltable *rhlt) > struct rhashtable *ht; > const struct bucket_table *tbl; > char buff[512] = ""; > + char *buffp = buff; > unsigned int i, cnt = 0; > > ht = &rhlt->ht; > @@ -508,18 +509,18 @@ static unsigned int __init print_ht(struct rhltable *rhlt) > next = !rht_is_a_nulls(pos) ? rht_dereference(pos->next, ht) : NULL; > > if (!rht_is_a_nulls(pos)) { > - sprintf(buff, "%s\nbucket[%d] -> ", buff, i); > + buffp += sprintf(buffp, "\nbucket[%d] -> ", i); > } > > while (!rht_is_a_nulls(pos)) { > struct rhlist_head *list = container_of(pos, struct rhlist_head, rhead); > - sprintf(buff, "%s[[", buff); > + buffp += sprintf(buffp, "[["); > do { > pos = &list->rhead; > list = rht_dereference(list->next, ht); > p = rht_obj(ht, pos); > > - sprintf(buff, "%s val %d (tid=%d)%s", buff, p->value.id, p->value.tid, > + buffp += sprintf(buffp, "val %d (tid=%d)%s", p->value.id, p->value.tid, > list? ", " : " "); this removes a space before val, not sure that was intended? > cnt++; > } while (list); > @@ -528,7 +529,7 @@ static unsigned int __init print_ht(struct rhltable *rhlt) > next = !rht_is_a_nulls(pos) ? > rht_dereference(pos->next, ht) : NULL; > > - sprintf(buff, "%s]]%s", buff, !rht_is_a_nulls(pos) ? " -> " : ""); > + buffp += sprintf(buffp, "]]%s", !rht_is_a_nulls(pos) ? " -> " : ""); > } > } > printk(KERN_ERR "\n---- ht: ----%s\n-------------\n", buff); >