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 X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16435C433B4 for ; Fri, 30 Apr 2021 01:48:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 88CC2613CA for ; Fri, 30 Apr 2021 01:48:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88CC2613CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 149A26B0071; Thu, 29 Apr 2021 21:48:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F84D8D0003; Thu, 29 Apr 2021 21:48:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDB126B0073; Thu, 29 Apr 2021 21:48:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id CCC8C6B0071 for ; Thu, 29 Apr 2021 21:48:40 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 81995180ACC35 for ; Fri, 30 Apr 2021 01:48:40 +0000 (UTC) X-FDA: 78087349200.23.1E69520 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP id B905A90009F1 for ; Fri, 30 Apr 2021 01:48:09 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id EB7AD613D8; Fri, 30 Apr 2021 01:48:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619747319; bh=R+Br+ByigmFx8GICfJM2Z3csLqKD2/XlBGg2xyizbhs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eVOOZh0eukyoXkjzWytUDenxV7bez2Y4Eee3JLk/SP3d3cZkGnsKPlh9c31qRTXGa Xo7p8L7zrFJvJqa4E5yPr/1Q+rW9CxraFPFzKDJL6dqGSdz/3IYI7dg6h2MNH+bKRL lTIwIvg+o+EIYDaru1B4gBy8J6darKe8151Sd3MB/0HNJlZueNjzg0ayIJKoOnTlE/ KNG3P4A+UCmSGtuShws4x1ZAxmn4u8oeq670kUfiTNYryOwc65/0pnRU+o6qKMKWI1 IHdHLaQGXKWJOon49HwGe9EP2cBBpPv/Z0b7yskfG9G0iBXtwzVwe0ykIaRATaJn9b DKlYWvwGZI5dA== Date: Fri, 30 Apr 2021 09:48:23 +0800 From: Gao Xiang To: Weichao Guo Cc: Chao Yu , Jaegeuk Kim , Huang Jianan , Matthew Wilcox , rpalethorpe@suse.de, kernel test robot , lkp@intel.com, Linux Memory Management List , LKML , lkp@lists.01.org, ltp@lists.linux.it Subject: Re: [LTP] [f2fs] 02eb84b96b: ltp.swapon03.fail Message-ID: <20210430014823.GA3132@hsiangkao-HP-ZHAN-66-Pro-G1> References: <20210308072510.GA902@xsang-OptiPlex-9020> <87h7llhnfe.fsf@suse.de> <20210309040144.GH3479805@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: af9ns8fegfaca3oosp5xrw1prb7h7arz X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B905A90009F1 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eVOOZh0e; spf=pass (imf19.hostedemail.com: domain of xiang@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=xiang@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619747289-331807 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 Thu, Apr 29, 2021 at 09:08:42PM +0800, Weichao Guo wrote: > > On 2021/3/23 17:04, Chao Yu wrote: > > On 2021/3/11 4:49, Jaegeuk Kim wrote: > > > 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); > > > > It will corrupt swap header info while relocating whole swapfile... > How about back up the header page, and recover it after expand_inode_data() > ? That sounds somewhat hacky, since I don't think fs should take care of swap detailed format. My premature suggesttion, how about a) for non-pinned files, f2fs_swap_activate() pins the file and move (reallocate) pre-fallocated data blocks if needed; b) for already pinned files and not section-aligned when f2fs_swap_activate(), just reject it. I think it would pass the test since pinned operation is f2fs-specific only. Or am I still missing something? Thanks, Gao Xiang > > > > > expand_inode_data(); > > > . > > >