Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1175580pxj; Fri, 4 Jun 2021 07:51:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxSUsHoxUn7CKA00SOs9tbo8/yEIBRKhLihDCGLzwhoxsfSO7CKTWLwAh8scIl5YDIT48+W X-Received: by 2002:a17:906:128e:: with SMTP id k14mr4496919ejb.485.1622818312904; Fri, 04 Jun 2021 07:51:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622818312; cv=none; d=google.com; s=arc-20160816; b=Ci45zkafDZWqtyZmyVkjIiZC4t7QXCZMLjGlfSfMhuYGj0sQ4iNk2euqG3MVQOTpRA vN5RpRIyp/4Dkea2+UpjotexuchCuzaGUWygINh8Nai/cUz3nGYKvb087z2yyWuzqY7R s1P2X/WnyywOiGFYZocI79nxjTK57d+3sXivRQKQskGt9q/emgUxJ9Wf5/5LiABOWwfm Eqg9ihqHZ7FbT+0oYRwIGavCM/CU95c0KWBb3MxelF8YJ54fMtmpbfiZS1qXv9cbDA0a AhNzJMA4mnWntBALMW1xhehtcunpzZKf6DUIrBTWu8FZxiHLwBHUoIuMVIaA6RBEpNqX dbZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jp1+wVSB+7vvWzgBMXFHA8qcBIuZi+O0ew+V7NeqdBE=; b=cAMYy6JL5qOMrCWneW0DTTTNsmEBhpk1lKZOIndN1uiirRw1xEIIRB8/yl05o1kVQf OtQ24pEoQDbYWPPRUXDQy0oqsROrUoErVCzBI0AH/VjgkStonmZ2MDQqqji0kAsfyF1v 2d9h9fz5T6xXM8u266QZHWZVdjgRaQ6rI1rUqsjHNFhklWjGf4YFPtPsJ7/5TjGYLnLB MV7wRw3oaCEsqIon/B+cSggZt1fE+Tu0rkLVkzc76Ziqj/H7wJBONm/Jl6MmAj1h02Dl 0SPYRU83GLPG6Q0RsOSF8xSrkGwUiWbI2gG6wISKxAuXVlmB1UTRFbox/AdKjkybxLsM VINA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Kv8VkCjz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hh15si4908790ejb.221.2021.06.04.07.51.29; Fri, 04 Jun 2021 07:51:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Kv8VkCjz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229941AbhFDOue (ORCPT + 99 others); Fri, 4 Jun 2021 10:50:34 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:31004 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229656AbhFDOud (ORCPT ); Fri, 4 Jun 2021 10:50:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622818126; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jp1+wVSB+7vvWzgBMXFHA8qcBIuZi+O0ew+V7NeqdBE=; b=Kv8VkCjzf0fqi2PR7/UwtesqbWeIHMwljPqPBIxj6cW7YjxKuUJfQl4wkYtUrAVGTnp2Ie pOFruiA57L+r8+dOHtX7oxFJSWUYAXeS55iC1hbquxyHQ2kWqLlTkYmSwZd+LifMMkL9zu XREJFUWIHnuE9dkiTT+80UfS4lvN0mU= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-108-TFw1viItPCSwN4VC1TE5iw-1; Fri, 04 Jun 2021 10:48:40 -0400 X-MC-Unique: TFw1viItPCSwN4VC1TE5iw-1 Received: by mail-qt1-f200.google.com with SMTP id q3-20020a05622a0303b02902390ac8c906so5306261qtw.11 for ; Fri, 04 Jun 2021 07:48:40 -0700 (PDT) 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:in-reply-to; bh=jp1+wVSB+7vvWzgBMXFHA8qcBIuZi+O0ew+V7NeqdBE=; b=q24MAud7MiP0cZHZuYTTfPUope2wT/Ufeu+heNN0AaQxMz7ZZpAMHdm/6ZEwzdi6GC fusoEoIsqY2x9X/0apPotohWQd24oTjf8oYc2HLewZ5vHggH/eSCDiybHolcCiQGhzzy QMfJVmX68PxvxN2qgDmyEUfPKx+xIIBjWI1GWjPu2rDD3hSaJkl741a/3KDhj3OIZqbs HKhmlZSooDRZc7Y8XKI+hpwRqqdmAdmCp66qpbBeeLVVMOAS0+ApN2OCafDtVE43/gyu oTDt9oN5w86mSi2l0lpwwQckx0MLopgnLdChF1QZFRC7DN+rluldB/5qcjDZ/wKL5AK9 OUmA== X-Gm-Message-State: AOAM530W7lSMvLvqM6boEgeePBHUYvOGDvUYxyFvhzOp4zofpPozA3L3 u1ucxWB8I69710BHJHFRM1R8F5VqVQWnAA2LJVpoUX0P9Ar0G2mZXzkx55VfA5bJnUfjLetbq1C /zXEnRj6NgfTT9qg2caGWTQ9Q X-Received: by 2002:ac8:5a44:: with SMTP id o4mr4892958qta.189.1622818119988; Fri, 04 Jun 2021 07:48:39 -0700 (PDT) X-Received: by 2002:ac8:5a44:: with SMTP id o4mr4892931qta.189.1622818119759; Fri, 04 Jun 2021 07:48:39 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-61-184-147-118-108.dsl.bell.ca. [184.147.118.108]) by smtp.gmail.com with ESMTPSA id 85sm4038779qko.14.2021.06.04.07.48.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 07:48:38 -0700 (PDT) Date: Fri, 4 Jun 2021 10:48:37 -0400 From: Peter Xu To: Hugh Dickins Cc: Andrew Morton , "Kirill A. Shutemov" , Yang Shi , Wang Yugui , Matthew Wilcox , Naoya Horiguchi , Alistair Popple , Ralph Campbell , Zi Yan , Miaohe Lin , Minchan Kim , Jue Wang , Jan Kara , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/7] mm/thp: try_to_unmap() use TTU_SYNC for safe DEBUG_VM splitting Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 03, 2021 at 07:54:11PM -0700, Hugh Dickins wrote: > On Thu, 3 Jun 2021, Peter Xu wrote: > > On Tue, Jun 01, 2021 at 02:07:53PM -0700, Hugh Dickins wrote: > > > diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c > > > index 2cf01d933f13..b45d22738b45 100644 > > > --- a/mm/page_vma_mapped.c > > > +++ b/mm/page_vma_mapped.c > > > @@ -212,6 +212,14 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw) > > > pvmw->ptl = NULL; > > > } > > > } else if (!pmd_present(pmde)) { > > > + /* > > > + * If PVMW_SYNC, take and drop THP pmd lock so that we > > > + * cannot return prematurely, while zap_huge_pmd() has > > > + * cleared *pmd but not decremented compound_mapcount(). > > > + */ > > > + if ((pvmw->flags & PVMW_SYNC) && > > > + PageTransCompound(pvmw->page)) > > > + spin_unlock(pmd_lock(mm, pvmw->pmd)); > > > return false; > > > } > > > if (!map_pte(pvmw)) > > > > Sorry if I missed something important, but I'm totally confused on how this > > unlock is pairing with another lock().. > > I imagine you're reading that as spin_unlock(pmd_lockptr(blah)); > no, the lock is right there, inside spin_unlock(pmd_lock(blah)). Heh, yeah... Sorry about that. > > > > > And.. isn't PVMW_SYNC only meaningful for pte-level only (as I didn't see a > > reference of it outside map_pte)? > > But you are pointing directly to its reference outside map_pte()! Right, I was trying to look for the lock() so I needed to look at all the rest besides this one. :) I didn't follow Yang's patch, but if Yang's patch can make kernel not crashing and fault handling done all well, then I'm kind of agree with him: having workaround code (like taking lock and quickly releasing..) only for debug code seems an overkill to me, not to mention that the debug code will be even more strict after this patch, as it means it's even less likely that one can reproduce one production host race with DEBUG_VM.. Normally debugging code would affect code execution already, and for this one we're enlarging that gap "explicitly" - not sure whether it's good. This also makes me curious what if we make !DEBUG_VM strict too - how much perf we'll lose? Haven't even tried to think about it with details, but just raise it up. Say, is there any chance we make the debug/non-debug paths run the same logic (e.g. of SYNC version)? -- Peter Xu