From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1FDAC433DB for ; Thu, 11 Mar 2021 23:28:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 080EA64F72 for ; Thu, 11 Mar 2021 23:28:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 080EA64F72 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 531978D030C; Thu, 11 Mar 2021 18:28:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E1208D02B2; Thu, 11 Mar 2021 18:28:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 111388D030C; Thu, 11 Mar 2021 18:28:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id E2F698D02B2 for ; Thu, 11 Mar 2021 18:28:49 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9FA408249980 for ; Thu, 11 Mar 2021 23:28:49 +0000 (UTC) X-FDA: 77909185578.15.B6F9103 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf03.hostedemail.com (Postfix) with ESMTP id AF274C0007C2 for ; Thu, 11 Mar 2021 23:28:46 +0000 (UTC) Received: by mail-qv1-f52.google.com with SMTP id i15so3425517qvr.0 for ; Thu, 11 Mar 2021 15:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=ZsSTpigG2EoWvSWDLvggAQ39g5J0AwVfYh+qxTHZ8LU=; b=IWOEEnWQoNSOrS2PqbGH9PEDsz/QWKgm5I7jMWtbuGawERSQrp1bg6FD4+Y2OIwXWv lhFlSM6FGcFFbGyYFuwHQKjIhB4pVNZIP59Yb6NotJT8Wfnh5Aj5AXw3QHD7LFIVeuC8 D+4y67T5V2yyzsFyj7VqJyyjXjgx/YciTHlTrUQ9ek4mGeyVWUlF1reMf/kd7HcxEjrc IozCtDPPSYApjRSHjtSm3M6GWYJ6a3gpmx40MRAuKqzXC2f+AMdl0cEmzX/RDDdPx0Rr 6oXxr+/go8dW7Dx9lM6AjEGVlwxZlb1dadji1aWpUORogDpU+4gwp8w5hiRo9SVKh7Sk 2s7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=ZsSTpigG2EoWvSWDLvggAQ39g5J0AwVfYh+qxTHZ8LU=; b=cZY3fBTv6vnU4jzP5ECH9hZqFuQlRvtTNBeJdgZjdKWNjAoDdW/xY9n0WkF52CMCFu jB9Hs+fmWhZo1o1J8Ma5dbL4c7tiVaXn6VJDIkyUVLwyHquR+wB8t/wredG56AnGOOBV HbKloamuIK+UWltuu75qpDddubcra5AcosYkcgtCb0dCWxSKHyTY3wQ0a7JrHYWF+xIp 2YzAn1CMlg8ro33kXEDDRK2WrhIZ8HKt3UI+hdcEcHmeFF/aCOWTOzdGKSLdqnyNZ3tn iEb5j7fhlz0AyWB2nXcT3KTVNpR/S8a0K76gWWcrOISAdOjoDycLgVCOEGipph6EA/3e n9QQ== X-Gm-Message-State: AOAM532plKtP7sJtoox/0wYUHcfntDrVc1bbBHyy6yGAiUdcLODXWiN0 miUvdDM917xP6Ek+Z2p0aDnEPA== X-Google-Smtp-Source: ABdhPJzBjsjG7Pl5Zhuv6V4OecqUGWpRQDn0c//JMhL+sHbYjjgsaUY8upg9kadvBAaVvK5/NwWRmQ== X-Received: by 2002:a05:6214:c8a:: with SMTP id r10mr10077768qvr.13.1615505328343; Thu, 11 Mar 2021 15:28:48 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id n136sm3118483qke.123.2021.03.11.15.28.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 15:28:47 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1lKUjX-00BZaI-6h; Thu, 11 Mar 2021 19:28:47 -0400 Date: Thu, 11 Mar 2021 19:28:47 -0400 From: Jason Gunthorpe To: Sean Christopherson Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Rientjes , Ben Gardon , Michal Hocko , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Andrea Arcangeli , Johannes Weiner , Dimitri Sivanich Subject: Re: [PATCH v2] mm/mmu_notifiers: Esnure range_end() is paired with range_start() Message-ID: <20210311232847.GA2710221@ziepe.ca> References: <20210311180057.1582638-1-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210311180057.1582638-1-seanjc@google.com> X-Stat-Signature: 13m9q7b4dg11gqwh891jmzdeb6izgckm X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AF274C0007C2 Received-SPF: none (ziepe.ca>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail-qv1-f52.google.com; client-ip=209.85.219.52 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615505326-174643 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Mar 11, 2021 at 10:00:57AM -0800, Sean Christopherson wrote: > If one or more notifiers fails .invalidate_range_start(), invoke > .invalidate_range_end() for "all" notifiers. If there are multiple > notifiers, those that did not fail are expecting _start() and _end() to > be paired, e.g. KVM's mmu_notifier_count would become imbalanced. > Disallow notifiers that can fail _start() from implementing _end() so > that it's unnecessary to either track which notifiers rejected _start()= , > or had already succeeded prior to a failed _start(). >=20 > Note, the existing behavior of calling _start() on all notifiers even > after a previous notifier failed _start() was an unintented "feature". > Make it canon now that the behavior is depended on for correctness. >=20 > As of today, the bug is likely benign: >=20 > 1. The only caller of the non-blocking notifier is OOM kill. > 2. The only notifiers that can fail _start() are the i915 and Nouveau > drivers. > 3. The only notifiers that utilize _end() are the SGI UV GRU driver > and KVM. > 4. The GRU driver will never coincide with the i195/Nouveau drivers. > 5. An imbalanced kvm->mmu_notifier_count only causes soft lockup in t= he > _guest_, and the guest is already doomed due to being an OOM victi= m. >=20 > Fix the bug now to play nice with future usage, e.g. KVM has a potentia= l > use case for blocking memslot updates in KVM while an invalidation is > in-progress, and failure to unblock would result in said updates being > blocked indefinitely and hanging. >=20 > Found by inspection. Verified by adding a second notifier in KVM that > periodically returns -EAGAIN on non-blockable ranges, triggering OOM, > and observing that KVM exits with an elevated notifier count. >=20 > Fixes: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notif= iers") > Suggested-by: Jason Gunthorpe > Cc: stable@vger.kernel.org > Cc: David Rientjes > Cc: Ben Gardon > Cc: Michal Hocko > Cc: "J=C3=A9r=C3=B4me Glisse" > Cc: Andrea Arcangeli > Cc: Johannes Weiner > Cc: Dimitri Sivanich > Signed-off-by: Sean Christopherson >=20 > v2: Reimplemented as suggested by Jason. Only functional change relati= ve > to Jason's suggestion is to check invalidate_range_end before calli= ng to > avoid a NULL pointer dereference. I also added more comments, hope= fully > they're helpful... >=20 > v1: https://lkml.kernel.org/r/20210310213117.1444147-1-seanjc@google.co= m Looks fine, thanks. I think you need some commit message remark to discourage backporting, the added WARN_ON will trigger on older kernels that have many more things implementing invalidate_range_end(). It should not be backported to anything that has more invalidate_range_ends()'s than today's kernel. Reviewed-by: Jason Gunthorpe Jason