Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp601271pxf; Wed, 10 Mar 2021 12:53:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOk3QcCYrFgUKIMN0NDMkiXMf22v3VS9jefEt056lSjQ9VHB2wpkgvhIoknjYe5x0PSYKo X-Received: by 2002:a50:fa42:: with SMTP id c2mr5374904edq.159.1615409618374; Wed, 10 Mar 2021 12:53:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615409618; cv=none; d=google.com; s=arc-20160816; b=ZwXVAL1GD6uSpCe9hxwZH/yq66FU0duKWOOekG+DNoZbG6IjYWcPwJioutsBKs+XDG 7uplicjqek4dpNxfSmPBDk65UfBjqk5KhHEWnYsjKS/0e/XYyH1U0KkyUODWhVuHoLV9 7C+Q9fGP8JCzebSITCp9a9MINOwsOMb/WcCtRaDKnyMfXth54fh/1gq080YZImCYPMeb O1wqKjRK+TyLcc4EPC/SYedKzZFYE1lRprnU/xhq0UjZUmWIw22fz7g9SdO0/iGIu1XX ii7EVyS04UMWvA/QzdU5SK2HnM3GpmpRBQ72DdlM+vq4Q2zeUYYOSKTxggvuwDm5onef ewSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JWX2XsnTn8graQVlcrlC1EbFZiSvSCEfgw7Lk+5BMgk=; b=i+s4llFNzK98pgOnNaUCiLCwkXUAVYDeM3mTvlt6vLPV/dz/AyaUhnQrbmFVjudkfT obwoQJ7THBPZRA3Kl44J1YWNVpMovCfo35b33lTgBJUdQ/sm08ImqkZPin4B61lzKaT8 8jbiJU/aEtDovFDNPz1RJQ03/KYJ04iD641gjYuxA+/SLAgDWCrfUOG7dJSnIEGHhdTq gvOwJkVBthf3v2cP+oir0zr5+EYswMVJxHq4ihF7SC1QkY3feAKahQQiKDxxdmuinupe K7+BtJKD1Y1aagxQNY6IbYGYhIt9neE35aCiLwDPj9f/NBgzGWPtXm8l12yTQmbur5p7 YhNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PQhX5z72; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rh9si314609ejb.341.2021.03.10.12.53.15; Wed, 10 Mar 2021 12:53:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PQhX5z72; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231400AbhCJUtY (ORCPT + 99 others); Wed, 10 Mar 2021 15:49:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:59072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230491AbhCJUtX (ORCPT ); Wed, 10 Mar 2021 15:49:23 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 208F664FC6; Wed, 10 Mar 2021 20:49:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615409362; bh=8Lubpt2RtIi1IKD8AnfhhcFsPyM8ZlZWqojFGL66AEo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PQhX5z72m4tWNc1wPcJL4+eNCCqDixQzxar0vIqh+ktQmQmEMsYW2KARrqaR/sQz4 xpu0uPizxIRDEbDLwNJkkihaImSz+OqHzM6htvp4AHC9W4ll/3jEg2WbWoZ4tyAOl7 XkRO6Dg4iZygdESiVlzkh5G4V3li+h3I0Uc84TN4rj3JWGIf9McWsQP4FCfYvLSofw 5I86XkYXRXb76K/gPmswQCXUYxkai7RHD5vZ+HhgNvAVVe3QWJcbOZ2uzdhuntCUMp kAy8FBMwT8QmYbaoMNw70iSw8ElSfrOJ14GwFobOzWND+101iubMUZkqpDuoL4TXua 2uqd9ngJtrxig== Date: Wed, 10 Mar 2021 12:49:20 -0800 From: Jaegeuk Kim To: Huang Jianan Cc: Matthew Wilcox , Weichao Guo , rpalethorpe@suse.de, kernel test robot , lkp@intel.com, Linux Memory Management List , Chao Yu , LKML , lkp@lists.01.org, ltp@lists.linux.it Subject: Re: [LTP] [f2fs] 02eb84b96b: ltp.swapon03.fail Message-ID: References: <20210308072510.GA902@xsang-OptiPlex-9020> <87h7llhnfe.fsf@suse.de> <20210309040144.GH3479805@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/10, Huang Jianan wrote: > Hi Richard, > > On 2021/3/9 12:01, Matthew Wilcox wrote: > > On Tue, Mar 09, 2021 at 10:23:35AM +0800, Weichao Guo wrote: > > > Hi Richard, > > > > > > On 2021/3/8 19:53, Richard Palethorpe wrote: > > > > Hello, > > > > > > > > > kern :err : [ 187.461914] F2FS-fs (sda1): Swapfile does not align to section > > > > > commit 02eb84b96bc1b382dd138bf60724edbefe77b025 > > > > > Author: huangjianan@oppo.com > > > > > Date: Mon Mar 1 12:58:44 2021 +0800 > > > > > f2fs: check if swapfile is section-alligned > > > > > If the swapfile isn't created by pin and fallocate, it can't be > > > > > guaranteed section-aligned, so it may be selected by f2fs gc. When > > > > > gc_pin_file_threshold is reached, the address of swapfile may change, > > > > > but won't be synchronized to swap_extent, so swap will write to wrong > > > > > address, which will cause data corruption. > > > > > Signed-off-by: Huang Jianan > > > > > Signed-off-by: Guo Weichao > > > > > Reviewed-by: Chao Yu > > > > > Signed-off-by: Jaegeuk Kim > > > > The test uses fallocate to preallocate the swap file and writes zeros to > > > > it. I'm not sure what pin refers to? > > > 'pin' refers to pinned file feature in F2FS, the LBA(Logical Block Address) > > > of a file is fixed after pinned. Without this operation before fallocate, > > > the LBA may not align with section(F2FS GC unit), some LBA of the file may > > > be changed by F2FS GC in some extreme cases. > > > > > > For this test case, how about pin the swap file before fallocate for F2FS as > > > following: > > > > > > ioctl(fd, F2FS_IOC_SET_PIN_FILE, true); > > No special ioctl should be needed. f2fs_swap_activate() should pin the > > file, just like it converts inline inodes and disables compression. > > Now f2fs_swap_activate() will pin the file. The problem is that when > f2fs_swap_activate() > > is executed, the file has been created and may not be section-aligned. > > So I think it would be better to consider aligning the swapfile during > f2fs_swap_activate()? Does it make sense to reallocate blocks like in f2fs_swap_activate(), set_inode_flag(inode, FI_PIN_FILE); truncate_pagecache(inode, 0); f2fs_truncate_blocks(inode, 0, true); expand_inode_data();