Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp390756imu; Mon, 26 Nov 2018 23:50:34 -0800 (PST) X-Google-Smtp-Source: AFSGD/Ul3tKv+3U+RDWw4yPkAVgQb92smCpZjiBMx0qj5Q9iM/+dgoEysMney0STjk9pMwrfyZpW X-Received: by 2002:a63:495b:: with SMTP id y27mr28241049pgk.32.1543305034384; Mon, 26 Nov 2018 23:50:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543305034; cv=none; d=google.com; s=arc-20160816; b=tkCl7/q4ZA0oS14Y1vSTamk1IUF/N2wqmWYKvlNZm01CMrg14GmwAAU4DI5ZyKtowO dJC/GuiIporCJ7giHcEdRELVR1+LGkQnzcsyj/sE8WZAySViMYgTAtCBNsPAfGArvA3+ IxXwyiEBiWOaYNS2mXFx4tT09zkz12+BDZYX0ea6VCEPa8aPUOhfXOZzCuEkv6VS1BNF 1xm0ExAmdKrZTiDExtAXLY1Ldxi0t5zh4yGHtCQtzcNE295rnmM78WzbhabdOXEdNqCX +t2MXDwzVOzRJHez8IZc9B/WK+pPTm7BMSVzUEEl5wqzVHDucNm5cA++lkR4eAtpB9Q6 YaaA== 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:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature; bh=K+hwhRQbtFrWQFqTn6T/jv0euH/QggHE+ezb2jMjYFc=; b=jTZs8cAeUZqki9nF4cFgMSTQ4Eq3Sdy5gDPCRBmcmfOmRf69SSyYk9ZIiQrUG+PHif e3uEy1K+eBy9cGAB7EH01SzDEbLcGJy5HWPGLtkU+vQ72bTkUzdpLP/NnN/nC842Tc91 1dQm4+igYeAWfBMJuRUwi4BLWI0T8PFAKJo/2PBOipLA66NB7HQDHpwdopDED/gmqim9 LJhKBaCwHvueAsSgk+hTD//XCNiMvwvXCRlBOWTbR6UCSFHb3iYXmQO1y8/6t5Yd9zu9 psFJpf5EfFgkdOuF+5jAYDkaEV7JPXyRvQHfqAPeNDSLSjgWwu9Anwz7Tftpd2qTxhu3 2WTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=At9BTUEj; 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 e125si3288013pfe.14.2018.11.26.23.50.19; Mon, 26 Nov 2018 23:50:34 -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=fail header.i=@ffwll.ch header.s=google header.b=At9BTUEj; 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 S1729181AbeK0SqZ (ORCPT + 99 others); Tue, 27 Nov 2018 13:46:25 -0500 Received: from mail-ed1-f67.google.com ([209.85.208.67]:42697 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728921AbeK0SqZ (ORCPT ); Tue, 27 Nov 2018 13:46:25 -0500 Received: by mail-ed1-f67.google.com with SMTP id j6so18135579edp.9 for ; Mon, 26 Nov 2018 23:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=K+hwhRQbtFrWQFqTn6T/jv0euH/QggHE+ezb2jMjYFc=; b=At9BTUEjadwzyCCyanuIMRFlACbBAhsjdMoBi0BRWFldJ8s9oG72GA/hd1kn4Y3t1i W6D0I5v8tppgJFPeG2CLIEmUerbJCK65vRRoxUUaQr7xShSbTUgljd7oBxJKAduDdv4T OCEvLz2mXFpdrU7kittFK8imkjHDsdt95hTJw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=K+hwhRQbtFrWQFqTn6T/jv0euH/QggHE+ezb2jMjYFc=; b=Y+dCaHoZc+2DWRUkdnmO/TiEXvSfJJDUEP7gOzuz0T+oWhTFyU4zh6xu3BuEobhd+I /G9lUQ7l49XfG9+UVqL4jM/DS07E1xn3dhMlLeRcvZ9BeE3FV3gJA4USDW1PRpdDy9QM sdauKaADgCpx6GWTDQ6VEy7xTWKlTmEqESbJT4NhLj0fJJq9xlXbwpemgwzWAkfJH36M CWD+2gjs3k4C6uj7PwoB/10kLwxzQJi3HUDjXq6F/HWQq0BeWMa67Frfl179whFrgmvx OHaup2NR1Q6pnWh1fzHiLGrdpPWf4PFViDWAJvfa8t4iydbP0pJFUHDfOY9+uAX/OzxY hdgg== X-Gm-Message-State: AA+aEWYYXAa4HsFpEyeTWTLyqoJGDfankjHJC44MGdZevIaiPLyBTpmn IKRW11SN/GcFtZMeXtgqcVOxlK0uyg8= X-Received: by 2002:a50:f415:: with SMTP id r21mr8338320edm.110.1543304961991; Mon, 26 Nov 2018 23:49:21 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id i46sm784960ede.62.2018.11.26.23.49.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Nov 2018 23:49:20 -0800 (PST) Date: Tue, 27 Nov 2018 08:49:18 +0100 From: Daniel Vetter To: LKML Cc: Linux MM , Intel Graphics Development , DRI Development , Daniel Vetter , Andrew Morton , David Rientjes , =?iso-8859-1?B?Suly9G1l?= Glisse , Michal Hocko , Christian =?iso-8859-1?Q?K=F6nig?= , Greg Kroah-Hartman , Mike Rapoport , Daniel Vetter Subject: Re: [PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start Message-ID: <20181127074918.GT4266@phenom.ffwll.local> Mail-Followup-To: LKML , Linux MM , Intel Graphics Development , DRI Development , Andrew Morton , David Rientjes , =?iso-8859-1?B?Suly9G1l?= Glisse , Michal Hocko , Christian =?iso-8859-1?Q?K=F6nig?= , Greg Kroah-Hartman , Mike Rapoport , Daniel Vetter References: <20181122165106.18238-1-daniel.vetter@ffwll.ch> <20181122165106.18238-4-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20181122165106.18238-4-daniel.vetter@ffwll.ch> X-Operating-System: Linux phenom 4.18.0-2-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 22, 2018 at 05:51:06PM +0100, 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. > > Aside: Since I typed this to test i915 mmu notifiers I've only rolled > this out for the invaliate_range_start callback. If there's > interest, we should probably roll this out to all of them. But my > undestanding of core mm is seriously lacking, and I'm not clear on > whether we need a lockdep map for each callback, or whether some can > be shared. > > 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 Any comments on this one here? This is really the main ingredient for catching deadlocks in mmu notifier callbacks. The other two patches are more the icing on the cake. Thanks, Daniel > --- > include/linux/mmu_notifier.h | 7 +++++++ > mm/mmu_notifier.c | 7 +++++++ > 2 files changed, 14 insertions(+) > > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h > index 9893a6432adf..a39ba218dbbe 100644 > --- a/include/linux/mmu_notifier.h > +++ b/include/linux/mmu_notifier.h > @@ -12,6 +12,10 @@ struct mmu_notifier_ops; > > #ifdef CONFIG_MMU_NOTIFIER > > +#ifdef CONFIG_LOCKDEP > +extern struct lockdep_map __mmu_notifier_invalidate_range_start_map; > +#endif > + > /* > * The mmu notifier_mm structure is allocated and installed in > * mm->mmu_notifier_mm inside the mm_take_all_locks() protected > @@ -267,8 +271,11 @@ static inline void mmu_notifier_change_pte(struct mm_struct *mm, > static inline void mmu_notifier_invalidate_range_start(struct mm_struct *mm, > unsigned long start, unsigned long end) > { > + mutex_acquire(&__mmu_notifier_invalidate_range_start_map, 0, 0, > + _RET_IP_); > if (mm_has_notifiers(mm)) > __mmu_notifier_invalidate_range_start(mm, start, end, true); > + mutex_release(&__mmu_notifier_invalidate_range_start_map, 1, _RET_IP_); > } > > static inline int mmu_notifier_invalidate_range_start_nonblock(struct mm_struct *mm, > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > index 4d282cfb296e..c6e797927376 100644 > --- a/mm/mmu_notifier.c > +++ b/mm/mmu_notifier.c > @@ -23,6 +23,13 @@ > /* global SRCU for all MMs */ > DEFINE_STATIC_SRCU(srcu); > > +#ifdef CONFIG_LOCKDEP > +struct lockdep_map __mmu_notifier_invalidate_range_start_map = { > + .name = "mmu_notifier_invalidate_range_start" > +}; > +EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map); > +#endif > + > /* > * This function allows mmu_notifier::release callback to delay a call to > * a function that will free appropriate resources. The function must be > -- > 2.19.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch