Received: by 10.213.65.68 with SMTP id h4csp1238629imn; Wed, 4 Apr 2018 15:23:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+GnpLtU6wEOwzRCRiBvarrbVM+N6ghSnD7T5rVfdytuBVYHI8k+XQcqs+A9lcJRWeEdw+v X-Received: by 2002:a17:902:5a3:: with SMTP id f32-v6mr6618187plf.287.1522880606441; Wed, 04 Apr 2018 15:23:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522880606; cv=none; d=google.com; s=arc-20160816; b=XyO6js3P/Ec9SMjP/NwDDm1DQ+mE2+eQPVwE4bUzQdlX6O7YWVGs0qTPhGvtDLvCBl t59tAkbePQLqZbj/Akzxb8PJ2W8cOdcoau8Hyeam6c9HVIMCUKr5FmMwJrEkQW74CcbL dmiGG3LN3mMsq34ZevUhhVhFb6gn7nkpZhHTEhImIcisvSlCvESqZMlmE4iylPZPzVD9 L0lcOX+qUU32QBZTyVXURJdQI5m7X4jEOk+l6cIvChkQPENHc8M+swRQyhYV1vM/qfVy 2WskVND7DOXbHZmWjON1qfNqM8AzX1pDtRu9L+pglTW3SAuiwimwzGGW1GXjW50vwAZF y3NQ== 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 :arc-authentication-results; bh=aGIWht1kQ+Cq66J7jmCJZLGEtEiqVLY1anVMyHjG/js=; b=Zs0MUCLOtuUhINcy3BJKZhHe3bV0p2e+qQuocZFK5th8E2TEYI10YUtejjSH+e+8E+ occZYTspwnW4QwebjtEmQiHlVv1OuhwNQo1N7keKiv2dDv5TLrpYg0rvPxiTlHabHbYw qXGDchtbdCihWyZYE0Fv5cxmeRRXPgV1J/onTvpTcaISgLzywnIUQwMrs7AIWfZ+eGb7 xfJxqmjpDW264pNdazc/1OMlLM/XUKsPhlXJn3karYXDDzo9k3cLa+wlr8daohFuktbi Qi89fms4L66Lf1hHsPPfc3SCQkyuc5/bhdHEPdfntuMhaVfr08vi04rQUnDTTqorDXJP QbbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ExD2uk6Z; 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 b13si2991592pfi.53.2018.04.04.15.23.12; Wed, 04 Apr 2018 15:23:26 -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=ExD2uk6Z; 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 S1752487AbeDDWVT (ORCPT + 99 others); Wed, 4 Apr 2018 18:21:19 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:44645 "EHLO mail-vk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751749AbeDDWVS (ORCPT ); Wed, 4 Apr 2018 18:21:18 -0400 Received: by mail-vk0-f43.google.com with SMTP id r184so13331235vke.11 for ; Wed, 04 Apr 2018 15:21:18 -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=aGIWht1kQ+Cq66J7jmCJZLGEtEiqVLY1anVMyHjG/js=; b=ExD2uk6ZQ8FjTivyR8+FBFJupy1ikjJ+NlUgGwnK1fNG9BQ3Wg+wwubXUTpn7F5lgD 5PS+nxTRa5TrsRf19ppIUpuK+yUEAWQ1dRZKuyU5TiNYUcTssIKTr39sGpwMl8GhwRJu HDdhuW1azYXqOoHSCH3zru1k9xz1if1WfvKIvWd3/jMqHaZOc5HCft503npoy3gziIa2 VnZnIF1qcnax4lIC6N0iZNZYlZ1VlC0/l9WuQZjyWpbGdngI5wAalKkimZAtakPUlR2c PePpXbMCTbEOfDQFR8ECNHziShs2BLEHZK/8qy3Zx++Z+Rjk5ZikBidD9v6ZJzEg0sto 2ZSw== 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=aGIWht1kQ+Cq66J7jmCJZLGEtEiqVLY1anVMyHjG/js=; b=Wx3Sgyo/SRK+8LcklqDatsuYODjk1oYGfWbsYRD3Vt2zJIwMNPgzU2DAfhb60ObEx3 HRUuJHNujPSwrvM0bbjgw3ZcZgoiHB10HRKLB0F157YPQDEaLDVBNYvAJs75o3d2su5O FdPMAAJSaTjm3u/UW0GVX8p+MVDjj7WD6XRMatRrKaClXQhMfgzA1vJOD1xptXEneH9N GQZxQ8uJHylceiPyxPMLrVA4O67rst1u5KkRwHvdst8oHH36Y3PXGSfUUqmOtZAJac3W jF8GQ+EH7tJ1KsgdJu86oKMx0lA1IEoJkZCoNpgBpMZ4O+sSkpbb/su85IH/rpgU3TZR fK9A== X-Gm-Message-State: ALQs6tD4U6gdhjY9arYcTcA3goOvsLyLckk9UOBBWFucOOLvdDg6IqZX +1nb+qfMt5owE+YlAw/yST5VYEtaZB7UD5G7p/FLyw== X-Received: by 10.31.220.1 with SMTP id t1mr12040741vkg.35.1522880477073; Wed, 04 Apr 2018 15:21:17 -0700 (PDT) MIME-Version: 1.0 References: <20180402095033.nfzcrmxvpm46dhbl@gmail.com> <20180403085904.GY4082@hirez.programming.kicks-ass.net> <20180403095118.rpf7tj577dppvx7d@gmail.com> <20180403180658.GE87376@google.com> <20180404093823.GC25996@kroah.com> <20180404165914.GA9034@kroah.com> In-Reply-To: From: James Y Knight Date: Wed, 04 Apr 2018 22:21:05 +0000 Message-ID: Subject: Re: [GIT PULL] x86/build changes for v4.17 To: Linus Torvalds Cc: gregkh@linuxfoundation.org, Nick Desaulniers , mka@chromium.org, Ingo Molnar , Peter Zijlstra , Linux Kernel Mailing List , tglx@linutronix.de, Andrew Morton , Chandler Carruth , Stephen Hines , Kees Cook , groeck@chromium.org, Greg Hackmann 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 Wed, Apr 4, 2018 at 3:42 PM Linus Torvalds wrote: > So we'd definitely want that "-fno-strict-overflow" to affect pointer > arithmetic too (or have a separate flag for the pointer equivalent of > "we play games that may temporarily wrap pointer values around".. The -fno-strict-overflow flag in clang does do that. You can subtract any two random pointers you have, whether they're in the same object or not, even if the math overflows. And you can later add things back together, and end up back where you started, and load the value. No problem, even though subtracting pointers from unrelated objects is illegal according to C. That's why container_of as it's written in the kernel does work in clang -- wrapping arithmetic when given a NULL pointer and everything. (as a sidenote...it would be a readability improvement to make container_of do its math with a uintptr_t instead of a void*, since it would be more *obviously* correct...) But allowing random pointer arithmetic, and pointer arithmetic wraparound, is still different than asserting that an object _field access_ can overflow. Clang does not believe that can happen -- it assumes that an object will still be contiguous. And that's why the llist stuff used to be broken, before it was corrected to do simply do math on a uintptr_t (which is a nice and simple and sane fix!).