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 7C568C433EF for ; Wed, 9 Mar 2022 01:00:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAB168D0002; Tue, 8 Mar 2022 20:00:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E58548D0001; Tue, 8 Mar 2022 20:00:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D202B8D0002; Tue, 8 Mar 2022 20:00:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id C294A8D0001 for ; Tue, 8 Mar 2022 20:00:10 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8E36E24886 for ; Wed, 9 Mar 2022 01:00:10 +0000 (UTC) X-FDA: 79223041380.02.D0B3D47 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf05.hostedemail.com (Postfix) with ESMTP id ABC3F10000C for ; Wed, 9 Mar 2022 01:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646787609; x=1678323609; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=4URLKVDgh8stZTbeL/CYtqk8VqMopTxqW9DHku7N9ps=; b=SPMO4u8NyAGWkkCTAJB/Gs1OnX688YOyKVi8ogVb3IzZ2/YJg70fdIKM 12pCCXb/akwMlBmj4zaloXySI/DrLiTG3ttL1EIvXo6TcruDQZ/G2swUX ZgBlVN9Aem8avROVw62VZ4XYOKnyY1zObbDxN+yxMgUbas//L84TFK+Kz L+mmVNV3F5W09RBrLrosSNhAMQgnwQ7dVQ66x1/UCVJfwhSNVuzMQXLup YDyo4c3/+gn+inIlhY6PmJ3gV8yjlSO2EOAkYaO6xlNnA/jjtrLvqCWbO W7nkms9PuP6vNEok+KzD3XBGTtq41uLPLZA2c7vruZXNFxOwk6AXPlTSM g==; X-IronPort-AV: E=McAfee;i="6200,9189,10280"; a="254795570" X-IronPort-AV: E=Sophos;i="5.90,165,1643702400"; d="scan'208";a="254795570" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2022 17:00:08 -0800 X-IronPort-AV: E=Sophos;i="5.90,165,1643702400"; d="scan'208";a="553874286" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2022 17:00:03 -0800 From: "Huang, Ying" To: Miaohe Lin Cc: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 13/16] mm/migration: return errno when isolate_huge_page failed References: <20220304093409.25829-1-linmiaohe@huawei.com> <20220304093409.25829-14-linmiaohe@huawei.com> <87ilsq5p0x.fsf@yhuang6-desk2.ccr.corp.intel.com> <85acb60f-76a6-2cbc-0896-a593531dfc27@huawei.com> Date: Wed, 09 Mar 2022 09:00:01 +0800 In-Reply-To: <85acb60f-76a6-2cbc-0896-a593531dfc27@huawei.com> (Miaohe Lin's message of "Tue, 8 Mar 2022 20:12:28 +0800") Message-ID: <8735jsgctq.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: ABC3F10000C X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SPMO4u8N; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf05.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=ying.huang@intel.com X-Stat-Signature: 76dirpdrsbn4wsfdehrxcdmy6cqcesbn X-HE-Tag: 1646787609-236027 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: Miaohe Lin writes: > On 2022/3/7 13:07, Huang, Ying wrote: >> Miaohe Lin writes: >> >>> We should return errno (-EBUSY here) when failed to isolate the huge page >>> rather than always return 1 which could confuse the user. >>> >>> Signed-off-by: Miaohe Lin >>> --- >>> mm/migrate.c | 6 ++---- >>> 1 file changed, 2 insertions(+), 4 deletions(-) >>> >>> diff --git a/mm/migrate.c b/mm/migrate.c >>> index 6c2dfed2ddb8..279940c0c064 100644 >>> --- a/mm/migrate.c >>> +++ b/mm/migrate.c >>> @@ -1618,10 +1618,8 @@ static int add_page_for_migration(struct mm_struct *mm, unsigned long addr, >>> goto out_putpage; >>> >>> if (PageHuge(page)) { >>> - if (PageHead(page)) { >>> - isolate_huge_page(page, pagelist); >>> - err = 1; >>> - } >>> + if (PageHead(page)) >>> + err = isolate_huge_page(page, pagelist) ? 1 : -EBUSY; >> >> IMHO, it's better to determine the proper errno inside >> isolate_huge_page() instead of in the caller. If you think it's >> necessary to get errno here. How about change isolate_huge_page() >> instead? > > IMO, -EBUSY should be enough for the user (as they could not do much) and this > errno keeps consistent with the non-hugetlb page case. What do you think? I found the prototype of isolate_lru_page() is as follows, int isolate_lru_page(struct page *page) And it will return errno directly. I think we should follow same convention here? Best Regards, Huang, Ying