From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7527C10F11 for ; Wed, 10 Apr 2019 21:51:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D33420830 for ; Wed, 10 Apr 2019 21:51:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="h6iTeezr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726230AbfDJVvH (ORCPT ); Wed, 10 Apr 2019 17:51:07 -0400 Received: from mail-ua1-f67.google.com ([209.85.222.67]:41765 "EHLO mail-ua1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725982AbfDJVvH (ORCPT ); Wed, 10 Apr 2019 17:51:07 -0400 Received: by mail-ua1-f67.google.com with SMTP id l22so1317068uao.8 for ; Wed, 10 Apr 2019 14:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6NkU3OomiDM2n3PhPZjvX+q6FnTqeBC15UID7r08M78=; b=h6iTeezr//aFIhYsFLtbPW9Qnh2cTqOem9rN5DsSvxg21HWew1QajuYjYeJ5e4kxlZ LraHM7XY5Co1ognr5QI5tsC9KA+2d6egcQc4X7euanQ2D6MN+xdmOk2/cYyJRL74XX5a LxPfCEAQNd6Ez2XDXYO/45bmKth1eNniqKgLI= 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=6NkU3OomiDM2n3PhPZjvX+q6FnTqeBC15UID7r08M78=; b=W+hPqRH4qQg1Nha5MgNsmCTJvNTjLLAXUivYeUvF+NAkYfwbHcaFsH8jhJgQNhuwDi 8l11yAD2iZm6cF2itjMu74vqCYCejOWaN/OtPy+AlV2lcOy8rsvu/9/mvf3kzqHQtd5w UQiDQAh2Sguj84NhEVk9+Wz7N4O43GLWtA1T1AgZG7/Mkt+B31pMLqea+iYwAuarTQ7r J2J8HPlp0BVN2OTkhb/SBvGOYbgjcRgMXFf2Vm66d0Po3+QKLvl4pbSgfkP7d8dPRbKV EgYNtxLi/lxYVw2n1MA8zFQARIrUVfTYOJRPoWyQl+452GlrbJ5ThJ9Tsju6AOi0RIEy dB3g== X-Gm-Message-State: APjAAAXX0NwBs5lEQ5VcdYZCQ2S7FAK/dgclyDbX+u0N4RhqriBg4+Ny ILuKQuW6s+aYEhhoyfAbuGimIPpEF/A= X-Google-Smtp-Source: APXvYqwhZQTDzilZr1yDbH9ac7R6bbKh6PiS3SSteLz4jrzhWUfLcj8yS1wLUhaCBbkFUNkuT23LlQ== X-Received: by 2002:ab0:4e07:: with SMTP id g7mr25018623uah.111.1554933066053; Wed, 10 Apr 2019 14:51:06 -0700 (PDT) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com. [209.85.217.43]) by smtp.gmail.com with ESMTPSA id u10sm17454444vku.34.2019.04.10.14.51.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 14:51:05 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id o10so2265134vsp.12 for ; Wed, 10 Apr 2019 14:51:05 -0700 (PDT) X-Received: by 2002:a67:76c7:: with SMTP id r190mr26741596vsc.196.1554933064639; Wed, 10 Apr 2019 14:51:04 -0700 (PDT) MIME-Version: 1.0 References: <20190408220925.13077-1-mcroce@redhat.com> <20190408220925.13077-3-mcroce@redhat.com> In-Reply-To: From: Kees Cook Date: Wed, 10 Apr 2019 14:50:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] kernel: use sysctl shared variables for range check To: Matteo Croce , Andrew Morton Cc: LKML , "linux-fsdevel@vger.kernel.org" , Luis Chamberlain , Alexey Dobriyan Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Apr 10, 2019 at 12:24 PM Matteo Croce wrote: > > On Wed, Apr 10, 2019 at 8:46 PM Kees Cook wrote: > > > > On Mon, Apr 8, 2019 at 3:09 PM Matteo Croce wrote: > > > > > > Use the shared variables for range check, instead of declaring a local one > > > in every source file. > > > > I was expecting this to be a tree-wide change for all the cases found > > by patch 1's "git grep". > > > > Hi Kees, > > I have already the whole patch ready, but I was frightened by the > output of get_maintainer.pl, so I decided to split the patch into > small pieces and send the first one. Heh, sounds fine. Normally the big tree-wide changes go via Linus just before cutting rc1 (or rc2). This is "only" 31 source files, though, so maybe akpm wants to take these instead? Andrew, how do you feel about that? > Patches for /proc/sys/net and drivers/ are pretty big, and can be > merged after the 1/2 inclusion. > > > Slight change to the grep for higher accuracy: > > > > $ git grep -E '\.extra[12].*&(zero|one|int_max)\b' |wc -l > > 245 > > > > Right, my regexp wrongly matches also one_hundred, one_jiffy, etc. > Anywqay, I did the changes by hand, so apart the commit message, the > content should be safe. > > > Only 31 sources: > > $ git grep -E '\.extra[12].*&(zero|one|int_max)\b' | cut -d: -f1 | > > sort -u > /tmp/list.txt > > $ wc -l /tmp/list.txt > > 31 > > > > One thing I wonder about is if any of these cases depend on the extra > > variable being non-const (many of these are just "static int"). > > > > $ egrep -H '\b(zero|one|int_max)\b.*=' $(cat /tmp/list.txt) | grep -v static > > > > Looks like none, so it'd be safe. How about doing this tree-wide for > > all 31 cases? (Coccinelle might be able to help.) > > It could be true for other sysctl values like > xpc_disengage_max_timelimit or fscache_op_wq, but it's very unlikely > that someone writes, for example, 5 into a variable named "zero". If > it does, it most likely a bug, so const is our friend. I completely agree. :) I just wanted to make sure and it turned out the grep was very easy. -- Kees Cook