Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1419782ybl; Wed, 14 Aug 2019 16:59:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqypfz9frKVaJd7sN92CPPgS2mKZq8ktseeIAkqNWmd/aIRy8/OQ7VpFdyNLkYm7DJYNqZTu X-Received: by 2002:aa7:9217:: with SMTP id 23mr2605872pfo.239.1565827190853; Wed, 14 Aug 2019 16:59:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565827190; cv=none; d=google.com; s=arc-20160816; b=azIdDUsnjJ71JVS0DcyuRQD88AICwgOVFnZOi18RoWwS6kCBjIqHgRsRjfhKm/Zczu HRRzN8ZYdps+HSTOx6HmzWrxaj8s6aSjFtyBmeAnVMu44kF3Lbg3+0ta3aYLw7eZGWcF Ew9ymYhcgx99i2fbG9b/wWIprfBaOF/8sbJXLBj7PHiHok++cmwqyYJssXTif9oodEAD y2WPj9qFBcnE7R1o5HXCXe6NGO4GSKsN+z/pV3hvCWMcPn0z+BhoTzWu3SWD3Ds7NDhv lOEPDtUkA7Cb7CXu7IHO9e+rXgVquGlFkn5HfwSn+MpJvx3g3LE9JDoCxZ45ZPWYsjyX cnHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=e+e/OQAXN7GkasI6yC/EXJqM8IXP7fwTmNiXqJvaCJE=; b=hPeqxSRP+UNH3zrWnF+QIukW2Q1ejDoFfmUoQfCB+60uLdoryV6PklaNuwOTNhbeHN qT4YdcHGDg07M/xdDMtT8fnd3BjJUKaqmRNDAcBjl/tMnW58dfD14n2LwxTfXBQUemyk PwpYx5Jj2kPQ8TATHkSK9kuPq08K9cVg84rM3LlXOQj13QfdxA0lqMquS5ea2GHoIbmT E2YUeBJ18CB3CM4lbdPOQdEhspHJELzZZtQ4gPG5aV0jw+0qlfBmvDW6chuDB/9bySc2 /6y540xmqY9vie58N0+a5OcnGj/eKyRBjZMg6Vj710+7q/8iOPD6bVb8T5y9eUhvsOnU AfCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=JVminWy3; 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=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e23si721732pgv.528.2019.08.14.16.59.34; Wed, 14 Aug 2019 16:59:50 -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=@nvidia.com header.s=n1 header.b=JVminWy3; 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=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729600AbfHNXfA (ORCPT + 99 others); Wed, 14 Aug 2019 19:35:00 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:16343 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728370AbfHNXfA (ORCPT ); Wed, 14 Aug 2019 19:35:00 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 14 Aug 2019 16:35:01 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Wed, 14 Aug 2019 16:34:59 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Wed, 14 Aug 2019 16:34:59 -0700 Received: from rcampbell-dev.nvidia.com (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 14 Aug 2019 23:34:58 +0000 Subject: Re: [PATCH 1/5] mm: Check if mmu notifier callbacks are allowed to fail To: Andrew Morton , Daniel Vetter CC: LKML , , DRI Development , Intel Graphics Development , Michal Hocko , =?UTF-8?Q?Christian_K=c3=b6nig?= , David Rientjes , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Paolo Bonzini , Jason Gunthorpe , Daniel Vetter References: <20190814202027.18735-1-daniel.vetter@ffwll.ch> <20190814202027.18735-2-daniel.vetter@ffwll.ch> <20190814151447.e9ab74f4c7ed4297e39321d1@linux-foundation.org> X-Nvconfidentiality: public From: Ralph Campbell Message-ID: Date: Wed, 14 Aug 2019 16:34:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190814151447.e9ab74f4c7ed4297e39321d1@linux-foundation.org> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1565825701; bh=e+e/OQAXN7GkasI6yC/EXJqM8IXP7fwTmNiXqJvaCJE=; h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=JVminWy3F1xcDKxguw/IFHSOu8yhmVpbFza3GaG0mcfwG4ZfLiV+j+Y1GInVll+lG zOHBACB2xataDHAY+fhoLTpXwvhpiAh8BOZRzHl8PQNjmb9XVXAJ6UhqcfmUWMkc1H s74P3+VufRz//nqshg6mlRajAdOp+1vAhWQ3HkNiMU08Pq4yh431tX72STl+3t5R08 2P0QHNrM//MIYUOmV/X/lEbCQgf8fXWN/WgAQy4ub4cbO3X3SQd3OPEX37pSR74BaI 4AAwMUxOrZgCYLjOGKv8LKXCsKj6qQpYdOhjKvEkLAoCFplAqwo5b1MAIqg/BjouNM h3xNFgkHpm/EA== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/14/19 3:14 PM, Andrew Morton wrote: > On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote: > >> Just a bit of paranoia, since if we start pushing this deep into >> callchains it's hard to spot all places where an mmu notifier >> implementation might fail when it's not allowed to. >> >> Inspired by some confusion we had discussing i915 mmu notifiers and >> whether we could use the newly-introduced return value to handle some >> corner cases. Until we realized that these are only for when a task >> has been killed by the oom reaper. >> >> An alternative approach would be to split the callback into two >> versions, one with the int return value, and the other with void >> return value like in older kernels. But that's a lot more churn for >> fairly little gain I think. >> >> Summary from the m-l discussion on why we want something at warning >> level: This allows automated tooling in CI to catch bugs without >> humans having to look at everything. If we just upgrade the existing >> pr_info to a pr_warn, then we'll have false positives. And as-is, no >> one will ever spot the problem since it's lost in the massive amounts >> of overall dmesg noise. >> >> ... >> >> --- a/mm/mmu_notifier.c >> +++ b/mm/mmu_notifier.c >> @@ -179,6 +179,8 @@ int __mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range) >> pr_info("%pS callback failed with %d in %sblockable context.\n", >> mn->ops->invalidate_range_start, _ret, >> !mmu_notifier_range_blockable(range) ? "non-" : ""); >> + WARN_ON(mmu_notifier_range_blockable(range) || >> + ret != -EAGAIN); >> ret = _ret; >> } >> } > > A problem with WARN_ON(a || b) is that if it triggers, we don't know > whether it was because of a or because of b. Or both. So I'd suggest > > WARN_ON(a); > WARN_ON(b); > This won't quite work. It is OK to have mmu_notifier_range_blockable(range) be true or false. sync_cpu_device_pagetables() shouldn't return -EAGAIN unless blockable is true.