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 8D8C8C433F5 for ; Fri, 1 Oct 2021 21:08:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 22ADA61ACE for ; Fri, 1 Oct 2021 21:08:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 22ADA61ACE 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 BCBE694014B; Fri, 1 Oct 2021 17:08:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B7AE0940121; Fri, 1 Oct 2021 17:08:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6A1C94014B; Fri, 1 Oct 2021 17:08:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id 964F5940121 for ; Fri, 1 Oct 2021 17:08:55 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 638263A8F6 for ; Fri, 1 Oct 2021 21:08:55 +0000 (UTC) X-FDA: 78649108230.14.B9B6F4F Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf23.hostedemail.com (Postfix) with ESMTP id 27814900039C for ; Fri, 1 Oct 2021 21:08:55 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id x7so37906028edd.6 for ; Fri, 01 Oct 2021 14:08:54 -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=FXIGOwidwYWPojVj+QkQOP2rlviWSjFjrreCUlP7Pc4=; b=DxgSh1ywafLUskHGUCY9KcouyOj20cLCVdIUANPokB/UJC629Q5OP0LmBXsf3uEWaa taNAV1tnZ4MCrsdLuUrL58eTdgoN7HwZHRSR+EokiAvOrTujS6C+XGakU1Ar8C8Et2Kh GNZXlxVeHvhxDqB3W9Ol71t2gUQyVdCuloV3xjCysgfVNjH4TM/xBiyBhKiYMOrsQQBT 3RiL4AIP5abLsmJd0fe8TKWLqcu/MD6Cn6jEGyGn+hopXMPHYg86JzTnsKzpbnKFrFSf oMGYuZGaP+Iz57c2wEUUsmDdCJ+jy2nZQUacD+mE/69ItZP6GqeOIkRE6ZfYXc3xlyKX rE+w== 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=FXIGOwidwYWPojVj+QkQOP2rlviWSjFjrreCUlP7Pc4=; b=wvHXTV9576nmdW7ZeVQw1SBKX+U1EG06WIMcMQqtlzegeW0tRJCqBKaGVqNo6Elelc ngR4TeQHYhxhZf8WtzmT4ymzJ38Fmyge5AIoF/UBGAJ1dnFNkDYeIp70mlPc6uGqBBev rkkBm6lQUe3JM7JCjrioCp684oOxUkpXRC9UPwbYvubmvUWf05vjrVgVGkHumrPnjCho J1ca76CuKKSrr73byaipipQ/m6PLM08jBpUnqC3PfEIOykBGDQYkFTY2/GiFcjcbzRmx B6jRANhYMacfY3cLuQZ5aT5Cc1eGpY1GiqZSEGN60txiX9ovoURV5lDwbhQiIJNdcrDP D99w== X-Gm-Message-State: AOAM530LKiP6iwdVvfbj0E4H+A5mekPEubGjlL00V4QARVGiHTaDokbm 5B2YE/RbENmzACqc8QFbJ7fboWpO7731r7h+jnc= X-Google-Smtp-Source: ABdhPJxNFruDUCogGSg8fAf4b1g6IqqCSmdf6Zz4PLYW/+LeRqbefG2WuhyXJmvtQctIoPkS6ygWiqwEHAdtUZuPXLY= X-Received: by 2002:a50:e044:: with SMTP id g4mr337701edl.46.1633122534073; Fri, 01 Oct 2021 14:08:54 -0700 (PDT) MIME-Version: 1.0 References: <20210930215311.240774-1-shy828301@gmail.com> <20210930215311.240774-5-shy828301@gmail.com> <20211001070539.GA1364952@u2004> In-Reply-To: <20211001070539.GA1364952@u2004> From: Yang Shi Date: Fri, 1 Oct 2021 14:08:41 -0700 Message-ID: Subject: Re: [v3 PATCH 4/5] mm: shmem: don't truncate page if memory failure happens To: Naoya Horiguchi Cc: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Peter Xu , Oscar Salvador , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 27814900039C X-Stat-Signature: b9a1cmbangke67ffb4qandnc6ss6chid Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=DxgSh1yw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.43 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-HE-Tag: 1633122535-445723 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 1, 2021 at 12:05 AM Naoya Horiguchi wrote: > > On Thu, Sep 30, 2021 at 02:53:10PM -0700, Yang Shi wrote: > > The current behavior of memory failure is to truncate the page cache > > regardless of dirty or clean. If the page is dirty the later access > > will get the obsolete data from disk without any notification to the > > users. This may cause silent data loss. It is even worse for shmem > > since shmem is in-memory filesystem, truncating page cache means > > discarding data blocks. The later read would return all zero. > > > > The right approach is to keep the corrupted page in page cache, any > > later access would return error for syscalls or SIGBUS for page fault, > > until the file is truncated, hole punched or removed. The regular > > storage backed filesystems would be more complicated so this patch > > is focused on shmem. This also unblock the support for soft > > offlining shmem THP. > > > > Signed-off-by: Yang Shi > > --- > ... > > @@ -894,6 +896,12 @@ static int me_pagecache_clean(struct page_state *ps, struct page *p) > > goto out; > > } > > > > + /* > > + * The shmem page is kept in page cache instead of truncating > > + * so need decrement the refcount from page cache. > > + */ > > This comment seems to me confusing because no refcount is decremented here. > What the variable dec tries to do is to give the expected value of the > refcount of the error page after successfull erorr handling, which differs > according to the page state before error handling, so dec adjusts it. > > How about the below? > > + /* > + * The shmem page is kept in page cache instead of truncating > + * so is expected to have an extra refcount after error-handling. > + */ Thanks for the suggestion, yes, it seems better. > > > + dec = shmem_mapping(mapping); > > + > > /* > > * Truncation is a bit tricky. Enable it per file system for now. > > * > ... > > @@ -2466,7 +2467,17 @@ shmem_write_begin(struct file *file, struct address_space *mapping, > > return -EPERM; > > } > > > > - return shmem_getpage(inode, index, pagep, SGP_WRITE); > > + ret = shmem_getpage(inode, index, pagep, SGP_WRITE); > > + > > + if (*pagep) { > > + if (PageHWPoison(*pagep)) { > > Unless you plan to add some code in the near future, how about merging > these two if sentences? > > if (*pagep && PageHWPoison(*pagep)) { Sure. > > Thanks, > Naoya Horiguchi > > > + unlock_page(*pagep); > > + put_page(*pagep); > > + ret = -EIO; > > + } > > + } > > + > > + return ret; > > } > > > > static int