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 ACB88C27C54 for ; Wed, 5 Jun 2024 02:57:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 140A36B008C; Tue, 4 Jun 2024 22:57:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F02E6B0092; Tue, 4 Jun 2024 22:57:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFB9B6B0093; Tue, 4 Jun 2024 22:57:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D31B36B008C for ; Tue, 4 Jun 2024 22:57:35 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 85772120D58 for ; Wed, 5 Jun 2024 02:57:35 +0000 (UTC) X-FDA: 82195324470.04.27A18E2 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by imf14.hostedemail.com (Postfix) with ESMTP id B9B43100004 for ; Wed, 5 Jun 2024 02:57:32 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gpm3xslE; spf=pass (imf14.hostedemail.com: domain of lkp@intel.com designates 192.198.163.18 as permitted sender) smtp.mailfrom=lkp@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717556253; a=rsa-sha256; cv=none; b=6vPO+F5W4qAdPtWYn/xoCyJPSS3l2x1H1RgLGJmodXLZU6P8DTJc+6Gz5CSYwD1bHnbyuB QvugeAiXfJDNx6TTZ3l9C8yLA6SERDcpAqpgiCFYHBLzV/F2MQwBzYAWjfK3QFU2HM3Tye oANJaXeynQHrY6npYb1F4KRfsL2vSNg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gpm3xslE; spf=pass (imf14.hostedemail.com: domain of lkp@intel.com designates 192.198.163.18 as permitted sender) smtp.mailfrom=lkp@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717556253; h=from:from: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:dkim-signature; bh=z11pKszFrMFi4zhUF9STIBuXtlsheDVGX009p7uGRG4=; b=ag00m6AiGYxFhzooOKyhcdLKV8Hlo3Xc/5WocqBPTsSAkXQMJfAnINNngQPK5jtk26ppDa P3iNmkUqvQxyBhD0WqeADLMcsRsP3fA1ETyy4aCfn0N1I4jKNR9oScFPPxLUOuqWvTNBIF Ij0v2SghghmD4/9O/tX26+KUInhlsP4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1717556253; x=1749092253; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Tf3EId6rxeexzyTsHKLQ6hT9dw4h2JfE1+v1zFOFQ4g=; b=gpm3xslEllrsDWAaBJ1evqQLdWP6B72XElEDuAOrHTS+ikmS8bwUAH+Q 4cTLdka1Sn43VZu1H6XBtKH3GAYMF/HFDlhJBAIqsSZZRZThZrAYCy7k8 UyTlQrg6XpAVmukWniEnlkqXchteRc3p5km01AZVT9kSuGVShvbWN2agB T5gZgUsQVpQF0MQaaAPWEXXNH3sWHOE9EFQAnvU3Uw1Q59OpTg8+xCLoF dKLUEcqmW3yh/rDDek1DBr0el9AjSl1CWR0iguEPTiwWasBRjGol+8DML acMq+iQo9cOqO/iX1kT/1t022Q/vvJK/rrblUjHg+sibXIKQIBBlUkI97 Q==; X-CSE-ConnectionGUID: 7FgAeOSRSjGssDNinqO6gQ== X-CSE-MsgGUID: j92yCq+jSgae6rb0dAZe+w== X-IronPort-AV: E=McAfee;i="6600,9927,11093"; a="13889969" X-IronPort-AV: E=Sophos;i="6.08,215,1712646000"; d="scan'208";a="13889969" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2024 19:57:31 -0700 X-CSE-ConnectionGUID: iK6PlWzmT6a05HZ7diAK5Q== X-CSE-MsgGUID: KHRIZ7fMR2C2Zb6tAzgy/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,215,1712646000"; d="scan'208";a="42550156" Received: from unknown (HELO 0610945e7d16) ([10.239.97.151]) by orviesa004.jf.intel.com with ESMTP; 04 Jun 2024 19:57:28 -0700 Received: from kbuild by 0610945e7d16 with local (Exim 4.96) (envelope-from ) id 1sEgq5-0000q3-0N; Wed, 05 Jun 2024 02:57:25 +0000 Date: Wed, 5 Jun 2024 10:57:13 +0800 From: kernel test robot To: Yang Shi , peterx@redhat.com, oliver.sang@intel.com, paulmck@kernel.org, david@redhat.com, willy@infradead.org, riel@surriel.com, vivek.kasireddy@intel.com, cl@linux.com, akpm@linux-foundation.org Cc: oe-kbuild-all@lists.linux.dev, yang@os.amperecomputing.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 2/2] mm: gup: do not call try_grab_folio() in slow path Message-ID: <202406051039.9m00gwIx-lkp@intel.com> References: <20240604234858.948986-2-yang@os.amperecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240604234858.948986-2-yang@os.amperecomputing.com> X-Rspamd-Queue-Id: B9B43100004 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: mwup8deetig1h47adt8s63r9ztqdn7br X-HE-Tag: 1717556252-920376 X-HE-Meta: U2FsdGVkX1/XMSp3S2yiD+u45MZcYXz9atYGqwnULM2754oAz6SR07omgserlTNVF0ZG6x0llVKmWK4rNVB8m9EI2VTLUDoN0KWnBOIkiQEZSBfceYAHEk9EIRqq2JbY/66Fnc24JJfSd6vItTBfYcGWOJ7tQogg6nxoSctCmG7T7ccc2ffovbWYNiwxqzEeiDtwyHls6jdHO+t0lRI1dbzWmIBZ5owGrz4YJGGlkqMVSesBEjzwkYZKaWs1m6OKLBn+NC8pOU2WswI6QZvi3ADD7OqZxrb8q3Q23W56aFVCPkU/gkml+bnAIhhsSRi+OFVCX9w2KrHVF1+pQv9nA0xi9jjfjCeFodZUcWdLd1MKMwvN5EpcWjJxPXGG2akph1adCTPRMiprcgP2k8bSn/KR6bO9mnm6N6EzNFsOh8LM9V6dy6r6S+TVM/qGBFxyotUaNw4voJVul8VdEILkfEYfr+HNGDxHg4sphWewD0mBWgGvK5beLQGJuP0m7waZgs2jtv1KLzZX3l+6QEJUeOGGGw0yTI7kr1Sz2Mn7GXFtJLfALCX9NzTPg48OBITfZvketrknycvnEUi8tUCnhLinJSEWejY07c8QrUIc42UPlYG00i7GzZhXVFAXe73I+Unm6Gu313Ndku+wN2Wos+uqru5SMz/6gFeZ2w+aHGi6cjPJnQFMBlgdYyXQNhNq8w9kCXVhDsYp+q48/7hdEYM0yBXNQfP4nO/SKyNZvPAgo3qzxW+Ljy9QjFdFXC0+MAw++M+Dx+5UxJH6UIZQQlqGb1GZ6BlS6pJyumCLOXwR/XStpVi+LBPAuPZxGYN4hvF2DFT+lGU+Do9JiduPjEBt73gJPeGd5+zgdpQOKnx5znTq+dS1jLOhwpDGQrsnf8V6QW6mPhfobhLmYDncR+FjoR8Rwr4po5vyRagZ2oQSQQl8XrQP6vOvg3gcJT2ID+0dKeNZUYLNiqfvl04 I7RWbuYA 1P8y6VTc/MowPZfVx01vppQGftZPQIc9iJ83EEQVn5E1eXrFgIy61l2tQyD2MKr2Qxai8esSD9HScIQ82IkEgJgedJ/a00kiHcFPLXgEgYKSoowpf7jFgema4KYcO4sdUqKDxU5AvdXgLJ3p9ovzxteH04PcVh9dkAJP+1RoR1C0wonvuzLaFaEcYdg8FDoSaLFXn7PrN6olLRIDQ7BfC1aTK1IJStysEmmr4j2MMhATaHQTToxjoluiIWc9LuFQ4hqaTb4GUgi+iKX2FseLROdm+ByLsTtzNkKmhyTetYhzKRVJMwyi43mI4fD3lsMbCR6DofjYeXR0SbJ4Ddwk54+BVdd1Q1fu1XQiVi7HTsYBFUNG0nW7cNweS3m9CVhK/fqHKAz+Taazy9iJhD+wrlwAubync8t2+lCr/ 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: List-Subscribe: List-Unsubscribe: Hi Yang, kernel test robot noticed the following build warnings: [auto build test WARNING on akpm-mm/mm-everything] url: https://github.com/intel-lab-lkp/linux/commits/Yang-Shi/mm-gup-do-not-call-try_grab_folio-in-slow-path/20240605-075027 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20240604234858.948986-2-yang%40os.amperecomputing.com patch subject: [PATCH 2/2] mm: gup: do not call try_grab_folio() in slow path config: openrisc-allnoconfig (https://download.01.org/0day-ci/archive/20240605/202406051039.9m00gwIx-lkp@intel.com/config) compiler: or1k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240605/202406051039.9m00gwIx-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202406051039.9m00gwIx-lkp@intel.com/ All warnings (new ones prefixed by >>): >> mm/gup.c:131:22: warning: 'try_grab_folio_fast' defined but not used [-Wunused-function] 131 | static struct folio *try_grab_folio_fast(struct page *page, int refs, | ^~~~~~~~~~~~~~~~~~~ vim +/try_grab_folio_fast +131 mm/gup.c 101 102 /** 103 * try_grab_folio_fast() - Attempt to get or pin a folio in fast path. 104 * @page: pointer to page to be grabbed 105 * @refs: the value to (effectively) add to the folio's refcount 106 * @flags: gup flags: these are the FOLL_* flag values. 107 * 108 * "grab" names in this file mean, "look at flags to decide whether to use 109 * FOLL_PIN or FOLL_GET behavior, when incrementing the folio's refcount. 110 * 111 * Either FOLL_PIN or FOLL_GET (or neither) must be set, but not both at the 112 * same time. (That's true throughout the get_user_pages*() and 113 * pin_user_pages*() APIs.) Cases: 114 * 115 * FOLL_GET: folio's refcount will be incremented by @refs. 116 * 117 * FOLL_PIN on large folios: folio's refcount will be incremented by 118 * @refs, and its pincount will be incremented by @refs. 119 * 120 * FOLL_PIN on single-page folios: folio's refcount will be incremented by 121 * @refs * GUP_PIN_COUNTING_BIAS. 122 * 123 * Return: The folio containing @page (with refcount appropriately 124 * incremented) for success, or NULL upon failure. If neither FOLL_GET 125 * nor FOLL_PIN was set, that's considered failure, and furthermore, 126 * a likely bug in the caller, so a warning is also emitted. 127 * 128 * It uses add ref unless zero to elevate the folio refcount and must be called 129 * in fast path only. 130 */ > 131 static struct folio *try_grab_folio_fast(struct page *page, int refs, 132 unsigned int flags) 133 { 134 struct folio *folio; 135 136 /* Raise warn if it is not called in fast GUP */ 137 VM_WARN_ON_ONCE(!irqs_disabled()); 138 139 if (WARN_ON_ONCE((flags & (FOLL_GET | FOLL_PIN)) == 0)) 140 return NULL; 141 142 if (unlikely(!(flags & FOLL_PCI_P2PDMA) && is_pci_p2pdma_page(page))) 143 return NULL; 144 145 if (flags & FOLL_GET) 146 return try_get_folio(page, refs); 147 148 /* FOLL_PIN is set */ 149 150 /* 151 * Don't take a pin on the zero page - it's not going anywhere 152 * and it is used in a *lot* of places. 153 */ 154 if (is_zero_page(page)) 155 return page_folio(page); 156 157 folio = try_get_folio(page, refs); 158 if (!folio) 159 return NULL; 160 161 /* 162 * Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a 163 * right zone, so fail and let the caller fall back to the slow 164 * path. 165 */ 166 if (unlikely((flags & FOLL_LONGTERM) && 167 !folio_is_longterm_pinnable(folio))) { 168 if (!put_devmap_managed_folio_refs(folio, refs)) 169 folio_put_refs(folio, refs); 170 return NULL; 171 } 172 173 /* 174 * When pinning a large folio, use an exact count to track it. 175 * 176 * However, be sure to *also* increment the normal folio 177 * refcount field at least once, so that the folio really 178 * is pinned. That's why the refcount from the earlier 179 * try_get_folio() is left intact. 180 */ 181 if (folio_test_large(folio)) 182 atomic_add(refs, &folio->_pincount); 183 else 184 folio_ref_add(folio, 185 refs * (GUP_PIN_COUNTING_BIAS - 1)); 186 /* 187 * Adjust the pincount before re-checking the PTE for changes. 188 * This is essentially a smp_mb() and is paired with a memory 189 * barrier in folio_try_share_anon_rmap_*(). 190 */ 191 smp_mb__after_atomic(); 192 193 node_stat_mod_folio(folio, NR_FOLL_PIN_ACQUIRED, refs); 194 195 return folio; 196 } 197 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki