From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by kanga.kvack.org (Postfix) with ESMTP id BB5ED6B00EA for ; Mon, 25 Nov 2013 15:31:12 -0500 (EST) Received: by mail-pd0-f176.google.com with SMTP id w10so6225756pde.21 for ; Mon, 25 Nov 2013 12:31:12 -0800 (PST) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org. [140.211.169.12]) by mx.google.com with ESMTP id ei3si14205235pbc.320.2013.11.25.12.31.10 for ; Mon, 25 Nov 2013 12:31:11 -0800 (PST) Date: Mon, 25 Nov 2013 12:31:08 -0800 From: Andrew Morton Subject: Re: [patch -mm] mm, mempolicy: silence gcc warning Message-Id: <20131125123108.79c80eb59c2b1bc41c879d9e@linux-foundation.org> In-Reply-To: References: <20131120141534.06ea091ca53b1dec60ace63d@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: KOSAKI Motohiro Cc: David Rientjes , Fengguang Wu , Kees Cook , Rik van Riel , "linux-mm@kvack.org" On Sat, 23 Nov 2013 15:49:08 -0500 KOSAKI Motohiro wrote: > >> --- a/mm/mempolicy.c > >> +++ b/mm/mempolicy.c > >> @@ -2950,7 +2950,7 @@ void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol) > >> return; > >> } > >> > >> - p += snprintf(p, maxlen, policy_modes[mode]); > >> + p += snprintf(p, maxlen, "%s", policy_modes[mode]); > >> > >> if (flags & MPOL_MODE_FLAGS) { > >> p += snprintf(p, buffer + maxlen - p, "="); > > > > mutter. There are no '%'s in policy_modes[]. Maybe we should only do > > this #ifdef CONFIG_KEES. > > > > mpol_to_str() would be simpler (and slower) if it was switched to use > > strncat(). > > IMHO, you should queue this patch. mpol_to_str() is not fast path at all and > I don't want worry about false positive warning. Yup, it's in mainline. > > It worries me that the CONFIG_NUMA=n version of mpol_to_str() doesn't > > stick a '\0' into *buffer. Hopefully it never gets called... > > Don't worry. It never happens. Currently, all of caller depend on CONFIG_NUMA. > However it would be nice if CONFIG_NUMA=n version of mpol_to_str() is > implemented > more carefully. I don't know who's mistake. Put a BUG() in there? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org