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=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 43317C07E9C for ; Mon, 5 Jul 2021 18:06:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B715161979 for ; Mon, 5 Jul 2021 18:06:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B715161979 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 6E8976B00A5; Mon, 5 Jul 2021 14:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 698986B00A6; Mon, 5 Jul 2021 14:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 560076B00A7; Mon, 5 Jul 2021 14:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 334956B00A5 for ; Mon, 5 Jul 2021 14:06:36 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AE32B202FA for ; Mon, 5 Jul 2021 18:06:35 +0000 (UTC) X-FDA: 78329314350.09.97F840A Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id 52F0C100252C for ; Mon, 5 Jul 2021 18:06:35 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 53BEC61960; Mon, 5 Jul 2021 18:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625508394; bh=Xy6ubhejwEcN3GLCCD+sUqLDtIYEEis2KKMbHhLmyHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ovqck0GUI7kaHVA3NtrmtZq5CWV8zozOpFvTU9JFlmuOX/dfRPmcX1M0CDgg5Z+RC 4f7ezNI1khjahp7kAobT7VkG0vANfLf4cv1rjM05f+sEvrup8/cZmYkrM/LnSFvtCd 6Mbs4za5rspQEE3YKc68gNKuZKRGWsI097MuPsQ2PVGhU5VNy6beqYOmz09+uEJ+zS 6R720ei75uXWBTOZomxorAldcIwevOd2KlakHB+LArrWrv0lkTSMHsjSdA2TwBGeyf iIBXMciczvBOC6ndXA2v1UTt8dYAQm9qNVqC5LdJWaNb6rQI3W16KhgsFwIWcbvamQ KKInZt6FF9szg== Date: Mon, 5 Jul 2021 11:06:32 -0700 From: Jaegeuk Kim To: Chao Yu Cc: Matthew Wilcox , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org Subject: Re: [f2fs-dev] [PATCH] f2fs: initialize page->private when using for our internal use Message-ID: References: <20210705052216.831989-1-jaegeuk@kernel.org> <5ab8d01a-8fac-60b2-9c2c-a32c5a81b394@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ab8d01a-8fac-60b2-9c2c-a32c5a81b394@kernel.org> Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ovqck0GU; spf=pass (imf07.hostedemail.com: domain of jaegeuk@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=jaegeuk@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 52F0C100252C X-Stat-Signature: io3xeg6rc8stoay7m5gfzwc511778j7o X-HE-Tag: 1625508395-390750 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 07/06, Chao Yu wrote: > On 2021/7/5 19:47, Matthew Wilcox wrote: > > On Mon, Jul 05, 2021 at 07:33:35PM +0800, Chao Yu wrote: > > > On 2021/7/5 16:56, Jaegeuk Kim wrote: > > > > On 07/05, Chao Yu wrote: > > > > > On 2021/7/5 13:22, Jaegeuk Kim wrote: > > > > > > We need to guarantee it's initially zero. Otherwise, it'll hurt entire flag > > > > > > operations. > > > > > > > > > > Oops, I didn't get the point, shouldn't .private be zero after page was > > > > > just allocated by filesystem? What's the case we will encounter stall > > > > > private data left in page? > > > > > > > > I'm seeing f2fs_migrate_page() has the newpage with some value without Private > > > > flag. That causes a kernel panic later due to wrong private flag used in f2fs. > > > > > > I'm not familiar with that part of codes, so Cc mm mailing list for help. > > > > > > My question is newpage in .migrate_page() may contain non-zero value in .private > > > field but w/o setting PagePrivate flag, is it a normal case? > > > > I think freshly allocated pages have a page->private of 0. ie this > > code in mm/page_alloc.c: > > > > page = rmqueue(ac->preferred_zoneref->zone, zone, order, > > gfp_mask, alloc_flags, ac->migratetype); > > if (page) { > > prep_new_page(page, order, gfp_mask, alloc_flags); > > > > where prep_new_page() calls post_alloc_hook() which contains: > > set_page_private(page, 0); > > > > Now, I do see in __buffer_migrate_page() (mm/migrate.c): > > > > attach_page_private(newpage, detach_page_private(page)); > > > > but as far as I can tell, f2fs doesn't call any of the > > buffer_migrate_page() paths. So I'm not sure why you're seeing > > a non-zero page->private. > > Well, that's strange. > > Jaegeuk, let's add a BUGON in f2fs to track the call path where newpage > has non-zero private value? if this issue is reproducible. We can debug anything tho, this issue is blocking the production, and I'd like to get this in this merge windows. Could you please check the patch has any holes? > > Thanks, > > >