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;
Date:   Sat, 21 Dec 2019 20:09:15 -0700
From:   Nathan Chancellor <natechancellor@gmail.com>
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Chris Wilson <chris@chris-wilson.co.uk>,
        Jani Nikula <jani.nikula@linux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@intel.com>,
        intel-gfx@lists.freedesktop.org,
        dri-devel <dri-devel@lists.freedesktop.org>,
        LKML <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] drm/i915: Remove tautological compare in eb_relocate_vma
Message-ID: <20191222030915.GA27679@ubuntu-m2-xlarge-x86>
References: <20191123195321.41305-1-natechancellor@gmail.com>
 <157453950786.2524.16955749910067219709@skylake-alporthouse-com>
 <CAKwvOdniXqn3xt3-W0Pqi-X1nWjJ2vUVofjCm1O-UPXZ7_4rXw@mail.gmail.com>
 <157538056769.7230.15356495786856166580@skylake-alporthouse-com>
 <CAKwvOd=ov789Lixdq8QE+MVXeYyh=W_sODSuj++4T8uF-hpVMw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKwvOd=ov789Lixdq8QE+MVXeYyh=W_sODSuj++4T8uF-hpVMw@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 03, 2019 at 10:45:22AM -0800, Nick Desaulniers wrote:
> On Tue, Dec 3, 2019 at 5:42 AM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Quoting Nick Desaulniers (2019-12-02 19:18:20)
> > > On Sat, Nov 23, 2019 at 12:05 PM Chris Wilson <chris@chris-wilson.co.uk> 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.

I don't think kmalloc_array is right because we are not validating an
allocation. I am not sure that any of these overflow macros are correct,
we would probably need something new but I am not sure.

Cheers,
Nathan