From patchwork Mon Feb 23 22:55:51 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rasmus Villemoes X-Patchwork-Id: 5868341 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 763569F36A for ; Mon, 23 Feb 2015 22:56:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7902620645 for ; Mon, 23 Feb 2015 22:56:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3806820644 for ; Mon, 23 Feb 2015 22:55:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752331AbbBWWz5 (ORCPT ); Mon, 23 Feb 2015 17:55:57 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:43306 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753181AbbBWWzz (ORCPT ); Mon, 23 Feb 2015 17:55:55 -0500 Received: by lbiw7 with SMTP id w7so21356999lbi.10 for ; Mon, 23 Feb 2015 14:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=P4B+DjIsUOGaxcBqkHXClZS9Tr3NYdgqoZLMX2ygfLA=; b=eamqqLLtz8VDygjzMvr0cTTHKn3ItNVVckiMATNa7BBjCn0JSA31aLGC59at6LAPTc AwwzMRD+gNhkfM2JdJ5FiSNnCLA5Uj/JHEvh1q3wcpWHNKC+Pi4CqF3A2Qi6mhDOKyGn T1V+CZu7HXai8Y7K8zYNuQQNYvJRRoQbYQxFE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=P4B+DjIsUOGaxcBqkHXClZS9Tr3NYdgqoZLMX2ygfLA=; b=enVCaskpAe7vEIXduUmMOsMofh90juoAZK1qrPdELFCulPF5nEbI573Ce5rukgP98s jGPDpq+8QnlkEkbSF2YXuYpjc38y2+0t/pkwJhmR9gmOcYR4KHQ9kv1YspD+cDQxQ/Wv 7TLcQ5y5mboFehLri7zvtqDV4zvST3NxUCBcroqLGkMKzsIkvz6RUklod+rkZnBPxtkK xuxjx8xlblcDKX5JydkPiIBKZZ6Jjw9cRPZ4b41x/nLMsmqIZWIQba/IIkHBtZCy/6sB y6UKcBKmWIO48IU5ZvCk3RX4/Uc5NPTRmZUnuWSy480wER9uA1c5U/Yq1nasApf95/jv KF2A== X-Gm-Message-State: ALoCoQknnVCLZH0rrqvhH97HdA0N7IndAVFw1urMFrhofENSCLV+IFPFUxR0XfEJnr0UeNl9imZ3 X-Received: by 10.112.188.227 with SMTP id gd3mr11687414lbc.22.1424732154203; Mon, 23 Feb 2015 14:55:54 -0800 (PST) Received: from morgan.rasmusvillemoes.dk (ip-21-165.bnaa.dk. [84.238.21.165]) by mx.google.com with ESMTPSA id a2sm7453699lbm.21.2015.02.23.14.55.52 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Feb 2015 14:55:53 -0800 (PST) From: Rasmus Villemoes To: Andy Shevchenko Cc: Andrew Morton , Trond Myklebust , "J. Bruce Fields" , "David S. Miller" , linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v3 3/3] lib/string_helpers.c: Change semantics of string_escape_mem Organization: D03 References: <1422525801-26560-1-git-send-email-linux@rasmusvillemoes.dk> <1423525491-12613-1-git-send-email-linux@rasmusvillemoes.dk> <1423525491-12613-4-git-send-email-linux@rasmusvillemoes.dk> <1423571552.31903.468.camel@linux.intel.com> <87386dj4x0.fsf@rasmusvillemoes.dk> <1423578150.31903.480.camel@linux.intel.com> <87oaoo59n2.fsf@rasmusvillemoes.dk> <1424695820.14897.10.camel@linux.intel.com> X-Hashcash: 1:20:150223:linux-nfs@vger.kernel.org::6b02cOREquvTXp37:0000000000000000000000000000000000000TAh X-Hashcash: 1:20:150223:linux-kernel@vger.kernel.org::9DAPL/GW/+xwyo9i:0000000000000000000000000000000000g32 X-Hashcash: 1:20:150223:akpm@linux-foundation.org::kEWNB3hZOd2Ceblg:0000000000000000000000000000000000002o9m X-Hashcash: 1:20:150223:netdev@vger.kernel.org::wwt1shhbbd63zuDk:0000000000000000000000000000000000000002afm X-Hashcash: 1:20:150223:trond.myklebust@primarydata.com::mc/0e16Bm4ZBrOXa:00000000000000000000000000000046+l X-Hashcash: 1:20:150223:andriy.shevchenko@linux.intel.com::F+yOQ01mNv12F+au:00000000000000000000000000005H3i X-Hashcash: 1:20:150223:bfields@fieldses.org::3qo+D94hhfXdQ27D:000000000000000000000000000000000000000006kYg X-Hashcash: 1:20:150223:davem@davemloft.net::Obs/3DIDAHv5xmv9:000000000000000000000000000000000000000000Dfa7 Date: Mon, 23 Feb 2015 23:55:51 +0100 In-Reply-To: <1424695820.14897.10.camel@linux.intel.com> (Andy Shevchenko's message of "Mon, 23 Feb 2015 14:50:20 +0200") Message-ID: <87k2z86xvs.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Feb 23 2015, Andy Shevchenko wrote: >> >> > So, why couldn't we split this to separate test case? It seems I already >> >> > pointed this out. >> >> > >> >> >> >> This actually provides better coverage >> > >> > I do not see much advantage of doing so. You may create a loop with >> > random number for in-size and check. So, I prefer to see separate case >> > for that. >> >> It's not about the size, it's about exercising all the various escape_* >> helpers, to ensure that they all respect the end of the buffer, while >> still returning the correct would-be output size. For that, one needs to >> call string_escape_mem with various combinations of flags and input >> buffers. The logic for that is already in place in test_string_escape >> and its caller, and I see no point in duplicating all that. > > Thanks for clarification. > >> If you insist on a separate function for doing the overflow testing, >> I'll just rip it out from my code and let you add such a test later. > > What about to make it a separate function *and* call from inside of > test_string_escape? Would it work for you? See my earlier point about "quite a lot of state to pass". But if this static __init void test_string_escape_overflow(const char *in, int p, char *out_real, int out_size, unsigned int flags, const char *esc, int q_test, const char *name) { int q_real; memset(out_real, 'Z', out_size); q_real = string_escape_mem(in, p, out_real, 0, flags, esc); if (q_real != q_test) pr_warn("Test '%s' failed: flags = %u, osz = 0, expected %d, got %d\n", name, flags, q_test, q_real); if (memchr_inv(out_real, 'Z', out_size)) pr_warn("Test '%s' failed: osz = 0 but string_escape_mem wrote to the buffer\n", name); } is what you want, sure, have it your way. I need to fix fs/proc/array.c in 3/3 as well, to make the kernel compile+boot and make the series bisectable. Before I send v4 please let me know what you think about this (the minimal fix I could come up with): [Longer-term I think it would be a lot better not to poke around in the internals of struct seq_file. One way is to do the escaping into a stack buffer (2*sizeof(p->comm) should be enough) and then use something like seq_write(m, buffer, min(sizeof(buffer), return-value-from-string_escape_str)). Another option is to do everything with a single seq_printf call, something like seq_printf(m, "Name:\t%*pEcs\n, (int)strlen(tcomm), tcomm) That will escape more than just \ and \n, but that would IMO be an improvement. But of course this is out of scope for this series.] Rasmus --- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/proc/array.c b/fs/proc/array.c index 1295a00ca316..20f2d50e2dba 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -99,10 +99,9 @@ static inline void task_name(struct seq_file *m, struct task_struct *p) buf = m->buf + m->count; /* Ignore error for now */ - string_escape_str(tcomm, &buf, m->size - m->count, - ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\"); + m->count += string_escape_str(tcomm, buf, m->size - m->count, + ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\"); - m->count = buf - m->buf; seq_putc(m, '\n'); }