Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1669948ybl; Tue, 3 Dec 2019 10:46:37 -0800 (PST) X-Google-Smtp-Source: APXvYqzDYrVcXhVijbChZlf7Qc8kM7M3B8uCP9GkOhm0D5spvksX3uWtawkVjoLCDKs0UAohJyXZ X-Received: by 2002:aca:b9d6:: with SMTP id j205mr3536348oif.77.1575398797086; Tue, 03 Dec 2019 10:46:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575398797; cv=none; d=google.com; s=arc-20160816; b=Cse45U7YeclX8mUHI3cCyucKXVov4ahxltfCr6+0+9ZOBvn1B2f3z10TVqcsxahKU+ THCw2KOaghJTCmS/coyrxy8pw82bFMqWQbP35hdakhOK/2c4UbItYaNqp4HaLBaVyCeA oYjmWNCBzjAKXZLdxlQuGHCytajlxg9z1X/bwrfUMFOywL7porKKL5Atkx7Mb1lCHOCr NvvEIrEfcdtFhWlA3YtA5yqXK75VxuX9tmX2FCIHcgiAg94OigFoJKqN0kRMN6Y2INnC cxLNZWnel0wDXYz2aDo7qRfZc6Cup1BdF28PENPbHI0NRWvT7xL6C4aXGnJNO0mC479u dGpA== 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=bG8Nt6cVodf34zynBURXT0B9txwe3S1q7fxCr2Als+4=; b=e2COBsTcGz1YJ5AAtiTOsLG64fcnoEub0EM1V1gpo7VCg1rR8n54fVeAZpIZyFt32s Dg7vGzEcAzSz0g2Zz7P5EIt31+F5ag/eB9DhlmN6GEIOVmIrMYi9jAB6Rtohp6Dh3U9A K+laWmkz7U4ljswNRGkD2R5VMnZDgef1VB3yv261EGKkTFWjMF0Bj7YycGR2X4rZy1J/ OkQBv4uQrTGmSTuc7ONAfsj13g0aI76ZnxpJzzSfWqNTDTX/HW4w57jNazA7O3rwjwRL 8MnNwwVO+gaAI4Tnz6aDVmbruRJpG6b+EUPO/ItXbSeyDo/6MU9NLuMHddcEEWxMWfz6 KvdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XNFVfbfC; 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 22si1665434otf.201.2019.12.03.10.46.23; Tue, 03 Dec 2019 10:46:37 -0800 (PST) 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=XNFVfbfC; 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 S1727010AbfLCSpe (ORCPT + 99 others); Tue, 3 Dec 2019 13:45:34 -0500 Received: from mail-pj1-f68.google.com ([209.85.216.68]:38519 "EHLO mail-pj1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726057AbfLCSpe (ORCPT ); Tue, 3 Dec 2019 13:45:34 -0500 Received: by mail-pj1-f68.google.com with SMTP id l4so1865650pjt.5 for ; Tue, 03 Dec 2019 10:45:34 -0800 (PST) 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=bG8Nt6cVodf34zynBURXT0B9txwe3S1q7fxCr2Als+4=; b=XNFVfbfC7D0GHt+6f17UiXwk5O1VQiJ9OqACo8IuzMrbOpSouHNZB4OUQfjJ34Xjc7 ijHp49f03VSRiLfBb6wCJS6WGBk0M+hgYqwBskCc0JbS8dxIy+TnmyPfKu+aTUSflR9G mHmeGQzJZZPgeOgdEIMR72fk0f199IwgQ9rlHrtEkKOVdnoiPC82tvtLNzTc7POPrOQ/ DA5TI2WvOiHU7ExYS7VixDjB/pZ2HnpjLFGnydGmakwQ/RbVUIEEcx10+D9Oq6DgUO6o ySTQVf9t6dyl83TCX+3hhU4djYIBm58Pabp+js0rioH8HgwUy5ehHAskL7fHOT/wGHnJ SeVg== 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=bG8Nt6cVodf34zynBURXT0B9txwe3S1q7fxCr2Als+4=; b=C+2JVFP7uhJnGlWxXPvds3O0batpy2Gro5mzdEhWiww2TWkFidGlZjh/VE/FPNaA1I By9S0EDd3xUMOAs0kSv/7AWD/NLoWwkGhllIqI5Jm7GOChH4H5LjtLcuEPHlQoRAx+l+ k8lwhYve0pFyrasS8PsajIOiMbgT/CiJwjCCyEvAHSNnXVXa96K/CCtAjXnWweL8br8J VnKTUPyP9IhVUsuhBl7OMw03BE0QnjWuxpyWm2L9i5Nh1tZ3M1GmSH8wFHI/qn80accp K4J+O7XyzCAPBLqNGJapi0qr4UeYkNc0S3kw0ArMWHgHL+hshM1zPKk/xudI8rdJdair Dlog== X-Gm-Message-State: APjAAAVv+MD7CriwnM0kUH3jgSNrLsJCA9DxiEP514moBQK4DdCVr8A+ Vg4OW7oVGe9rlY7t24j7m/9yi1x3zJXHD5OaNN8BC6F5JMA= X-Received: by 2002:a17:902:8ec8:: with SMTP id x8mr6052422plo.119.1575398733219; Tue, 03 Dec 2019 10:45:33 -0800 (PST) MIME-Version: 1.0 References: <20191123195321.41305-1-natechancellor@gmail.com> <157453950786.2524.16955749910067219709@skylake-alporthouse-com> <157538056769.7230.15356495786856166580@skylake-alporthouse-com> In-Reply-To: <157538056769.7230.15356495786856166580@skylake-alporthouse-com> From: Nick Desaulniers Date: Tue, 3 Dec 2019 10:45:22 -0800 Message-ID: Subject: Re: [PATCH] drm/i915: Remove tautological compare in eb_relocate_vma To: Chris Wilson Cc: Jani Nikula , Joonas Lahtinen , Nathan Chancellor , Rodrigo Vivi , intel-gfx@lists.freedesktop.org, dri-devel , LKML , clang-built-linux , Kees Cook 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, Dec 3, 2019 at 5:42 AM Chris Wilson wrote: > > Quoting Nick Desaulniers (2019-12-02 19:18:20) > > On Sat, Nov 23, 2019 at 12:05 PM Chris Wilson wrote: > > > > > > Quoting Nathan Chancellor (2019-11-23 19:53:22) > > > > -Wtautological-compare was recently added to -Wall in LLVM, which > > > > exposed an if statement in i915 that is always false: > > > > > > > > ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1485:22: warning: > > > > result of comparison of constant 576460752303423487 with expression of > > > > type 'unsigned int' is always false > > > > [-Wtautological-constant-out-of-range-compare] > > > > if (unlikely(remain > N_RELOC(ULONG_MAX))) > > > > ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ > > > > > > > > Since remain is an unsigned int, it can never be larger than UINT_MAX, > > > > which is less than ULONG_MAX / sizeof(struct drm_i915_gem_relocation_entry). > > > > Remove this statement to fix the warning. > > > > > > The check should remain as we do want to document the overflow > > > calculation, and it should represent the types used -- it's much easier > > > > What do you mean "represent the types used?" Are you concerned that > > the type of drm_i915_gem_exec_object2->relocation_count might change > > in the future? > > We may want to change the restriction, yes. > > > > to review a stub than trying to find a missing overflow check. If the > > > overflow cannot happen as the types are wide enough, no problem, the > > > compiler can remove the known false branch. > > > > What overflow are you trying to protect against here? > > These values are under user control, our validation steps should be > clear and easy to check. If we have the types wrong, if the checks are > wrong, we need to fix them. If the code is removed because it can be > evaluated by the compiler to be redundant, it is much harder for us to > verify that we have tried to validate user input. > > > > Tautology here has a purpose for conveying information to the reader. > > > > Well leaving a warning unaddressed is also not a solution. Either > > replace it with a comment or turn off the warning for your subdir. > > My personal preference would be to use a bunch of central macros for the > various type/kmalloc overflows, and have the warnings suppressed there > since they are very much about documenting user input validation. > -Chris Is kmalloc_array what you're looking for? Looks like it has the `check_mul_overflow` call in it. -- Thanks, ~Nick Desaulniers