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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79C6CECAAA1 for ; Wed, 7 Sep 2022 01:27:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94CEB8D0005; Tue, 6 Sep 2022 21:27:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FB078D0001; Tue, 6 Sep 2022 21:27:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79C7B8D0005; Tue, 6 Sep 2022 21:27:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 64C848D0001 for ; Tue, 6 Sep 2022 21:27:08 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2F6F8A0201 for ; Wed, 7 Sep 2022 01:27:08 +0000 (UTC) X-FDA: 79883550936.10.65A0000 Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by imf18.hostedemail.com (Postfix) with ESMTP id A74731C0066 for ; Wed, 7 Sep 2022 01:27:05 +0000 (UTC) HMM_SOURCE_IP:172.18.0.218:47248.1217073643 HMM_ATTACHE_NUM:0000 HMM_SOURCE_TYPE:SMTP Received: from clientip-110.188.55.54 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id F0DEB2800D4; Wed, 7 Sep 2022 09:26:46 +0800 (CST) X-189-SAVE-TO-SEND: lic121@chinatelecom.cn Received: from ([172.18.0.218]) by app0025 with ESMTP id ec71a940db7a43cab5eb89777746d3ec for akpm@linux-foundation.org; Wed, 07 Sep 2022 09:26:58 CST X-Transaction-ID: ec71a940db7a43cab5eb89777746d3ec X-Real-From: lic121@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Date: Wed, 7 Sep 2022 01:26:33 +0000 From: Cheng Li To: Andrew Morton Cc: Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: use mem_map_offset instead of mem_map_next Message-ID: <20220907012633.GA21996@vscode.7~> References: <1662358159-22780-1-git-send-email-lic121@chinatelecom.cn> <20220906171048.1cd24a27b71ded17f89ddb00@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220906171048.1cd24a27b71ded17f89ddb00@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662514027; a=rsa-sha256; cv=none; b=NKKYh8RKAjDv2dEerw42hbzhVQQQ6BjQfURbiGWATKTHFK6Kspchd95aASWb1YAeUI+1hb l2DveIg22MkVP5NdMjVbxv6wueH33YQ+u8Bjcy9x/urM9AdCSEjfs86nS0LLqHVMphnnru aRohZ1L4hwhwaOz8b4prclD2TAPRuV0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of lic121@chinatelecom.cn designates 42.123.76.220 as permitted sender) smtp.mailfrom=lic121@chinatelecom.cn; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662514027; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=idOVy4H5e8OyDpfyVPTtKbqmDwovYW9GsGEbUolYUps=; b=ssT4mYTwsa5V3DHGCx7clwAT4+QuT92x2bE1C7I5+eyw22lpDjNLFRulqnr4Es4XwGZCsq rik9+WdCFAnPZmNA6c/buX1jVyGS9XD6js2Pcm4fFw0niG8GqG4aX4nN3Hb7diOU0sBb/K hFqxKdVoPjW4iQTAghscnipCLExo+Tk= X-Stat-Signature: jq3r7itfu899nuhixzpa678y8d338yon X-Rspamd-Queue-Id: A74731C0066 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of lic121@chinatelecom.cn designates 42.123.76.220 as permitted sender) smtp.mailfrom=lic121@chinatelecom.cn; dmarc=none X-Rspamd-Server: rspam08 X-HE-Tag: 1662514025-669117 X-Bogosity: Ham, tests=bogofilter, spamicity=0.287382, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 06, 2022 at 05:10:48PM -0700, Andrew Morton wrote: > On Tue, 6 Sep 2022 10:07:03 -0700 Mike Kravetz wrote: > > > On 09/05/22 06:09, Cheng Li wrote: > > > To handle discontiguity case, mem_map_next() has a parameter named > > > `offset`. As a function caller, one would be confused why "get > > > next entry" needs a parameter named "offset". The other drawback of > > > mem_map_next() is that the callers must take care of the map between > > > parameter "iter" and "offset", otherwise we may get an hole or > > > duplication during iteration. So we use mem_map_offset instead of > > > mem_map_next. > > > > > > Signed-off-by: Cheng Li > > > Fixes: 69d177c2fc70 ("hugetlbfs: handle pages higher order than MAX_ORDER") > > > > The Fixes tag implies there is a user visible bug. I do not believe this is > > the case here. Is there a user visible bug? > > A Fixes: with a cc:stable would indicate a user-visible bug. But IMO a > bare Fixes: is simply a when-to-stop guide to backporters - a > convenience. And, I suppose, it has some documentation benefit. > > And if people are really that interested, they can read the dang > changelog ;) > Thank you for the reviews and the "Fixes" tag tips. So seems we are agrenment on replacing mem_map_offset() with nth_page(). I may need to send the version 3 :) I learnt the "Fixes" tag usage from this kenrel contribution guide.[1] [1] https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes