Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1930306pxy; Thu, 29 Apr 2021 18:51:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwxDIQxF1l9xunqg41/NEvJf/nJqHGkpNsPbypbucrTNiRlq069ygRK3uX61xIneQCHYkn X-Received: by 2002:a17:902:e8ca:b029:ec:bec2:ba6b with SMTP id v10-20020a170902e8cab02900ecbec2ba6bmr2913765plg.42.1619747478953; Thu, 29 Apr 2021 18:51:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619747478; cv=none; d=google.com; s=arc-20160816; b=j3guECCGv2vyc2TMSvzqmk5JKqaNIWF0Hotzv+zMpgFPzkjfmcYTsnDKlanuLSpIgX 6X4Gst+jaAreMCGnxtY9B748KZ/HM4y5HBRDkBYrWYG6kN04OhF7mg2wj4+6dVehL/BP NLNy6zGJDoEHhWnSmRu3Kxl5LKLWkJHE4TCtiXU+wkL+TlNI3H7s+fUX0x0VYgODqByk 2/miaGhfCzb1DYqs1wAYWqbe4ZCuiRDv8fJ0icejyc778gUiryH22cWKk9CBOdEtRe6j RF16GpoiZuRnxWFNMtBKtQGVZ7a/3ubL2HVNtAcq1/Y1yoDosD2LiRDUMAfX3hWXGs0n aWDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=jGLqREpT4ly4I8j7ohT2vmzdTBJB4hc8QwvnrL3HXgs=; b=vhSqHXJ6AYcRIAipdSFqjoIhkUZUBY0q+0TnjFb3I2YsvMPj10uOQuToWT8d3FCq/g kSSRKVHmqLe7YBuLcuAeK49lPag+IcWelKQZmtSf6HDPWr+tHXo55aMumQE2Un+5HXT6 HcFQD+GxUZxzEsr7mjrsKPQFoJqpLuLJazFrY1h45ckfDiG2G6itZ3V2EdQAmKuofkhE leT7r7a+caCoLH5NwYnaYUjFcok6cETslZ6a+XBxfLwAaPaOnbRy46U6qBv7YJ6uTAPD mNZrSx8JaDWx7yoRg8U+qcc0NQg1ZcxiJjY25jxoS5EnvYkUPsSLrvvyMX6MZ66Fu62d gC2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eVOOZh0e; 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 y5si1737782pll.69.2021.04.29.18.51.06; Thu, 29 Apr 2021 18:51:18 -0700 (PDT) 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=eVOOZh0e; 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 S230036AbhD3Bt1 (ORCPT + 99 others); Thu, 29 Apr 2021 21:49:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:40910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbhD3Bt0 (ORCPT ); Thu, 29 Apr 2021 21:49:26 -0400 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(); > > > . > > >