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=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 2F704C433E1 for ; Thu, 11 Jun 2020 14:29:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CBC532065C for ; Thu, 11 Jun 2020 14:29:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="FseEPp8F" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CBC532065C 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 27CAF8D009D; Thu, 11 Jun 2020 10:29:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22C8A8D0084; Thu, 11 Jun 2020 10:29:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11AB68D009D; Thu, 11 Jun 2020 10:29:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0129.hostedemail.com [216.40.44.129]) by kanga.kvack.org (Postfix) with ESMTP id EE67A8D0084 for ; Thu, 11 Jun 2020 10:29:56 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id ABC56182EB19C for ; Thu, 11 Jun 2020 14:29:56 +0000 (UTC) X-FDA: 76917165192.18.peace63_631416e26dd4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 7B3011012BB60 for ; Thu, 11 Jun 2020 14:29:56 +0000 (UTC) X-HE-Tag: peace63_631416e26dd4 X-Filterd-Recvd-Size: 6890 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 11 Jun 2020 14:29:55 +0000 (UTC) Received: by mail-qv1-f66.google.com with SMTP id di13so2689746qvb.12 for ; Thu, 11 Jun 2020 07:29:55 -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; bh=iS2yXa8gKHNwS2UChvutG5V1O7eVsWQuqeZ34MVLXc0=; b=FseEPp8Fso/6As15zVP3Ym7NPs9kvuOvCIptWPzePslhXjFzBDqQXKhNnYWATD+15R Al/WYp+hbHsKFK4X2ojiK+EHs7yhQmmL+EDMNyPnOR89aEMfOJc5yjRH0aJYrgc62Vs4 Doe6mzmOoH4EXTAuqTBF2FSP/hDXXwvjF9/30kmpRxNG9NB7+P9LM/fisKeD5/yoOQW2 PEChRlkS/fkvSbixN4O37472Uu4NlrAggCY6VhNzkkPK4SDvGr55LxYD+4T/EdoOhWVl 4gdKknLaMPLAltUrhRVsboI89uK5/pkjAghK31JbmOaIh7KRRHIu3+t+3Jd7dolDArof vWaA== 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=iS2yXa8gKHNwS2UChvutG5V1O7eVsWQuqeZ34MVLXc0=; b=DdltjfOX83LVUSh0Q4ZSiYtR3zy+prGjo3qtq9oghTT44T24LSWOYPssV1TnoWpcgc JD77f488zQCzAUv8x5rvv+ze/I3Zc2fYlv7kX27I1DCBY5af4nDYlXSlYM5EW1+BD9xg 4Ijoafv2TiGXedKI/4gAFP2PItSAQlZ4JupsYTjarp4WXObHm7H9g3tvDHYq3P//4kf8 ZxKWd9lxprg3BUXCxvxGT3DhlTScMlRpudbiByH70hBiUGP7jjIGbuZFLcgtWppZhusL An0myWAHTkXwTVobQYAqYOW85z6Yb8q7xhOE09XQpJ34CBP7XMWH+cjcVpEjUXTNLnGv LjQQ== X-Gm-Message-State: AOAM530YSADDWXBxD1N6TOGFKX4vh2RHDGNCGV7g0mTrKhS/Dnzoz8mV JYijzyDzakYwk2Ct4MxWYjP2aQ== X-Google-Smtp-Source: ABdhPJyglizbugl/WH3rPRKasgzr+R/H6TfhyQSpLDpaYV29o2R1YgDECnGExOwsuREk0P31Na2jyw== X-Received: by 2002:a05:6214:13e6:: with SMTP id ch6mr8093893qvb.29.1591885794923; Thu, 11 Jun 2020 07:29:54 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id 195sm2287728qkg.74.2020.06.11.07.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2020 07:29:54 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.93) (envelope-from ) id 1jjODJ-005xNV-Ml; Thu, 11 Jun 2020 11:29:53 -0300 Date: Thu, 11 Jun 2020 11:29:53 -0300 From: Jason Gunthorpe To: Daniel Vetter Cc: Intel Graphics Development , DRI Development , LKML , amd-gfx@lists.freedesktop.org, Thomas =?utf-8?Q?Hellstr=C3=B6m?= , Andrew Morton , linux-mm@kvack.org, linux-rdma@vger.kernel.org, Maarten Lankhorst , Christian =?utf-8?B?S8O2bmln?= , Daniel Vetter Subject: Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release Message-ID: <20200611142953.GA1419658@ziepe.ca> References: <20200604081224.863494-2-daniel.vetter@ffwll.ch> <20200610194101.1668038-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200610194101.1668038-1-daniel.vetter@ffwll.ch> X-Rspamd-Queue-Id: 7B3011012BB60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote: > fs_reclaim_acquire/release nicely catch recursion issues when > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend > to use to keep the excessive caches in check). For mmu notifier > recursions we do have lockdep annotations since 23b68395c7c7 > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end"). >=20 > But these only fire if a path actually results in some pte > invalidation - for most small allocations that's very rarely the case. > The other trouble is that pte invalidation can happen any time when > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier > recursion. >=20 > I was pondering whether we should just do the general annotation, but > there's always the risk for false positives. Plus I'm assuming that > the core fs and io code is a lot better reviewed and tested than > random mmu notifier code in drivers. Hence why I decide to only > annotate for that specific case. >=20 > Furthermore even if we'd create a lockdep map for direct reclaim, we'd > still need to explicit pull in the mmu notifier map - there's a lot > more places that do pte invalidation than just direct reclaim, these > two contexts arent the same. >=20 > Note that the mmu notifiers needing their own independent lockdep map > is also the reason we can't hold them from fs_reclaim_acquire to > fs_reclaim_release - it would nest with the acquistion in the pte > invalidation code, causing a lockdep splat. And we can't remove the > annotations from pte invalidation and all the other places since > they're called from many other places than page reclaim. Hence we can > only do the equivalent of might_lock, but on the raw lockdep map. >=20 > With this we can also remove the lockdep priming added in 66204f1d2d1b > ("mm/mmu_notifiers: prime lockdep") since the new annotations are > strictly more powerful. >=20 > v2: Review from Thomas Hellstrom: > - unbotch the fs_reclaim context check, I accidentally inverted it, > but it didn't blow up because I inverted it immediately > - fix compiling for !CONFIG_MMU_NOTIFIER >=20 > Cc: Thomas Hellstr=C3=B6m (Intel) > Cc: Andrew Morton > Cc: Jason Gunthorpe > Cc: linux-mm@kvack.org > Cc: linux-rdma@vger.kernel.org > Cc: Maarten Lankhorst > Cc: Christian K=C3=B6nig > Signed-off-by: Daniel Vetter > --- > This is part of a gpu lockdep annotation series simply because it > really helps to catch issues where gpu subsystem locks and primitives > can deadlock with themselves through allocations and mmu notifiers. > But aside from that motivation it should be completely free-standing, > and can land through -mm/-rdma/-hmm or any other tree really whenever. > -Daniel I'm still not totally clear on how all the GFP flags map to different behaviors, but this seems plausible to me At this point it should go through Andrew's tree, thanks Acked-by: Jason Gunthorpe # For mmu_notifiers Jason