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 1DAADC4332F for ; Thu, 3 Nov 2022 07:52:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F79E8E0002; Thu, 3 Nov 2022 03:52:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A81E8E0001; Thu, 3 Nov 2022 03:52:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 871D88E0002; Thu, 3 Nov 2022 03:52:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 775DE8E0001 for ; Thu, 3 Nov 2022 03:52:55 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 50E31405D4 for ; Thu, 3 Nov 2022 07:52:55 +0000 (UTC) X-FDA: 80091364710.03.1F85B58 Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by imf02.hostedemail.com (Postfix) with ESMTP id DC27280003 for ; Thu, 3 Nov 2022 07:52:54 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id z9so652113ilu.10 for ; Thu, 03 Nov 2022 00:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hev-cc.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u0qpy1xXrx+Jm1tVFqhypX7wcmKSsRnIhOx4LBDIUWc=; b=F9K3CJ3FvP98ElCjXMu4zTo3a0qxs1YGeTWeyfW6LZiwCXIMplCpHom2O8jSZ58Z5O r72omjs/MwV75QE4eo5wEFoaVQUIkor05WXtU6G+mpPrBOeMvdoaGhNH7hvse3s84fMK 8MezfAXEzfvcaKUdDl8GiIMxscuLHOHsEF5fY+TTBtgG05EuOdxnV0GXeXI0w9jXYeTt DkBizOxedrg5fahv/PHRS/y94m+hS4WHL/LmpAUT71wpiLje23wG6gbrLAYbJCceQDHb 8gO+DrUNlZw9M3QgxQzxo4syNKOcuMu5wHtj2if3//0PXyZwOsX0utxS3t/CfFXR3zOG oOGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=u0qpy1xXrx+Jm1tVFqhypX7wcmKSsRnIhOx4LBDIUWc=; b=SWOTEkCDs4+eSLAiBMoM5FIC6nf261KNb1VAuWkbsJz/3GKO6GoC9viN6eVzwqLDzH CUszUc0Lk50Kw75Fn6c95nNFv/tImDbvqw2P/cXjwfX3Ds/+FLsxx0ljeqXi+tcRM7+e FbLzLDMAgZ9k1AMZkPNH21jcI6x4jpOWrD/eU/4B82+SOFfnTSNYIMXxnJSH/ThoFxsP 6by15GqDYX6j8qnJlXVvhDd+LUb6nImVPZu+e0/INUn81Yvi/5evpAi9edeC9ItQ3Ncb Nu/Xgc5RYVnIfvW8tqnaSfptWUtpM97tH2NjbfPbdwTl77bOgoWJcCqjEPGtGNdhMhuy m5aQ== X-Gm-Message-State: ACrzQf3nm7Scd3++unQP6jxQimt8KfDdwxtT8pbgWvD7UUT1VMi5ncy+ RAdDVlxJxqgN0WNsDVhnuZeca+nRanIr3OX16LhWRw== X-Google-Smtp-Source: AMsMyM6HJ1FM+MmBXQmhNZz51l/upEyoMbnh6stLHorO4ikEPO28lSGsaKD8SdLASBOVTPs/1hbKrp77XOaAuBkORhg= X-Received: by 2002:a05:6e02:1ba3:b0:2fa:3547:477a with SMTP id n3-20020a056e021ba300b002fa3547477amr18537627ili.34.1667461973783; Thu, 03 Nov 2022 00:52:53 -0700 (PDT) MIME-Version: 1.0 References: <20221101032248.819360-1-kernel@hev.cc> In-Reply-To: From: hev Date: Thu, 3 Nov 2022 15:52:43 +0800 Message-ID: Subject: Re: [RFC PATCH] mm/shmem: Fix undo range for failed fallocate To: Matthew Wilcox Cc: linux-mm@kvack.org, Guoqi , Huacai Chen , Rui Wang Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=hev-cc.20210112.gappssmtp.com header.s=20210112 header.b=F9K3CJ3F; spf=pass (imf02.hostedemail.com: domain of r@hev.cc designates 209.85.166.181 as permitted sender) smtp.mailfrom=r@hev.cc; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667461975; a=rsa-sha256; cv=none; b=QRTtAAdNAPv8V+xPLB9ew9YryPJmRZ6QFzn5WfRP2uOh73TzLcSbUi4EqxWg5d38RkBqv5 9icL/ECcMmvJiT1lOFVg7ewwBkNE2oSBDBDHhTPqM3N7RcUqST0UyctPLnY7rwLr2HGON9 Kkf4LvdlAM7y6FGdbyNTAHSGZQjkyI8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667461975; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=u0qpy1xXrx+Jm1tVFqhypX7wcmKSsRnIhOx4LBDIUWc=; b=hMGRnKEVJsNyI0WaRpHs0wyqhG92oaP8p1zPul+rJ1PfN1QWK/9iTmCgqlUVsa1rLDi9iu MMr+2JXACoYqtZUpU0mmfP4crepmD5Iz0P2yKTryIa+PJZdQRz0VR5hMQwkEFQ3qOmO88r C5rYpe0X12yMGVP/AN7tPOy/XwpRDEE= X-Stat-Signature: prjnziuubkwyjo94s9h7k1if14hsi6q3 X-Rspamd-Queue-Id: DC27280003 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=hev-cc.20210112.gappssmtp.com header.s=20210112 header.b=F9K3CJ3F; spf=pass (imf02.hostedemail.com: domain of r@hev.cc designates 209.85.166.181 as permitted sender) smtp.mailfrom=r@hev.cc; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1667461974-678253 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: Hi Matthew, On Wed, Nov 2, 2022 at 10:41 PM Matthew Wilcox wrote: > > On Tue, Nov 01, 2022 at 11:22:48AM +0800, Rui Wang wrote: > > This patch fixes data loss caused by the fallocate system > > call interrupted by a signal. > > > > Bug: https://lore.kernel.org/linux-mm/33b85d82.7764.1842e9ab207.Coremail.chenguoqic@163.com/ > > Fixes: b9a8a4195c7d ("truncate,shmem: Handle truncates that split large folios") > > How does that commit introduce this bug? In the test case[1], we created a file that contains non-zero data from offset 0 to A-1. and a process try to expand this file by fallocate(fd, 0, 0, B), B > A. Concurrently, another process try to interrupt this fallocate syscall by a signal. I think the expected results are: 1. The file is not expanded and file size is A, and the data from offset 0 to A-1 is not changed. 2. The file is expanded and the data from offset 0 to A-1 is not changed, and from A to B-1 contains zeros. Now, the unexpected result is that the file is not expanded and the data that from offset 0 to A-1 is changed by truncate_inode_partial_folio that called from shmem_undo_range with unfalloc = true. This issue is only reproduced when file on tmpfs, and begin from this commit: b9a8a4195c7d ("truncate,shmem: Handle truncates that split large folios") > > > Reported-by: Guoqi Chen > > Cc: Huacai Chen > > Signed-off-by: Rui Wang > > --- > > mm/shmem.c | 20 ++++++++++++-------- > > 1 file changed, 12 insertions(+), 8 deletions(-) > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > index bc9b84602eec..8c8dce34eafc 100644 > > --- a/mm/shmem.c > > +++ b/mm/shmem.c > > @@ -948,11 +948,13 @@ static void shmem_undo_range(struct inode *inode, loff_t lstart, loff_t lend, > > folio = shmem_get_partial_folio(inode, lstart >> PAGE_SHIFT); > > if (folio) { > > same_folio = lend < folio_pos(folio) + folio_size(folio); > > - folio_mark_dirty(folio); > > - if (!truncate_inode_partial_folio(folio, lstart, lend)) { > > - start = folio->index + folio_nr_pages(folio); > > - if (same_folio) > > - end = folio->index; > > + if (!unfalloc || !folio_test_uptodate(folio)) { > > + folio_mark_dirty(folio); > > + if (!truncate_inode_partial_folio(folio, lstart, lend)) { > > + start = folio->index + folio_nr_pages(folio); > > + if (same_folio) > > + end = folio->index; > > + } > > ... so what you're saying is that if we allocate a page, but zeroing > it is interrupted by a signal, we cannot now remove that page from > the cache? That seems wrong. > > Surely the right solution is to remove this page from the cache if we're > interrupted by a signal. So I think we should not truncate_inode_partial_folio for unfalloc = true. Isn't that right? [1] https://github.com/abner-chenc/abner/blob/master/fallocate.c Regards, Ray