Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp1040494img; Thu, 28 Feb 2019 12:01:11 -0800 (PST) X-Google-Smtp-Source: AHgI3IbezNiwWbNg00O8GvkYDupbZHaEaQ9tFM19Kr4J2h0GZdC/DrN4LQKnas7/yAhFX8b38w2h X-Received: by 2002:a62:1a8c:: with SMTP id a134mr1412730pfa.182.1551384070959; Thu, 28 Feb 2019 12:01:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551384070; cv=none; d=google.com; s=arc-20160816; b=JTiLa9s7qlUEXGu3WCptIG6bRKSWLbdNbJeeCaCskIuS+cm4tIP4YJoMaK3HEinips Ie+bM0iXs7VLsZPWMJ6j2fX0WvoeQpba1ZldsODbFuexDQRME1vfbljA45S9l9DMj3Lu IHVCdPbgcBU4UbRBunB5bc+mqwJN/DwAp7HE4CNP2AMQwlkEgli7HJ4HNs4pk6ASKfty VdI0fX288R9byd5Oy+ZxOt8oEdsIW65uqnS4t8kJDvqgA6wQPFQ5ESaL2MX6cy+VeO+l 3PS98BCWnjEemEUwuIdXCrSryqnNXlIM3sZ5HHhW11dMjmaQy5vdmwaJXqCOT1uQ0nAo jlkA== 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=3piHqZNEcy9SKWLEwBV/mKkW8cAFlGizlOArQiazQDo=; b=T5wOxEJG/xrZUKpNaRaybWnw9Fmm/p0COgs0YVODBB8MTTZUdTEIzGWFkO0uiNdYWG hQGPPO9K0q53ItgJ914GrnEhNKIC/CefpGGgWvi++xJ3BDwB/nffy0iXiEty/UcR1JwR E0SiQ4DaN1lM0J6MlGW8SPGexbnPEnncL+BqSWEjMNB4TQwFhCrdt1W71mlj/xGibeO7 LGtIz/d9pzk842A5laYBvYr4EaVOhcrTwE6C3h+NbiZcZn1555G6L5b3m+fRtQFyTArF cUfkaV2GImMs7910pp31/Pb/5fIk/7sAhztXUhOCG5MgbLb+V1NQ3LhyqsbA7ibCCd5c Q+jg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=KIW7QzHN; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r35si18429962pgl.379.2019.02.28.12.00.53; Thu, 28 Feb 2019 12:01:10 -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=@linux-foundation.org header.s=google header.b=KIW7QzHN; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733177AbfB1QuS (ORCPT + 99 others); Thu, 28 Feb 2019 11:50:18 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:35688 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727861AbfB1QuS (ORCPT ); Thu, 28 Feb 2019 11:50:18 -0500 Received: by mail-lf1-f68.google.com with SMTP id m73so10213284lfa.2 for ; Thu, 28 Feb 2019 08:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3piHqZNEcy9SKWLEwBV/mKkW8cAFlGizlOArQiazQDo=; b=KIW7QzHN+HY8Jbx2K5sP+q/zoQeDeSZRCuE+HK+eNScSNhobsuoZ/pD4HIc+NS3xHX tGyHcpuJYwQ4pwRDiNV8V2MVug2HPxnzTHsvBkH59+TJIlafXOIzvHyR9r2K7uQG6CYa HSTo+/U2VMHZBqebtKRCazaLovlkPjEaqVGlM= 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=3piHqZNEcy9SKWLEwBV/mKkW8cAFlGizlOArQiazQDo=; b=lfPG4zECMDujGOHDJTUCSPvJ3ViHs54WBchSZyjwqxs4rbLD1/tsTv0wTi5HBILnCO BSVVQG4bfqVPNTvH62OACJ4HeyjV0v9zXzQAEo2HtWrl4f/pDPiZS1s0Cm/kRYr50/5D HC6eLDi8hQ5T/RUOdGFU95hXNwWSO2vE6YwQ5JpXWHYWeALryrL7pD9GvJQzxamK55gx FU/4PyZajLSgJDOuLtL29iVpLbhJk1IPgO9CjUhuFKiGGFBTRjRrDPJnSYaE8ws9ZuNH BEIAU01JYKf1tpiyd7e0/r10uI46Q3MkDaElp/XfcLSImNA2q+pOKZnqUa2AVEOl8e25 A68Q== X-Gm-Message-State: APjAAAUQ0L2Kb1YM0e6bg2SGZOd/jZmN1eaal7bwMXW76r5GxJ4Btj11 u1h07os9jX/fen3a/6Df5xPO58ZrHKU= X-Received: by 2002:a19:48c3:: with SMTP id v186mr270618lfa.40.1551372615324; Thu, 28 Feb 2019 08:50:15 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id o67sm4762313lfe.40.2019.02.28.08.50.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Feb 2019 08:50:14 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id j1so15756311lfb.10 for ; Thu, 28 Feb 2019 08:50:14 -0800 (PST) X-Received: by 2002:a19:3f44:: with SMTP id m65mr248529lfa.136.1551372613604; Thu, 28 Feb 2019 08:50:13 -0800 (PST) MIME-Version: 1.0 References: <20190228145450.289603901@infradead.org> <20190228150152.540038736@infradead.org> In-Reply-To: <20190228150152.540038736@infradead.org> From: Linus Torvalds Date: Thu, 28 Feb 2019 08:49:57 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 6/8] i915,uaccess: Fix redundant CLAC To: Peter Zijlstra Cc: Thomas Gleixner , Peter Anvin , Julien Thierry , Will Deacon , Andy Lutomirski , Ingo Molnar , Catalin Marinas , James Morse , valentin.schneider@arm.com, Brian Gerst , Josh Poimboeuf , Andrew Lutomirski , Borislav Petkov , Denys Vlasenko , Linux List Kernel Mailing , Chris Wilson 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 Thu, Feb 28, 2019 at 7:05 AM Peter Zijlstra wrote: > > drivers/gpu/drm/i915/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x3c: redundant UACCESS disable > drivers/gpu/drm/i915/i915_gem_execbuffer.o: warning: objtool: .altinstr_replacement+0x66: redundant UACCESS disable > > AKA. you don't need user_access_end() if user_access_begin() fails. NOOO! This is complete garbage, and will end up running with AC set forever after. PeterZ, you need to remove that "redundant UACCESS disable" check, or make it a whole lot smarter. Because as it is, it's horribly horribly wrong. We absolutely _have_ to have that "user_access_end()" there. Yes, it is redundant (but harmlessly so) if no fault occurs. But if a fault occurs, that "user_access_end()" is what clears AC on the faulting path. That's absolutely required, because we don't clear it on return from exception (and we shouldn't - one common pattern for user space exceptions is "try to do a big access, if that fails go back to using small accesses until it fails again"). Your reachability clearly doesn't take exception handling into account. That patch must die, and your incorrect reachability model must be fixed. Right now the objtool rules seem to be worse than not using objtool, if it causes these kinds of false positives. Linus