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 1E27EC4332F for ; Mon, 5 Dec 2022 00:45:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DCA18E0002; Sun, 4 Dec 2022 19:45:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78CFA8E0001; Sun, 4 Dec 2022 19:45:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62DD28E0002; Sun, 4 Dec 2022 19:45:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 500238E0001 for ; Sun, 4 Dec 2022 19:45:49 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EB4501A040E for ; Mon, 5 Dec 2022 00:45:48 +0000 (UTC) X-FDA: 80206409976.23.9B3C2E9 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by imf24.hostedemail.com (Postfix) with ESMTP id 890FD18000F for ; Mon, 5 Dec 2022 00:45:48 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bZ8SjeMi; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.167.175 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670201148; 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=VtvsCQ8fHRhk6x8VToDSbomE5ZMa9LavMZLQcaqpC9Y=; b=w9a0t1WzIdkuKO4WrGttLkuE9afbmgB3QTcxwQhc9j4Xjp0U3DdfigEmvdq735h0gMuUfd sw2ih6pUOC2YTWYFeEqGLH6GfnarLR+KdgjsPd3gUO2iklVnV62qoRA2HVUjztLLfTuR2z PwC3KU8FCi58x5zTsoonI3hOqzX4Ffo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bZ8SjeMi; spf=pass (imf24.hostedemail.com: domain of hughd@google.com designates 209.85.167.175 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670201148; a=rsa-sha256; cv=none; b=1MfBU4HFtiGmjXaAlKIkzo8D+46LoknyuX7AjzyAgjkS7xW87Bae6/xZAevErvOXscJhSF cStf3uDomTJPxVQwvIFF32CvP7MrrfUkOhpVUDen5aiozvO+WhmXHBqfVi+R9TqmVNyZaF slFTiY8UzFFScbCs02y1X8V5ux1egjo= Received: by mail-oi1-f175.google.com with SMTP id s187so5153485oie.10 for ; Sun, 04 Dec 2022 16:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=VtvsCQ8fHRhk6x8VToDSbomE5ZMa9LavMZLQcaqpC9Y=; b=bZ8SjeMi3/UczyDxZXS7zVDxJajNbrzIoW0OlW8hH6g6BQw0jcAMSTmLGSEHhHDiCS /4rq6dAIDr8K8g8vcV6Y6IuidDyFDrjbhbEh9b6l7zdCHlgjoSgwACQDLQL3/raCnx4i ttFJTLiEFLut+8z4PZlHT0N30YZx1QgZkLMg64vEe2ryC9m9byJbIQIOWvRuuGITzDfN RKdmZTkMVM48o5P/Zr1knzzNTD91AcgmrRXsTxzRsK+/MtnUn8UcwN3UvFRDTKU11VOw hZCzwjjr3k8ISOn9gGwoggI+Wo5yGvvGlPe+xSRUMpEOZEJAaa/S2SXzTH6DdcY79G1x 035g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VtvsCQ8fHRhk6x8VToDSbomE5ZMa9LavMZLQcaqpC9Y=; b=2VAcNFs/vxXA9fdmj1tlJnYZOQ4V7UYOL02vzh7dnUg7BZaZKzNniD8MDGdN69UZvc P9iNHo4A8QhvQuW8Jno/oAFp+UcY6ldQQolL4Ps4PwxkSG1c+OFcPwgpt1zJRZl2CJ8E OwZRy9FFHVAGy0grkowwzcMQkmuHi4O3fJXH+vOnfBg0poOYptw4x1cLNiDQlXl563iV VMvC80uTTy31SwHAMPDxRX9h/Nc3bXzhJiPxQcG/0d1CTu949BwfdFSSGMQ9UhhvCx5J pL5HBoK0OUvoZ4EfjaTBw0NGajFPiK/KIkq0HGfv6zrj2S35aAoH5+Rs7S4gl4u7d/5z 85HQ== X-Gm-Message-State: ANoB5plUvJXTD070qkuhOKOfUJ7WRsomDol4dNixEmX2sJ78MWTiDFTl jviN3TZCu+IOFA3gbIHaRKK8tw== X-Google-Smtp-Source: AA0mqf7jfsaE4Kcw/T3BQzMPBJ+a/VF4WDpQhaEAUCRLq4MFCxgGrjEvAi3xJNByIZnjCSXdF9+EBg== X-Received: by 2002:a05:6808:149:b0:35b:b8d6:32c5 with SMTP id h9-20020a056808014900b0035bb8d632c5mr15921488oie.226.1670201147592; Sun, 04 Dec 2022 16:45:47 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id e9-20020a4ae0c9000000b004a05e943f9esm1141017oot.21.2022.12.04.16.45.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Dec 2022 16:45:47 -0800 (PST) Date: Sun, 4 Dec 2022 16:45:35 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Rui Wang cc: Andrew Morton , Matthew Wilcox , Guoqi Chen , Huacai Chen , Rui Wang , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH] mm/shmem: Fix undo range for failed fallocate In-Reply-To: <9984f58e-826-74c6-1cd4-65366cc01549@google.com> Message-ID: <5889e4e3-e054-7654-1436-8d2bcbefe3c6@google.com> References: <20221101032248.819360-1-kernel@hev.cc> <9984f58e-826-74c6-1cd4-65366cc01549@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 890FD18000F X-Rspam-User: X-Stat-Signature: k363xj3s1fjapmxzrbpbmr4tqubp87ce X-Spamd-Result: default: False [-2.90 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SORBS_IRL_BL(3.00)[209.85.167.175:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; BAD_REP_POLICIES(0.10)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[8]; DMARC_POLICY_ALLOW(0.00)[google.com,reject]; DKIM_TRACE(0.00)[google.com:+]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17]; RCVD_COUNT_THREE(0.00)[3]; R_DKIM_ALLOW(0.00)[google.com:s=20210112]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; RCVD_VIA_SMTP_AUTH(0.00)[] X-HE-Tag: 1670201148-334426 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 Tue, 22 Nov 2022, Hugh Dickins wrote: > On Thu, 3 Nov 2022, hev wrote: > > 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") > > Like Matthew, I was sceptical at first. > > But I currently think that you have discovered something important, and > that your patch is the correct fix to it; but I'm still rather confused, > and want to do some more thinking and testing: this mail is mainly to > signal to Matthew that I'm on it, so he doesn't have to rush to look > at it when he's back. > > I was able to reproduce it with the test case, once I multiplied both > of the usleep intervals by 10 - before that, it was too difficult for > it to complete a fallocate: guess the timing is different on my x86 box. Thanks, I needed that breathing space to get back to thinking it through. My main concern was, how did Matthew and I come to miss this unfalloc issue when the folio commit went in? Speaking for myself (but quite likely for Matthew too), it's because there was never a need for special unfalloc treatment in the partial page handling there before, so we didn't even think of adding any when that got updated. But when the partial page handling got turned into partial folio handling, it came to do a lot more than before: it's tricky stuff, and Matthew intentionally moved all the difficulty there into the partial folio block; whereas before it had been just as tricky, but hidden away in the shmem_punch_compound() call from inside the loop which follows. And was subject there to the unfalloc exception. So that sort of satisfied me, how we came to overlook it. Your patch worked for me, and until yesterday I was intending to send it in as is. But then realized that, although it's a peculiar exception to the standard processing there, unfalloc actually has a much simpler job to do: just remove any !uptodate folios from the range. It has no need whatsoever for the zeroing and splitting involved in truncate_inode_partial_folio(), and I really wanted to avoid having to think through all that again - easier just to skip it all. So the patch I'm about to send to Andrew is not quite yours: but many thanks to you and to Guoqi Chen for revealing this issue. Hugh