Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4064745ybl; Tue, 20 Aug 2019 06:32:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1wIHe6ltLvgGnneWVRJTnYwlFk3VWW29TpEKGr0f2GQgAPqFNYN/XNlYan4hSAHORRTq0 X-Received: by 2002:a63:e901:: with SMTP id i1mr24344470pgh.451.1566307951747; Tue, 20 Aug 2019 06:32:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566307951; cv=none; d=google.com; s=arc-20160816; b=xQiHp6beBxPhb2PBaew4uhCNeCK929BCJds2jmyewxkRCsSCkuzmSztvF7NiXEyuh0 C6tPWLN9gUNSrLaawOGFe9wNdWu6xA7kwDO6L/UHgglpFuxhBU370PoU3X29mT4sG0QY 4INxDlYc1AMXS2iafQZxntzRs7X8iGmXI8/RmYAH3PLvEt0UQmKndkNsIpGEWN7KKWSH W1dAUs4ldfIWBoOlyS0pKrS+bTBhHgFaSULODMbWSTkhXqt+x2CugP/50mCXMkIy/N7t bwE6m2jC4MeNt5tJ0IkovWneUl1YVmVVJrfR5vLExpSDzd/d8t4YYLUOicXpN1koVblU oteA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=aYpPZYtqod+fTEVMSorWhJ9m+fKXe1m4+frfAcmvGyw=; b=v8KNXpYoT6dshYx1/+4CxckWCBmeTw1u+bsHrz337PISPxLhW1r1xmslCEiVeF6bRm gveiBCKmOY+OPw6eomEMpXSK9jd4o3uUtdXNjha5lnPNmp76O4T1vwp904IW60mjO/5g VYdSbvkUSytXK8cKohm5icuZQ8Vj8rs+cVT0KA8sTnDGT7SPI6cM4+0ovsGmph6koQNC BIPzYlo/ibG3xfKG6+Oz/8KA2VgOt54REJjw1zu1xdHzwNx53/VcyxdecGMVL2Gv46bk pT9Trg+QWWfXLKVpWCFRUIYTEKp85Z3Utc6WDnJSFwamrGEKxadTi4RDYolKVMDXBAgz BYqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=kyQ9OWt0; 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 68si11989454pgb.104.2019.08.20.06.32.15; Tue, 20 Aug 2019 06:32:31 -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=@ziepe.ca header.s=google header.b=kyQ9OWt0; 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 S1730059AbfHTNbI (ORCPT + 99 others); Tue, 20 Aug 2019 09:31:08 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:36141 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729203AbfHTNbI (ORCPT ); Tue, 20 Aug 2019 09:31:08 -0400 Received: by mail-qt1-f194.google.com with SMTP id z4so5981544qtc.3 for ; Tue, 20 Aug 2019 06:31:07 -0700 (PDT) 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 :user-agent; bh=aYpPZYtqod+fTEVMSorWhJ9m+fKXe1m4+frfAcmvGyw=; b=kyQ9OWt0i7+BfpuIcyUPTFQLZeuohCEC5hlVUNQiEKpacPgte/tVYaXCcoWS0iNX46 LbDElheqaJ2KHddRS3Bu1aFYUKIF2VpbD9EaDtyp4ulfo2y9LapY2j2xgHMY5n6AgQGw h4SFdWkbBCEN0DxcCvSoBBbBbofopvxvLfyOOYwAaZFocYVAJnpeBoqzpNLDQWNPUm6p i5owmJsN0JKV6XnsgkHqBSTsTXrlH7ufNqL47j8nTzIRKN8roxX/xH2mNEAvLkFk1b2T eLX65YwAZeD6TPycNJswzneMyzYbv45HIRhTCNU/IO+ns1pewbMV0/JRx5RbGFzoVUz2 E1NA== 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:user-agent; bh=aYpPZYtqod+fTEVMSorWhJ9m+fKXe1m4+frfAcmvGyw=; b=dP7mQVlCCdWoXHNVXZTQP0mP2MGfnjMis2L8CiNJTtshbQUZV9gHvRCjTbGikuqu/3 vjH+0X/Rw4+3hWrYGSTSZF4Z/w67VVXIMD/xAjb5tG+p5e61adsjYUW2CG0n6AFS8RwX SkKKT0WH3QL5GXHcBCDufF8+vT0PkR7df/cOJaazqU7HNoz0G1z7ZUV8XAnQZFmCFmNZ ahxds5yjhvC8HO3xieLpmLAmhLs2N43gZPRiyySPKWSNAEctxhswwxXbo7hReFi67tFE KndXPyY838MfxubFbnDMyOnn85c6w4b55mwu19lciRaRn7yfCAjbh3LU++Xg5QURmI6a l5Ew== X-Gm-Message-State: APjAAAWiudP06wnP4Br7LvYTydjeaqZpRDUOxDSYbyDgwaum4tr0tPNR 9ufPrVrcpmRzxg5BJFaMBzJIoQ== X-Received: by 2002:a0c:ab49:: with SMTP id i9mr14487677qvb.142.1566307867024; Tue, 20 Aug 2019 06:31:07 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-55-100.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.55.100]) by smtp.gmail.com with ESMTPSA id u23sm8481051qkj.98.2019.08.20.06.31.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Aug 2019 06:31:06 -0700 (PDT) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1i04E6-0000Y2-5B; Tue, 20 Aug 2019 10:31:06 -0300 Date: Tue, 20 Aug 2019 10:31:06 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: LKML , Linux MM , DRI Development , Intel Graphics Development , Chris Wilson , Andrew Morton , David Rientjes , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Michal Hocko , Christian =?utf-8?B?S8O2bmln?= , Greg Kroah-Hartman , Mike Rapoport , Daniel Vetter Subject: Re: [PATCH 1/4] mm, notifier: Add a lockdep map for invalidate_range_start/end Message-ID: <20190820133106.GE29246@ziepe.ca> References: <20190820081902.24815-1-daniel.vetter@ffwll.ch> <20190820081902.24815-2-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190820081902.24815-2-daniel.vetter@ffwll.ch> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 20, 2019 at 10:18:59AM +0200, Daniel Vetter wrote: > This is a similar idea to the fs_reclaim fake lockdep lock. It's > fairly easy to provoke a specific notifier to be run on a specific > range: Just prep it, and then munmap() it. > > A bit harder, but still doable, is to provoke the mmu notifiers for > all the various callchains that might lead to them. But both at the > same time is really hard to reliable hit, especially when you want to > exercise paths like direct reclaim or compaction, where it's not > easy to control what exactly will be unmapped. > > By introducing a lockdep map to tie them all together we allow lockdep > to see a lot more dependencies, without having to actually hit them > in a single challchain while testing. > > On Jason's suggestion this is is rolled out for both > invalidate_range_start and invalidate_range_end. They both have the > same calling context, hence we can share the same lockdep map. Note > that the annotation for invalidate_ranage_start is outside of the > mm_has_notifiers(), to make sure lockdep is informed about all paths > leading to this context irrespective of whether mmu notifiers are > present for a given context. We don't do that on the > invalidate_range_end side to avoid paying the overhead twice, there > the lockdep annotation is pushed down behind the mm_has_notifiers() > check. > > v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion > with this being a real mutex (Chris Wilson). > > v3: Rebase on top of Glisse's arg rework. > > v4: Also annotate invalidate_range_end (Jason Gunthorpe) > Also annotate invalidate_range_start_nonblock, I somehow missed that > one in the first version. > > Cc: Jason Gunthorpe > Cc: Chris Wilson > Cc: Andrew Morton > Cc: David Rientjes > Cc: "Jérôme Glisse" > Cc: Michal Hocko > Cc: "Christian König" > Cc: Greg Kroah-Hartman > Cc: Daniel Vetter > Cc: Mike Rapoport > Cc: linux-mm@kvack.org > Signed-off-by: Daniel Vetter > --- > include/linux/mmu_notifier.h | 8 ++++++++ > mm/mmu_notifier.c | 9 +++++++++ > 2 files changed, 17 insertions(+) Reviewed-by: Jason Gunthorpe Jason