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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C2E6C433EF for ; Thu, 10 Mar 2022 00:59:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D19D08D0002; Wed, 9 Mar 2022 19:59:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC8CF8D0001; Wed, 9 Mar 2022 19:59:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B91A38D0002; Wed, 9 Mar 2022 19:59:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id AA7E58D0001 for ; Wed, 9 Mar 2022 19:59:14 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6F2025BE for ; Thu, 10 Mar 2022 00:59:14 +0000 (UTC) X-FDA: 79226667828.09.9DB79F5 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf25.hostedemail.com (Postfix) with ESMTP id F15F3A000E for ; Thu, 10 Mar 2022 00:59:13 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id mg21-20020a17090b371500b001bef9e4657cso6902850pjb.0 for ; Wed, 09 Mar 2022 16:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NQaSIZIxO5KOdOicjkb1cFrwib5bGbIpCqk65gAppCI=; b=VS2xx8r9PIGwCLa64CuDfWCjlfdzMZcrNjPDuGSm77clH/PVMaEZN2pFx9+sRO7bqW NT6d5L8XGp5XpSuR6KuMouThtrdyDHbkITw+k9eisuQJylQgdSTzNjL6hXN+HdOsOAiQ cpFH7NrpzwaP8f7q7dqp322hrR0wM5RwN+VGHbpilCz8ADGA8IPs2ZX55ZR+0G7xPGsC CSwwKUf//3X1p7hREN0WgucPZ5yZc7YRbwvGPR1udtiTEZJao3XE/m/Hn1NBh7rCglRm fbhq4iAW9AUvr0m7gEOlYSgkuwWgsA4XYTxNaspmnJFzTOItrpijpGdy7OsrHpvYytSU Da9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NQaSIZIxO5KOdOicjkb1cFrwib5bGbIpCqk65gAppCI=; b=GvKMM7cs80UeOkBXbfUNyUodLlLJGTdDm7rMIinX50/MeI8TxPXRqMIplkDD2OmgHK k0nQAfYzTnForF2UF11EFJGmo162AN2ixyybdk/4evwIlwqRi1TdhhQV2GMEpbqxQ+aA 09vCdu2E3Jo5NOrlMq1EQLwU+mX7lA0aJCh53tM1xM2N+8bP9o8lH+SNtOOpY67pYr6z snKWZcjm3p7fd+0aqvv6DVeMMPb/j2z5Dm6WyOD6+8MQMireM7Jfm+rcOMXP7Rvs8uzz onIwTegP89/FC+asnYqvnTO3dg6sDeFKO87IyESX3Pt9Twe5tzzg9taMXFe32ribpX2E nTqA== X-Gm-Message-State: AOAM532Ht3TIJzeGs2vpNtHAoJeGigizQqgvuJk6OSfcrDszc4SMYshN vlZNGZOuuxYpKkucq8g3KGOohLe+DZzYpoXpE35rAg== X-Google-Smtp-Source: ABdhPJw96a/Eq6dU3OeebKd8y0NUTDNVyL9MKec/ynBgpi4ejJZav6ILrpB7Vds7D2x6nUx/OKPBrD3KR+tlbTRAg84= X-Received: by 2002:a17:902:7296:b0:14b:4bc6:e81 with SMTP id d22-20020a170902729600b0014b4bc60e81mr2486890pll.132.1646873952956; Wed, 09 Mar 2022 16:59:12 -0800 (PST) MIME-Version: 1.0 References: <20220302082718.32268-1-songmuchun@bytedance.com> <20220302082718.32268-6-songmuchun@bytedance.com> In-Reply-To: <20220302082718.32268-6-songmuchun@bytedance.com> From: Dan Williams Date: Wed, 9 Mar 2022 16:59:02 -0800 Message-ID: Subject: Re: [PATCH v4 5/6] dax: fix missing writeprotect the pte entry To: Muchun Song Cc: Matthew Wilcox , Jan Kara , Al Viro , Andrew Morton , Alistair Popple , Yang Shi , Ralph Campbell , Hugh Dickins , xiyuyang19@fudan.edu.cn, "Kirill A. Shutemov" , Ross Zwisler , Christoph Hellwig , linux-fsdevel , Linux NVDIMM , Linux Kernel Mailing List , Linux MM , duanxiongchun@bytedance.com, Muchun Song Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: F15F3A000E X-Stat-Signature: 681eyz6kzkx1q13y1e7krfh5nmm5kjxi Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=VS2xx8r9; spf=none (imf25.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.216.48) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646873953-395001 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, Mar 2, 2022 at 12:30 AM Muchun Song wrote: > > Currently dax_mapping_entry_mkclean() fails to clean and write protect > the pte entry within a DAX PMD entry during an *sync operation. This > can result in data loss in the following sequence: > > 1) process A mmap write to DAX PMD, dirtying PMD radix tree entry and > making the pmd entry dirty and writeable. > 2) process B mmap with the @offset (e.g. 4K) and @length (e.g. 4K) > write to the same file, dirtying PMD radix tree entry (already > done in 1)) and making the pte entry dirty and writeable. > 3) fsync, flushing out PMD data and cleaning the radix tree entry. We > currently fail to mark the pte entry as clean and write protected > since the vma of process B is not covered in dax_entry_mkclean(). > 4) process B writes to the pte. These don't cause any page faults since > the pte entry is dirty and writeable. The radix tree entry remains > clean. > 5) fsync, which fails to flush the dirty PMD data because the radix tree > entry was clean. > 6) crash - dirty data that should have been fsync'd as part of 5) could > still have been in the processor cache, and is lost. Excellent description. > > Just to use pfn_mkclean_range() to clean the pfns to fix this issue. So the original motivation for CONFIG_FS_DAX_LIMITED was for archs that do not have spare PTE bits to indicate pmd_devmap(). So this fix can only work in the CONFIG_FS_DAX_LIMITED=n case and in that case it seems you can use the current page_mkclean_one(), right? So perhaps the fix is to skip patch 3, keep patch 4 and make this patch use page_mkclean_one() along with this: diff --git a/fs/Kconfig b/fs/Kconfig index 7a2b11c0b803..42108adb7a78 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -83,6 +83,7 @@ config FS_DAX_PMD depends on FS_DAX depends on ZONE_DEVICE depends on TRANSPARENT_HUGEPAGE + depends on !FS_DAX_LIMITED # Selected by DAX drivers that do not expect filesystem DAX to support # get_user_pages() of DAX mappings. I.e. "limited" indicates no support ...to preclude the pmd conflict in that case?