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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36EE0C433F5 for ; Fri, 15 Oct 2021 21:48:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CEAB66108E for ; Fri, 15 Oct 2021 21:48:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CEAB66108E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 45DDF6B007B; Fri, 15 Oct 2021 17:48:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E57E6B007D; Fri, 15 Oct 2021 17:48:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2ACC6900002; Fri, 15 Oct 2021 17:48:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 191026B007B for ; Fri, 15 Oct 2021 17:48:28 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BF0F4180219D6 for ; Fri, 15 Oct 2021 21:48:27 +0000 (UTC) X-FDA: 78700011054.38.018C78B Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf01.hostedemail.com (Postfix) with ESMTP id 5400950F281C for ; Fri, 15 Oct 2021 21:48:25 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id y30so25553038edi.0 for ; Fri, 15 Oct 2021 14:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fy8JX1MISO+E6iiO8M4K0L0jBN1ZBpTt5D/TgO1B54U=; b=U7+cTP+WOIeSHVdUukK9i8mAbLqOyx+qsv7LKqyA1d9LnYKxTxqGp1qFfzQBmZyub+ 2WS2AsPbS3Bzn0j4xDW2BZBmYT14PRpRBy200SYYKaHLTLw5c++3nj7sinEL6J2+v0Zr rwP3kfkTJquHOTMXOuyjwxtkES4zGr5M9wjHJJZ1J7bAr3qG12JioOORDjt/yCPNKI2e LCBig775MW/n7T7ugT5XMIRgbePHsJppd0XpLXu8CRjlyDYyls5yD3jDl1bWo+cVwgwE tK3WeidHc6CVSXMf6j/+gPQKKU8wM75aPxRVHInezczSE8WO1B73zapsU87whFU0gn35 Xgcw== 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=Fy8JX1MISO+E6iiO8M4K0L0jBN1ZBpTt5D/TgO1B54U=; b=Hqk8wRNp/CqxdTjci+NvPuALalPGkXBUz3AlsD37j8HMROWILUoEaUTIzns/baVyrX jN8RAZD1sIMtkgEMzHiGK1ptNftDRFAVqucOlhMbpRGky9tbaTuGsDZ0dICTjMHFHyg8 epulKzq8R69agZuPfADRU8Vuqn2gdVyGOfC4tRCkhTOdvjXm7T1bb5LyM3avrVSPPbfz 7kkH9oWGWJbqtSWfhIr4HHzsFGyIPqzm+1xKKQxNbDmnCEbL6fYuR9GoKjv9jWYz7BCh RWcrPisnW4YWCfWeTulRNl1ChbGR/gbBJYdBXrCNRUbRdSwnvi9a9aSmQLRkqGeu7bDG qYRw== X-Gm-Message-State: AOAM530QxCszIVKExvAzlUrQnlVkZ2XUDD+jAuUk1q8eI9up6YtIE5dq SYS7pMfyVsxdtLJhrppoVlL7wLqwJk04Dx029pU= X-Google-Smtp-Source: ABdhPJxzPoBGmacpktimn0FUL9PLamaLUctIWvwvIPEK4LcwDaz5KhCkQGyMHTGRHT4amHjaBl4V4kjNsLgEvuuxKys= X-Received: by 2002:a17:907:6297:: with SMTP id nd23mr10244354ejc.62.1634334506069; Fri, 15 Oct 2021 14:48:26 -0700 (PDT) MIME-Version: 1.0 References: <20211014191615.6674-1-shy828301@gmail.com> <20211015132800.357d891d0b3ad34adb9c7383@linux-foundation.org> In-Reply-To: <20211015132800.357d891d0b3ad34adb9c7383@linux-foundation.org> From: Yang Shi Date: Fri, 15 Oct 2021 14:48:14 -0700 Message-ID: Subject: Re: [RFC v4 PATCH 0/6] Solve silent data loss caused by poisoned page cache (shmem/tmpfs) To: Andrew Morton Cc: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Peter Xu , Oscar Salvador , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5400950F281C X-Stat-Signature: 5n4tzagjj9hhtmzwebd365n995bt8hp9 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=U7+cTP+W; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-HE-Tag: 1634334505-616712 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 Fri, Oct 15, 2021 at 1:28 PM Andrew Morton wrote: > > On Thu, 14 Oct 2021 12:16:09 -0700 Yang Shi wrote: > > > When discussing the patch that splits page cache THP in order to offline the > > poisoned page, Noaya mentioned there is a bigger problem [1] that prevents this > > from working since the page cache page will be truncated if uncorrectable > > errors happen. By looking this deeper it turns out this approach (truncating > > poisoned page) may incur silent data loss for all non-readonly filesystems if > > the page is dirty. It may be worse for in-memory filesystem, e.g. shmem/tmpfs > > since the data blocks are actually gone. > > > > To solve this problem we could keep the poisoned dirty page in page cache then > > notify the users on any later access, e.g. page fault, read/write, etc. The > > clean page could be truncated as is since they can be reread from disk later on. > > > > The consequence is the filesystems may find poisoned page and manipulate it as > > healthy page since all the filesystems actually don't check if the page is > > poisoned or not in all the relevant paths except page fault. In general, we > > need make the filesystems be aware of poisoned page before we could keep the > > poisoned page in page cache in order to solve the data loss problem. > > Is the "RFC" still accurate, or might it be an accidental leftover? Yeah, I think it can be removed. > > I grabbed this series as-is for some testing, but I do think it wouild > be better if it was delivered as two separate series - one series for > the -stable material and one series for the 5.16-rc1 material. Yeah, the patch 1/6 and patch 2/6 should go to -stable, then the remaining patches are for 5.16-rc1. Thanks for taking them. >