Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5040162ybi; Tue, 11 Jun 2019 17:58:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqwhmOuBbGLSMInC5yuDr9B/gyZm1FKf4Qr528HBplc8h9SKI+YKVCdQMVzcT/mZh3z8OW+f X-Received: by 2002:a62:1dd0:: with SMTP id d199mr30812570pfd.257.1560301129737; Tue, 11 Jun 2019 17:58:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560301129; cv=none; d=google.com; s=arc-20160816; b=XgJQHFzRzGp9xaXaJ0KUA34/FUAxabdtKB7FuoLixFnlgRtstdhryslphc4U9FC03+ iiXPw0gPszOCcu1nwhIUwX8sQfcah+k8v05tsYfiApObY7PA7U1m4Se/fETHvj3W3ACf oB6L+pQ23ztkX7UNDirtxQwJkZF9t9KMrysuTQoP/Nitjuta3eQsdoGcrYS6czeSulXe eZRHhVpo6Wo6QZHBFSJrlXIVst8GbYLIAiVvUxRuj0jiwPZrObBZMW9+2zR4VpSO7qKg RTb52NPcLd+mUTpBM+CgfQxwo2u2qGafBAdT3pTAzNA4OS56StxZtyMgHNRHJx44uCgF Z3uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=dhnwSrdCPnvzoEVfuuVGqE83p7TnkQ5Modn2BNCoQD0=; b=d38LxDCQ2jymYD3InNDJM276LXJT09mjejRN3E4E1j5Ur8OHAYUOEl5vuNAdrzkqMQ KYWMYHjnce37M6Me623io21s4GcxfFwdoZsJzAFtNqVMzx6xe/pRpUJQ7aNt17FzIxM2 Y9KrUbYzlvmmuhlaHmai8zZiCIl10mY8Bin7mad49xtg8tgPSyIcdVkUJR6bI2lsTs9Z miz1dmdv4Jt5AduQSnkKF0t7QaVdaS/bmRQDzD8mk1Q5nYjP7DRwFuvq9otBhzImSHYm bslIJSchXxnezmq3s9nG93bgZwEoIdpRhG5PydT3ku0LCwACGO2E0h1VRja9X/GRu5/Z esnA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Pp0Hq+hd; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x10si15786239pfj.93.2019.06.11.17.58.34; Tue, 11 Jun 2019 17:58:49 -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=@google.com header.s=20161025 header.b=Pp0Hq+hd; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406502AbfFKU3O (ORCPT + 99 others); Tue, 11 Jun 2019 16:29:14 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:40019 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405476AbfFKU3N (ORCPT ); Tue, 11 Jun 2019 16:29:13 -0400 Received: by mail-pg1-f195.google.com with SMTP id d30so7585253pgm.7 for ; Tue, 11 Jun 2019 13:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dhnwSrdCPnvzoEVfuuVGqE83p7TnkQ5Modn2BNCoQD0=; b=Pp0Hq+hd8QA6syECahlCWtYv82jhOxBm0sr+fZ9Dkk8nXtHe7nrSiSj+V8u0FaITQ7 84fXuzNXkrhzDQgkHPp26EjnsIzrDKXg48+xvOTrPv1gFdJxgRLOvcs0dwgoU2BGvzqE Liz3+gL3rcT7wqBUJosubNY4aHZAru2eeUFG6CtPZ2mbKIzTjquHFKUIQcWXvVk4hMLI 7UB1amIr3aRGarnBUHse/35CwxBlRRF3qifo7BnhaOJV61RWbVqr0wA4GIowlDaA6gfT pWINRb5VwbD/mtNfms9GrZfwha/4G8tSCCTtYnHFhjTrLaOGAdTroClIT1QeFCWuqloy NJbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dhnwSrdCPnvzoEVfuuVGqE83p7TnkQ5Modn2BNCoQD0=; b=qwixqWuwuCUKlc+b6F7S33VNUReix5G3dLpiYvX8NfnLWGTLJ2RB0TxbuUKdLOSdqy t8WNybndJ/4k6QD17Xq95PwUO8wNF5ZFK16P5PaHUeSTARAKLyaCBsTP1ZEqiPERSkQs 3O6EpBQquQaCBCP73AhJ4VzcSzRgqlR7kKnV751wOIu0980oK9Rlsw02rrtZ/I/VYB9a svykxqvKUwYwiR3XhA3GWn8wB187BKF++T57sRWjlu4mG6dZis84v+1BN+bwKD0Arwgy dFo6mzAMJy5eaJyB+WqDpSqx01CLykzaKy7t26l9CVoXR1NfOf+ex8UgOMLP7e8gjE8V gbNQ== X-Gm-Message-State: APjAAAXmHv/XuL3YV+/XuL0h62yYE5TK83viwN3dBDmfBa1X3rK1QlZX dH1X8lzAM/KL/Qu3CrmQXuyFcAaWLnlAbOE/aJRHdg== X-Received: by 2002:a17:90a:2e89:: with SMTP id r9mr28553830pjd.117.1560284952085; Tue, 11 Jun 2019 13:29:12 -0700 (PDT) MIME-Version: 1.0 References: <20190514221711.248228-1-brendanhiggins@google.com> <20190514221711.248228-18-brendanhiggins@google.com> <20190517182254.548EA20815@mail.kernel.org> <20190607190047.C3E7A20868@mail.kernel.org> <20190611175830.GA236872@google.com> <20190611185018.2E1C021744@mail.kernel.org> In-Reply-To: <20190611185018.2E1C021744@mail.kernel.org> From: Brendan Higgins Date: Tue, 11 Jun 2019 13:29:01 -0700 Message-ID: Subject: Re: [PATCH v4 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() To: Stephen Boyd Cc: Iurii Zaikin , Frank Rowand , Greg KH , Josh Poimboeuf , Kees Cook , Kieran Bingham , Luis Chamberlain , Peter Zijlstra , Rob Herring , shuah , "Theodore Ts'o" , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 11, 2019 at 11:50 AM Stephen Boyd wrote: > > Quoting Brendan Higgins (2019-06-11 10:58:30) > > On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote: > > > Quoting Iurii Zaikin (2019-06-05 18:29:42) > > > > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote: > > > > > > > > > > Quoting Brendan Higgins (2019-05-14 15:17:10) > > > > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c > > > > > > new file mode 100644 > > > > > > index 0000000000000..fe0f2bae66085 > > > > > > --- /dev/null > > > > > > +++ b/kernel/sysctl-test.c > > > > > > + > > > > > > + > > > > > > +static void sysctl_test_dointvec_happy_single_negative(struct kunit *test) > > > > > > +{ > > > > > > + struct ctl_table table = { > > > > > > + .procname = "foo", > > > > > > + .data = &test_data.int_0001, > > > > > > + .maxlen = sizeof(int), > > > > > > + .mode = 0644, > > > > > > + .proc_handler = proc_dointvec, > > > > > > + .extra1 = &i_zero, > > > > > > + .extra2 = &i_one_hundred, > > > > > > + }; > > > > > > + char input[] = "-9"; > > > > > > + size_t len = sizeof(input) - 1; > > > > > > + loff_t pos = 0; > > > > > > + > > > > > > + table.data = kunit_kzalloc(test, sizeof(int), GFP_USER); > > > > > > + KUNIT_EXPECT_EQ(test, 0, proc_dointvec(&table, 1, input, &len, &pos)); > > > > > > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, len); > > > > > > + KUNIT_EXPECT_EQ(test, sizeof(input) - 1, pos); > > > > > > + KUNIT_EXPECT_EQ(test, -9, *(int *)table.data); > > > > > > > > > > Is the casting necessary? Or can the macro do a type coercion of the > > > > > second parameter based on the first type? > > > > Data field is defined as void* so I believe casting is necessary to > > > > dereference it as a pointer to an array of ints. I don't think the > > > > macro should do any type coercion that == operator wouldn't do. > > > > I did change the cast to make it more clear that it's a pointer to an > > > > array of ints being dereferenced. > > > > > > Ok, I still wonder if we should make KUNIT_EXPECT_EQ check the types on > > > both sides and cause a build warning/error if the types aren't the same. > > > This would be similar to our min/max macros that complain about > > > mismatched types in the comparisons. Then if a test developer needs to > > > convert one type or the other they could do so with a > > > KUNIT_EXPECT_EQ_T() macro that lists the types to coerce both sides to > > > explicitly. > > > > Do you think it would be better to do a phony compare similar to how > > min/max used to work prior to 4.17, or to use the new __typecheck(...) > > macro? This might seem like a dumb question (and maybe it is), but Iurii > > and I thought the former created an error message that was a bit easier > > to understand, whereas __typecheck is obviously superior in terms of > > code reuse. > > > > This is what we are thinking right now; if you don't have any complaints > > I will squash it into the relevant commits on the next revision: > > Can you provide the difference in error messages and describe that in > the commit text? The commit message is where you "sell" the patch, so > being able to compare the tradeoff of having another macro to do type > comparisons vs. reusing the one that's there in kernel.h would be useful > to allay concerns that we're duplicating logic for better error > messages. Oh sorry, I didn't think too hard about the commit message since I figured it would get split up and squashed into the existing commits. I just wanted to get it out sooner to discuss this before I post the next revision (probably later this week). > Honestly, I'd prefer we just use the macros that we've developed in > kernel.h to do comparisons here so that we can get code reuse, but more > importantly so that we don't trip over problems that caused those macros > to be created in the first place. If the error message is bad, perhaps > that can be fixed with some sort of compiler directive to make the error > message a little more useful, i.e. compiletime_warning() thrown into > __typecheck() or something. That's a good point. I have no qualms sticking with __typecheck(...) for now; if we later feel that it is causing problems, we can always fix it later by supplying our own warning in the manner you suggest. Iurii, do you have any additional thoughts on this? > > > --- > > From: Iurii Zaikin > > > > Adds a warning message when comparing values of different types similar > > to what min() / max() macros do. > > > > Signed-off-by: Iurii Zaikin