Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3041830ybh; Mon, 16 Mar 2020 14:42:26 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsEvYB5yg6Fo7MrC5sAxFpTb5mYT+3YkIdrhaXGXChc0BDiLdFkxCq9LcVl66gjs0tcd8DT X-Received: by 2002:aca:ad93:: with SMTP id w141mr1258170oie.54.1584394945800; Mon, 16 Mar 2020 14:42:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584394945; cv=none; d=google.com; s=arc-20160816; b=FC0Jrut9HFjck3QN1hUKsPrXMRGAwh1RW32gfBC04aDZQVg6cimN+oLBn+3aDevypM jIaTIufuXHRBvVw38Joh1PPOsjpqzKHumy9PWFyu2UkgOeqZlBwtbtHW+9r2xknkkK9W dqds2NiH/d0+l7df2bkhZsuVwFAlhRx0NyUK4rNDn1n0jQHV+KiE7T88c5kZwRwKGVr+ iyLJn/pBpuoeJSXaIp1nN8GQD5neHYqnHazsrqrhcPLJiDfCKwj80ass0JdUZw7vqYTn dEU7yvVOHU+PclL9EQ3g1LBDWelsFl12NwHQSIthITDtIAjur0DpGOFaVexUKrDfthZv Ti7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=9wf0Koz5Hqawzf6JsmYQiKszzPagSKBiZUUlt5oOYqk=; b=SdpC6qe36BJoDfHP0sJk86R4jdn0IUrqPo25B7H6/JYUhHGldYCd6goFec+gnSBD++ rUHapvnSkXFxVFBjLardDaNdywTMeAgDHBt5R9oVGJ5FYHIY0/0x22gRPeiaZnAP/eZI 0jmu/rFebQvhjXZjoXQR8djEcRjxpv+rrClDH8F2v8XB3sSBooIfKSoJdbaKT2MBLyfs 3LgRVWjquJU4x+UPtjFyxZ8G/M8WQAoN1zSLR9nw9dFvz275/dSlOq9Lt5C/zG7XJqaR kNITYF4d8bUJJV/Hdu9jSu1EHETfRq/MlLy9oGZVyhTlek4mR7Eo0+nSHiFYHN4kIL7c 7ivw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bygEw+ut; 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 e11si610198oib.152.2020.03.16.14.42.12; Mon, 16 Mar 2020 14:42:25 -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=bygEw+ut; 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 S1732690AbgCPVlh (ORCPT + 99 others); Mon, 16 Mar 2020 17:41:37 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:42467 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732636AbgCPVlh (ORCPT ); Mon, 16 Mar 2020 17:41:37 -0400 Received: by mail-pl1-f196.google.com with SMTP id t3so8594232plz.9 for ; Mon, 16 Mar 2020 14:41:36 -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:content-transfer-encoding; bh=9wf0Koz5Hqawzf6JsmYQiKszzPagSKBiZUUlt5oOYqk=; b=bygEw+utdMG3J5vWZUoZSaS7LmV6Z5HdtyZV/VdNtbOd9xdi8xc0AugHxl6FD6zUyE DYho48lurJEKOQsrXUCvVHgqwG5nzSQ9hCveGYqzxMmXyXHZZj4TSZj7imlQc1nxdiHm AetbRzqEN6m4JOEDas4VlK2MDkOXsuAz8ba+zYfeZwrZ08d7nqfZUL7MWZDs3SuIb6Fg hDEBTGIAwM7cIXBIUMAgMZeQtZQgPsr1VNX0Zbnn0UONxvqrcD7hzeT7XNNc1nrkrD6L XWgo9QJuNS7GdyhnuwxaexJq3QG/5dIbA2yuW1NwoXOE95YUbvsI1GJ3JTlDNV/gN9oV 203Q== 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:content-transfer-encoding; bh=9wf0Koz5Hqawzf6JsmYQiKszzPagSKBiZUUlt5oOYqk=; b=kUy3khUzDsc9x1e/i1XiL7y/z6n3Op9DPhvDLN5L3Vfun+ghVjmaJF9b20fEaxwxYK 80E4HwPJJ2UOYKZQP8rV65pHqQsd7G2ryKCG/lmSC0suHcrdPDCDlerfwZd/VN69f0Rm 2LsGY5Fd7J17qX8D9jnooZ7RJe0wjEWoT1jH+eXP5jGWh6zzvmp/8Pv5dxWlMkwNHo2O 8/a3ulACbTGEubsSO3i1mxRD7k9fEkOa1ibzub1PRWGsvpFV60xqDQCdRETqTnpurONL pfMOKYhYpe7fxVrJuFoaySJ6vqTwU6BiwG30qJi1aoaSkfiS89l4AksZS+BRcnD17SNE L1Nw== X-Gm-Message-State: ANhLgQ2vluv133GJDpPrGSaxIr5PlD2jj1cNoNqExfm7YHuzkC/o1ety flFOSQkaXnw3fMh02BpfF+0KoZDzQmxta1oDO9+WZQ== X-Received: by 2002:a17:902:8a88:: with SMTP id p8mr1121105plo.179.1584394895359; Mon, 16 Mar 2020 14:41:35 -0700 (PDT) MIME-Version: 1.0 References: <20200214054706.33870-1-natechancellor@gmail.com> <87v9o965gg.fsf@intel.com> <158166913989.4660.10674824117292988120@skylake-alporthouse-com> <87o8u1wfqs.fsf@intel.com> In-Reply-To: From: Nick Desaulniers Date: Mon, 16 Mar 2020 14:41:23 -0700 Message-ID: Subject: Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma To: =?UTF-8?Q?Michel_D=C3=A4nzer?= , Chris Wilson , Nathan Chancellor , Jani Nikula Cc: Joonas Lahtinen , Rodrigo Vivi , intel-gfx@lists.freedesktop.org, LKML , dri-devel , clang-built-linux Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 14, 2020 at 7:36 AM Michel D=C3=A4nzer wro= te: > > On 2020-02-14 12:49 p.m., Jani Nikula wrote: > > On Fri, 14 Feb 2020, Chris Wilson wrote: > >> Quoting Jani Nikula (2020-02-14 06:36:15) > >>> On Thu, 13 Feb 2020, Nathan Chancellor wro= te: > >>>> A recent commit in clang added -Wtautological-compare to -Wall, whic= h is > >>>> enabled for i915 after -Wtautological-compare is disabled for the re= st > >>>> of the kernel so we see the following warning on x86_64: > >>>> > >>>> ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433: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))) > >>>> ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ > >>>> ../include/linux/compiler.h:78:42: note: expanded from macro 'unlik= ely' > >>>> # define unlikely(x) __builtin_expect(!!(x), 0) > >>>> ^ > >>>> 1 warning generated. > >>>> > >>>> It is not wrong in the case where ULONG_MAX > UINT_MAX but it does n= ot > >>>> account for the case where this file is built for 32-bit x86, where > >>>> ULONG_MAX =3D=3D UINT_MAX and this check is still relevant. > >>>> > >>>> Cast remain to unsigned long, which keeps the generated code the sam= e > >>>> (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) a= nd > >>>> the warning is silenced so we can catch more potential issues in the > >>>> future. > >>>> > >>>> Link: https://github.com/ClangBuiltLinux/linux/issues/778 > >>>> Suggested-by: Michel D=C3=A4nzer > >>>> Signed-off-by: Nathan Chancellor > >>> > >>> Works for me as a workaround, > >> > >> But the whole point was that the compiler could see that it was > >> impossible and not emit the code. Doesn't this break that? > > > > It seems that goal and the warning are fundamentally incompatible. > > Not really: > > if (sizeof(remain) >=3D sizeof(unsigned long) && > unlikely(remain > N_RELOC(ULONG_MAX))) > return -EINVAL; > > In contrast to the cast, this doesn't generate any machine code on 64-bit= : > > https://godbolt.org/z/GmUE4S > > but still generates the same code on 32-bit: > > https://godbolt.org/z/hAoz8L Exactly. This check is only a tautology when `sizeof(long) =3D=3D sizeof(int)` (ie. ILP32 platforms, like 32b x86), notice how BOTH GCC AND Clang generate exactly the same code: https://godbolt.org/z/6ShrDM Both compilers eliminate the check when `-m32` is not set, and generate the exact same check otherwise. How about: ``` diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index d3f4f28e9468..25b9d3f3ad57 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1415,8 +1415,10 @@ static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev) urelocs =3D u64_to_user_ptr(entry->relocs_ptr); remain =3D entry->relocation_count; +#ifndef CONFIG_64BIT if (unlikely(remain > N_RELOC(ULONG_MAX))) return -EINVAL; +#endif /* * We must check that the entire relocation array is safe ``` We now have 4 proposed solutions: 1. https://lore.kernel.org/lkml/20191123195321.41305-1-natechancellor@gmail= .com/ 2. https://lore.kernel.org/lkml/20200211050808.29463-1-natechancellor@gmail= .com/ 3. https://lore.kernel.org/lkml/20200214054706.33870-1-natechancellor@gmail= .com/ 4. my diff above Let's please come to a resolution on this. --=20 Thanks, ~Nick Desaulniers