From nobody Tue Jun 23 14:07:25 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F656C433EF for ; Fri, 4 Mar 2022 04:31:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232055AbiCDEc1 (ORCPT ); Thu, 3 Mar 2022 23:32:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236451AbiCDEcX (ORCPT ); Thu, 3 Mar 2022 23:32:23 -0500 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 205981795FE for ; Thu, 3 Mar 2022 20:31:35 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id 11so6485342qtt.9 for ; Thu, 03 Mar 2022 20:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version; bh=aTbJtV8j5fplGh+y9hP64K8aiDbN2PZ+yad5jwKxTY8=; b=LbTdUllock64OE1OwMtnYr4r0KmMGLlymE7Lee64D5z+FkbK7nQj7/BhYDZNVg1M5K tLUHU8xB1wXdV2Gu4Winb3UnlhKZko26C4nxL4Ck6dleHa7C8p4Em7VP9H4d4aQIKqsX Je1Sk/eAq1OEKZ188GPC3M44Z/ozBUAgx/kasoe1RRt9xehf4Sc2Ezk7dCTm7gwdmjt9 5lVyHJtoBdxHdDfSeWcFuC0z4omqUaUV1saqJ9G4ptNeaHQzdqRIt88qcB9P8UkAwy7B SinFQ6F7fGs2YQfhs+tIjwY5eTGPH3ZPGWzb7QiavHaknUJqMf2dOB0lh+KS2Auu0CZQ AOsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version; bh=aTbJtV8j5fplGh+y9hP64K8aiDbN2PZ+yad5jwKxTY8=; b=IlCkO+80/vZs3hxP0+T12cr76CclgJV6DrDWNYX/EGAef9mlLU98JVDtrNyYj1vyad H3C4jb6UnFYymVocS+mhKw8mKj7PF24BQ0rCBd6Kf0R0GnTbMRCQWsW3AvSA/QIigDsh M2f1TnFWpPeBnJ8Bfx9qDx/FY47iD8yg8xGKiXSB7pSYcqg1caEjBZ5hBpi2Ze492gpz xdGlmKEDF+MoUi144Mh0dblNHJgsV9AA7dGAXlyBIsW2EFFxB54HAENgWvgdvIiyySF+ +3OTOEqoXrqJBl6d6N/BaspjSE5+xSYOpBz5/Szsp3wvJINr3CTDAK8blpfh7/iazGtQ 6N7w== X-Gm-Message-State: AOAM532qKcHctkqTP7b/GkSIyxO3AxyTShl8uzt162FxRPWbrkVEUqFc JZJmVeRQLBGc9g8uqSMK3f2dBw== X-Google-Smtp-Source: ABdhPJwifbzXSXQ/wLbXKhWHJKCumbHB5C1izqmvXzKPpCer3x9VCYc6tIjTcvMM6jMywJyktEHmrQ== X-Received: by 2002:ac8:5b04:0:b0:2dd:2600:2f1 with SMTP id m4-20020ac85b04000000b002dd260002f1mr29366129qtw.364.1646368294018; Thu, 03 Mar 2022 20:31:34 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d16-20020ac85ad0000000b002d71c463d9csm2694100qtd.24.2022.03.03.20.31.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Mar 2022 20:31:33 -0800 (PST) Date: Thu, 3 Mar 2022 20:31:31 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Andrew Morton cc: "Kirill A. Shutemov" , Davidlohr Bueso , Sasha Levin , Mel Gorman , Mike Kravetz , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH mmotm] mm: unmap_mapping_range_tree() with i_mmap_rwsem shared Message-ID: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Revert 48ec833b7851 ("Revert "mm/memory.c: share the i_mmap_rwsem"") to reinstate c8475d144abb ("mm/memory.c: share the i_mmap_rwsem"): the unmap_mapping_range family of functions do the unmapping of user pages (ultimately via zap_page_range_single) without modifying the interval tree itself, and unmapping races are necessarily guarded by page table lock, thus the i_mmap_rwsem should be shared in unmap_mapping_pages() and unmap_mapping_folio(). Commit 48ec833b7851 was intended as a short-term measure, allowing the other shared lock changes into 3.19 final, before investigating three trinity crashes, one of which had been bisected to commit c8475d144ab: [1] https://lkml.org/lkml/2014/11/14/342 https://lore.kernel.org/lkml/5466142C.60100@oracle.com/ [2] https://lkml.org/lkml/2014/12/22/213 https://lore.kernel.org/lkml/549832E2.8060609@oracle.com/ [3] https://lkml.org/lkml/2014/12/9/741 https://lore.kernel.org/lkml/5487ACC5.1010002@oracle.com/ Two of those were Bad page states: free_pages_prepare() found PG_mlocked still set - almost certain to have been fixed by 4.4 commit b87537d9e2fe ("mm: rmap use pte lock not mmap_sem to set PageMlocked"). The NULL deref on rwsem in [2]: unclear, only happened once, not bisected to c8475d144ab. No change to the i_mmap_lock_write() around __unmap_hugepage_range_final() in unmap_single_vma(): IIRC that's a special usage, helping to serialize hugetlbfs page table sharing, not to be dabbled with lightly. No change to other uses of i_mmap_lock_write() by hugetlbfs. I am not aware of any significant gains from the concurrency allowed by this commit: it is submitted more to resolve an ancient misunderstanding. Signed-off-by: Hugh Dickins --- mm/memory.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/memory.c +++ b/mm/memory.c @@ -3388,11 +3388,11 @@ void unmap_mapping_folio(struct folio *folio) details.even_cows =3D false; details.single_folio =3D folio; =20 - i_mmap_lock_write(mapping); + i_mmap_lock_read(mapping); if (unlikely(!RB_EMPTY_ROOT(&mapping->i_mmap.rb_root))) unmap_mapping_range_tree(&mapping->i_mmap, first_index, last_index, &details); - i_mmap_unlock_write(mapping); + i_mmap_unlock_read(mapping); } =20 /** @@ -3418,11 +3418,11 @@ void unmap_mapping_pages(struct address_space *mapp= ing, pgoff_t start, if (last_index < first_index) last_index =3D ULONG_MAX; =20 - i_mmap_lock_write(mapping); + i_mmap_lock_read(mapping); if (unlikely(!RB_EMPTY_ROOT(&mapping->i_mmap.rb_root))) unmap_mapping_range_tree(&mapping->i_mmap, first_index, last_index, &details); - i_mmap_unlock_write(mapping); + i_mmap_unlock_read(mapping); } EXPORT_SYMBOL_GPL(unmap_mapping_pages);