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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E0A1CC4743D for ; Fri, 4 Jun 2021 18:57:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7BEA261153 for ; Fri, 4 Jun 2021 18:57:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BEA261153 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A51916B006E; Fri, 4 Jun 2021 14:57:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A01746B0070; Fri, 4 Jun 2021 14:57:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A1E96B0071; Fri, 4 Jun 2021 14:57:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0247.hostedemail.com [216.40.44.247]) by kanga.kvack.org (Postfix) with ESMTP id 5B41E6B006E for ; Fri, 4 Jun 2021 14:57:01 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DEBB082FADBF for ; Fri, 4 Jun 2021 18:57:00 +0000 (UTC) X-FDA: 78216948600.02.1488285 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf19.hostedemail.com (Postfix) with ESMTP id EC07A9001ECD for ; Fri, 4 Jun 2021 18:56:40 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id og14so10701692ejc.5 for ; Fri, 04 Jun 2021 11:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8NkZLuODRGewH4zgC3asg1j+OkGGx+7ZEADeUCWN74M=; b=AZOMP7RwTJv+l9AGvBTpG43OcDsnnTvgcZRvwckXkRIPNds68iR+iR6l1vRACYm0eF znXZdiMm+96xHm4rcPmcza3bIy6sTFZiupGZPbw6MbkkSJD+vmsDjjq1KkdrTno4J/F8 gSlQ7cA7SyyHwaiBKj2t60vTm4puwPSkfWgGZAeCa0Ew95TCCj7jcwCpe5vyTPKJUhoT +QOHqzem+HNdUt2Ywtwp07U0tswsfMNeZWdtQlYHWxIsk+PTFYmKxZ3H21a5UD6udAxL gnnDD7SOfX5MWhpqkFMK/QonB3sZCo5E1AaUyCUlAG2pF4TqPXYZY7p9m86yy0+IAgSO mYDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8NkZLuODRGewH4zgC3asg1j+OkGGx+7ZEADeUCWN74M=; b=im6EzYC6DF5oppBd0MU8QsMdVfhBBKRgKGzjP6ogH1PyRDUN+5corq2pIY4SJlryyB CjpJhSjvHW4svfAREqD9juNllEEpWi0bJsE8SziQCMTYwEfF8fH/o9VHcjU4/hEZvxiN GFuOM75Q+kqCbbFu1U4DPAyc6DsC1KtY+5WqPLzLaFsFRQPk7Y2g0B11nfNDnMxqGKZ/ 88lgcQFnzxIKBFskpm+MSUO7VuH31yDIH1PNhUwxpHMQoV9FEOZdLxBwdE00rM0E19tc zrDSkb47hH1T+dHJMEGE0ftj09LDfn0WvTu9LvRxUqF2Y7RoWA3HwbVCkddqdbpzu/lh g9Cg== X-Gm-Message-State: AOAM531wO1rb1qJhoxNzPMkOYjC0m0gNdzFl43hHqFfW09d3BZcNoH6x Ixng8+FmEdsOzp/NE+R/8lK1tHzF69QYGvMGjzCf5fgJNcpAew== X-Google-Smtp-Source: ABdhPJxzh0Zb0Nux3f2gz0cdh0pFdmncuMubQc2aD60/G5zIhcfwbELlmAPGN453ktwZC25dCFYcajmc0cRx9LSnuEA= X-Received: by 2002:aa7:d5c6:: with SMTP id d6mr6020346eds.290.1622831091631; Fri, 04 Jun 2021 11:24:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Shi Date: Fri, 4 Jun 2021 11:24:38 -0700 Message-ID: Subject: Re: [PATCH 2/7] mm/thp: try_to_unmap() use TTU_SYNC for safe DEBUG_VM splitting To: Hugh Dickins Cc: 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 Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=AZOMP7Rw; spf=pass (imf19.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam03 X-Stat-Signature: 91xc6curpo7xdyhdj9cne81s7ji74438 X-Rspamd-Queue-Id: EC07A9001ECD X-HE-Tag: 1622833000-551561 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, Jun 3, 2021 at 7:45 PM Hugh Dickins wrote: > > 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. Sorry for not marking it for stable. I do have no any objection to having it in stable, just forgot to cc 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. Understood. > > 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). The point is if we just close the race for DEBUG_VM case, it doesn't sound worth it to me IMHO. How's about making it for !DEBUG_VM anyway? How big the overhead could be? It looks like the heavy lifting (tlb shootdown and page free) is done after pmd lock is released so it should not block pvmw for a long time. > > 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