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=-14.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL 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 63B40C47082 for ; Fri, 4 Jun 2021 02:46:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3BD1B61263 for ; Fri, 4 Jun 2021 02:46:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229803AbhFDCsY (ORCPT ); Thu, 3 Jun 2021 22:48:24 -0400 Received: from mail-oi1-f181.google.com ([209.85.167.181]:40711 "EHLO mail-oi1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbhFDCsX (ORCPT ); Thu, 3 Jun 2021 22:48:23 -0400 Received: by mail-oi1-f181.google.com with SMTP id f30so7082813oij.7 for ; Thu, 03 Jun 2021 19:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=855vlSEYhsLOGNdJcugYbdlOBheupCBIdY8o4dmTr/0=; b=aymqnrJmRWg5jXI6iKWsmz4jrob/orNsUCAC8p8/H1z8/H1qH0Ap4GOSkiuU0OhZwC NSysJZDc8NqFnY1EWohSavsL1H6CP9VB/d4GZ9X3syjDiyGFBbrcOgXTlR6ZY5V+6xrp 1qtT5Drf272NI5zkkGK6CMFyaDN689nWJ/WDOqUpKRdPS6tsLzghBhm/D08LtGsgOAha JAL6/4VEZWRXeumpuGv1+k6y2/btUDHnVZrRfc/NFo7fe834/BpS8hLik41C+d+23Rj5 TI6MHqhzMW84NjjH+h+HCnceTHSZaDq5vNQiL6oF20cgEMqDFZz6p+K+QSbUZJauHD2l bGww== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=855vlSEYhsLOGNdJcugYbdlOBheupCBIdY8o4dmTr/0=; b=BcaU2YuTcAeWYXtnPEce1D2r4c1XmPv1PRtg3RNtkOz8uqvWhXysUUsVTOtUwFvG/D dtvV5BX9sOv/7aR5sv0sy7cQ632NtvLd7JN3e+qPqKnL6Qt2uq9j0xcGpYyaoBuIf9Xa OL/zKtg9a0XXAxpGS398eZepfTu7+jzU8uXqd3M0pZOEO6TuG+QLh6iiX4QQvIgV/Tni ykzj59OfEtKXMHBPbXPjQZ1xjFOGzUh2O4VLMkznHLIKLzhhTUhpVk5NGsBHG95guqek GBFe32WfzE5DEsfTlJrcjIE1FvKmDLGTRsSTa69LhS1pDaPksdIDCg/JnaOgyK8BUWJz AePg== X-Gm-Message-State: AOAM531C+nDzky0QK6VeoZfPSriB0TqV8Q4Mv7kjufw3IEfbVUTuFx/9 kDdAAhDLguzv2deeVnFygtbppg== X-Google-Smtp-Source: ABdhPJzRyhZp5CykGMFTeTYXTpk0uIoK9A9IkhdVQ1PT2z8ehR0eKm4KQe1UC3BvFixUimvRrO9kKQ== X-Received: by 2002:a05:6808:8a:: with SMTP id s10mr6703449oic.33.1622774724484; Thu, 03 Jun 2021 19:45:24 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id b81sm198114oia.19.2021.06.03.19.45.22 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 03 Jun 2021 19:45:24 -0700 (PDT) Date: Thu, 3 Jun 2021 19:45:21 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Yang Shi cc: Hugh Dickins , Andrew Morton , "Kirill A. Shutemov" , Wang Yugui , Matthew Wilcox , Naoya Horiguchi , Alistair Popple , Ralph Campbell , Zi Yan , Miaohe Lin , Minchan Kim , Jue Wang , Peter Xu , Jan Kara , Linux MM , Linux Kernel Mailing List Subject: Re: [PATCH 2/7] mm/thp: try_to_unmap() use TTU_SYNC for safe DEBUG_VM splitting In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jun 2021, Yang Shi wrote: > On Tue, Jun 1, 2021 at 2:07 PM Hugh Dickins wrote: > > > > Instead of abandoning the unsafe VM_BUG_ON_PAGE(), and the ones that > > follow, use PVMW_SYNC in try_to_unmap_one() in this case: adding TTU_SYNC > > to the options, and passing that from unmap_page() when CONFIG_DEBUG_VM=y. > > It could be passed in the non-debug case too, but that would sometimes add > > a little overhead, whereas it's rare for this race to result in failure. > > The above statement makes me feel this patch is just to relieve the > VM_BUG_ON, but my patch already changed it to VM_WARN, the race sounds > acceptable (at least not fatal) and the splitting code can handle the > failure case as well. So I'm wondering if we still need this patch or > not if it is just used to close the race when CONFIG_DEBUG_VM=y. I do agree that your 1/2 (what I'm calling 6.1/7) BUG->WARN patch is the most important of them; but it didn't get marked for stable, and has got placed behind conflicting mods never intended for stable. And a lot of the descriptions had been written in terms of the prior situation, with VM BUG there: it was easier to keep describing that way. Whether your fix makes mine redundant is arguable (Wang Yugui thinks not). It's easier to argue that it makes the racy ones (like this) redundant, than the persistent ones (like vma_address or pvm_walk). Since I know of at least one customer who wants all these fixes in 5.10 longterm, I'm fighting to get them that far at least. But the further back they go, the less effort I'll make to backport them - will fall back to porting your BUG->WARN only. Hugh 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=-14.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL 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 3647EC47096 for ; Fri, 4 Jun 2021 02:45:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C40096140A for ; Fri, 4 Jun 2021 02:45:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C40096140A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5BD0C6B0036; Thu, 3 Jun 2021 22:45:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 545146B006C; Thu, 3 Jun 2021 22:45:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3979D6B006E; Thu, 3 Jun 2021 22:45:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 03E3B6B0036 for ; Thu, 3 Jun 2021 22:45:42 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8D0EE4408 for ; Fri, 4 Jun 2021 02:45:42 +0000 (UTC) X-FDA: 78214500924.36.BEB8D72 Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by imf12.hostedemail.com (Postfix) with ESMTP id 3A669353C for ; Fri, 4 Jun 2021 02:45:21 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id v22so8405078oic.2 for ; Thu, 03 Jun 2021 19:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=855vlSEYhsLOGNdJcugYbdlOBheupCBIdY8o4dmTr/0=; b=aymqnrJmRWg5jXI6iKWsmz4jrob/orNsUCAC8p8/H1z8/H1qH0Ap4GOSkiuU0OhZwC NSysJZDc8NqFnY1EWohSavsL1H6CP9VB/d4GZ9X3syjDiyGFBbrcOgXTlR6ZY5V+6xrp 1qtT5Drf272NI5zkkGK6CMFyaDN689nWJ/WDOqUpKRdPS6tsLzghBhm/D08LtGsgOAha JAL6/4VEZWRXeumpuGv1+k6y2/btUDHnVZrRfc/NFo7fe834/BpS8hLik41C+d+23Rj5 TI6MHqhzMW84NjjH+h+HCnceTHSZaDq5vNQiL6oF20cgEMqDFZz6p+K+QSbUZJauHD2l bGww== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=855vlSEYhsLOGNdJcugYbdlOBheupCBIdY8o4dmTr/0=; b=Fn47O7nvYCmdW2Els6BBbcNoaL3gMDDzCfxtIkog9ReS9YWDHpdOOljskpBwrNkpWT SrHw0TPOMWchHLJBpUmUAyshUv6VUEdZttawD99YFq5v3uX30bxVFZOxNMAAAzONIAU/ EexNQz9/lQtX/0dcZuPxhMRzJw/MhfR0cY/LgT5aLOsEo5jsmTMN0vljiKNR9/iO7bcu 4Sy9Cim5yw7ihA/yIR5dMUNEFm8jVeMUeIUO6Y0QGprLQZ5moTcRIzcQ1/yXB6zVyQF8 06s93v7DaDmqILzlBikWs0lSAtQQFACJpDV+mJYQ1jjCQTajIwaaLJlf+/A6Sy+xW4dw 3S5Q== X-Gm-Message-State: AOAM530eJNWbhAaEBea1IVxA/gCYnrRXy52OOAtfaeVXt6Km7wKriJmw jw5uwgrFrcIeKfxf1e06x1RyBQ== X-Google-Smtp-Source: ABdhPJzRyhZp5CykGMFTeTYXTpk0uIoK9A9IkhdVQ1PT2z8ehR0eKm4KQe1UC3BvFixUimvRrO9kKQ== X-Received: by 2002:a05:6808:8a:: with SMTP id s10mr6703449oic.33.1622774724484; Thu, 03 Jun 2021 19:45:24 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id b81sm198114oia.19.2021.06.03.19.45.22 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 03 Jun 2021 19:45:24 -0700 (PDT) Date: Thu, 3 Jun 2021 19:45:21 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Yang Shi cc: Hugh Dickins , Andrew Morton , "Kirill A. Shutemov" , Wang Yugui , Matthew Wilcox , Naoya Horiguchi , Alistair Popple , Ralph Campbell , Zi Yan , Miaohe Lin , Minchan Kim , Jue Wang , Peter Xu , Jan Kara , Linux MM , Linux Kernel Mailing List Subject: Re: [PATCH 2/7] mm/thp: try_to_unmap() use TTU_SYNC for safe DEBUG_VM splitting In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3A669353C X-Stat-Signature: sr4417f5fs4mxw9wnh7tag16h85nkpkr Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=aymqnrJm; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of hughd@google.com designates 209.85.167.178 as permitted sender) smtp.mailfrom=hughd@google.com X-HE-Tag: 1622774721-445563 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 Thu, 3 Jun 2021, Yang Shi wrote: > On Tue, Jun 1, 2021 at 2:07 PM Hugh Dickins wrote: > > > > Instead of abandoning the unsafe VM_BUG_ON_PAGE(), and the ones that > > follow, use PVMW_SYNC in try_to_unmap_one() in this case: adding TTU_SYNC > > to the options, and passing that from unmap_page() when CONFIG_DEBUG_VM=y. > > It could be passed in the non-debug case too, but that would sometimes add > > a little overhead, whereas it's rare for this race to result in failure. > > The above statement makes me feel this patch is just to relieve the > VM_BUG_ON, but my patch already changed it to VM_WARN, the race sounds > acceptable (at least not fatal) and the splitting code can handle the > failure case as well. So I'm wondering if we still need this patch or > not if it is just used to close the race when CONFIG_DEBUG_VM=y. I do agree that your 1/2 (what I'm calling 6.1/7) BUG->WARN patch is the most important of them; but it didn't get marked for stable, and has got placed behind conflicting mods never intended for stable. And a lot of the descriptions had been written in terms of the prior situation, with VM BUG there: it was easier to keep describing that way. Whether your fix makes mine redundant is arguable (Wang Yugui thinks not). It's easier to argue that it makes the racy ones (like this) redundant, than the persistent ones (like vma_address or pvm_walk). Since I know of at least one customer who wants all these fixes in 5.10 longterm, I'm fighting to get them that far at least. But the further back they go, the less effort I'll make to backport them - will fall back to porting your BUG->WARN only. Hugh