Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp17146pxy; Tue, 20 Apr 2021 11:26:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQApp5L4S2g15ZIhWUy0FE1a+xMws336CLiIhNchj0CrPuVLMlPbxfM7RmzWHvYHTRft/o X-Received: by 2002:a63:789:: with SMTP id 131mr2199481pgh.297.1618943218780; Tue, 20 Apr 2021 11:26:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618943218; cv=none; d=google.com; s=arc-20160816; b=tbh80e2sQp0vIH/pjPreQvEvKAYgq3Bf8XPrK4/PiWSStWq5GjydNJmqULw+qI2hhf 0moafDwDm93SPiiPdB12j0Cn2fAlLHLB/oVQrrtFUlL+havkddq9s8XYHM4Pz3XuD/gI WYWZzwbGcaNgVuG75in7/IEDy8eT2FFCvWi6I2Sgkdd/ZiEDWcpcIN9k5uc7K404Scwa bgIc5WhP0LZkGvPDUjUqMotZvttn6cpfXONnGRdFxXpHiJG1Z++hYWawT7omqlGth4pH 2MlpV9YFpcEn7HrNPjdGr+ucA2fwgzUch4SR4WNHjBfv+WkIw+5d/2RZAc9kxnzJrFXK j0zA== 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=xzH3Ukv+VsMSFLBfooU973P2thpwN6R+a4UmZE0ALVI=; b=JpRBH3+/a5g5PWI8daQkrXmqyZ2buEgrGOabmYHkBy5AAh+V9FGAagxCu0e/2yJRp0 kA1DxjQMiKLT8YiIQx8nClnHNXsFeP/h48fuOJaH3VN6gooiiY1/ZNEZ5O+GV5mZ+c9Z vGoVgp+jnMbn3vPN+It6CkJs9mIWno43rDZ9A8G4MUW7TUUYkMvJSfFRMotif9N/6Sco BD7+7kjehC5yb+6Q7/h/iv4VJoY54TF4VVZqPccpUJ1MAj9Z3QiUxk0hM+0TSAfHJVQ7 QtyG3xHhg31MKHfqXvi0Q2HghszFBYl4ap9oQ6PskzmJ5M+G/8VVSg5/EqcGA9ROTjJn nfbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=g0sHndMS; 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 o3si22225128pfd.42.2021.04.20.11.26.46; Tue, 20 Apr 2021 11:26:58 -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=g0sHndMS; 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 S233517AbhDTS0o (ORCPT + 99 others); Tue, 20 Apr 2021 14:26:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:55182 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232759AbhDTS0m (ORCPT ); Tue, 20 Apr 2021 14:26:42 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 42F8B613CE; Tue, 20 Apr 2021 18:26:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618943170; bh=c6iMBvteXSLo2ps7WOwHOoMbvk0m6jpJVCFWhxgH69o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g0sHndMS7ZK5/RPC2Bsktxa539LTcmVdpcD9jH8JUH73KqAIJrn4fbX8jX51JB01i Ifk/mz0G88iEEDs1yIiH9eOWaFGzG9uUVvCBbCZc1Mp48BwQNhrY8U1cyKMnkLNySw eFBq3G03xqCmL+owlApJThjHGukMu8DEFmOWtpkc6FxvhByt9BGP0+MbF1XHbc9Kdu RBHMJJ/SdZn0TfQDwS9ajrfSsE1fBL9fEw3TMp5yzH4aEMJUBhONo299lMdaM4l54q 0T5InSGMitTrigg4A4bbWRdEcRMKfNmtQCFqtYrJnFyVcME1Q0zjdzRX49lS98QtJC Ly6g4KZxQe79Q== Date: Tue, 20 Apr 2021 11:26:08 -0700 From: Jaegeuk Kim To: Chao Yu Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, chao@kernel.org Subject: Re: [PATCH] f2fs: fix to cover allocate_segment() with lock Message-ID: References: <20210414012134.128066-1-yuchao0@huawei.com> <03dc1c69-9215-1b5f-b1cc-c38454f3b90a@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03dc1c69-9215-1b5f-b1cc-c38454f3b90a@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/20, Chao Yu wrote: > On 2021/4/20 0:57, Jaegeuk Kim wrote: > > On 04/14, Chao Yu wrote: > > > As we did for other cases, in fix_curseg_write_pointer(), let's > > > change as below: > > > - use callback function s_ops->allocate_segment() instead of > > > raw function allocate_segment_by_default(); > > > - cover allocate_segment() with curseg_lock and sentry_lock. > > > > > > Signed-off-by: Chao Yu > > > --- > > > fs/f2fs/segment.c | 7 ++++++- > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c > > > index b2ee6b7791b0..daf9531ec58f 100644 > > > --- a/fs/f2fs/segment.c > > > +++ b/fs/f2fs/segment.c > > > @@ -4848,7 +4848,12 @@ static int fix_curseg_write_pointer(struct f2fs_sb_info *sbi, int type) > > > f2fs_notice(sbi, "Assign new section to curseg[%d]: " > > > "curseg[0x%x,0x%x]", type, cs->segno, cs->next_blkoff); > > > - allocate_segment_by_default(sbi, type, true); > > > + > > > + down_read(&SM_I(sbi)->curseg_lock); > > > + down_write(&SIT_I(sbi)->sentry_lock); > > > + SIT_I(sbi)->s_ops->allocate_segment(sbi, type, true); > > > + up_write(&SIT_I(sbi)->sentry_lock); > > > + up_read(&SM_I(sbi)->curseg_lock); > > > > Seems f2fs_allocate_new_section()? > > f2fs_allocate_new_section() will allocate new section only when current > section has been initialized and has valid block/ckpt_block. > > It looks fix_curseg_write_pointer() wants to force migrating current segment > to new section whenever write pointer and curseg->next_blkoff is inconsistent. > > So how about adding a parameter to force f2fs_allocate_new_section() to > allocate new section? I think that can be doable. Hope to avoid native calls as much as possible. > > Thanks, > > > > > > /* check consistency of the zone curseg pointed to */ > > > if (check_zone_write_pointer(sbi, zbd, &zone)) > > > -- > > > 2.29.2 > > . > >