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 5F25AC04FFE for ; Thu, 18 Apr 2024 18:22:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6F3D6B008C; Thu, 18 Apr 2024 14:22:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF80B6B0092; Thu, 18 Apr 2024 14:22:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 998F96B0093; Thu, 18 Apr 2024 14:22:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7DA896B008C for ; Thu, 18 Apr 2024 14:22:00 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2E06FC01D1 for ; Thu, 18 Apr 2024 18:22:00 +0000 (UTC) X-FDA: 82023471600.06.6F63A5D Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by imf17.hostedemail.com (Postfix) with ESMTP id 2F5AC4000E for ; Thu, 18 Apr 2024 18:21:58 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=F7K7lDSz; spf=pass (imf17.hostedemail.com: domain of lkp@intel.com designates 192.198.163.17 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=1713464518; 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=/fJnHQ1sNqpbj6lAD/kDPEp+3N4C6I3kAaYQwIsRr7Q=; b=mJapb2WRBVHKiLq9fraj6l6YLUyA3zNy2c3y5V0FjelpmJGH8VyxtJiQ2d/D3XjULPgtis tWv0TSiKKHJHNy4QHXd4DI4NyfFYVvvhenefhDeQb6NlERYlpuzXbSxSZQX1+0iE+KBUGa LpobwOediNWHq5pNFx6lk0o2bv9lg8I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713464518; a=rsa-sha256; cv=none; b=INDpf1EceectcjwUKA25zUjnyb9Aci/1oytpsuoOMgcHvfr31PiG8BLJhX9FGdSWwIcyup OP1NLpIFhx0z2EKqjcrDgFgaFHJ9Zd+h1SVpcb6S0Qo2t0yNammwJn78JucaR8b/LXwLYy X7/8FJIOxFRyo9/556gPhaTs7DRAWsk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=F7K7lDSz; spf=pass (imf17.hostedemail.com: domain of lkp@intel.com designates 192.198.163.17 as permitted sender) smtp.mailfrom=lkp@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713464518; x=1745000518; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=76Q4Uz7TXZn7xtFGN4DRXE4m+cPLFVaCk5NMS6tTgQ0=; b=F7K7lDSzeOgYKToCdPyV6uLnOSZPuNSzRSWa4KaxPDf/C0g38HYyfuLA 9m56HSIQ8O/ZYSy8+HSY24+XUFIfR1UlF6M0w8RmmqAgf1NNp3vyCEL+V v/b74HeVecc/kUObEnrdIA94PXWIo+fS7DMVFKsz/zuFjYim+748DJHds p94a64/S/FZetV84fHzSuPEndhzbGxRxPqvw15QgoxAqdTT+LxOJ+ZsAQ 9LWl/2yvesFTEYjGQ0FamdZj2VvDY871bScYfICPFa2E3LgwLyW83uJoZ ASm4TIkcMA1JZA/zEDeoDXl+cUpeKErhzfu7piWgxXxH73Vc40BOXGevS w==; X-CSE-ConnectionGUID: 72ijKmMFRY6p/1YIk45AbA== X-CSE-MsgGUID: qtBIEZ/vSMatV+a3hCQzbA== X-IronPort-AV: E=McAfee;i="6600,9927,11047"; a="8898368" X-IronPort-AV: E=Sophos;i="6.07,212,1708416000"; d="scan'208";a="8898368" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2024 11:21:53 -0700 X-CSE-ConnectionGUID: PaPWmaMoQDOLn9EQ4/K1xw== X-CSE-MsgGUID: T4X8YjSiSSqQ9bZJ2iB4LA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,212,1708416000"; d="scan'208";a="27531779" Received: from unknown (HELO 23c141fc0fd8) ([10.239.97.151]) by fmviesa005.fm.intel.com with ESMTP; 18 Apr 2024 11:21:49 -0700 Received: from kbuild by 23c141fc0fd8 with local (Exim 4.96) (envelope-from ) id 1rxWOJ-00095s-0c; Thu, 18 Apr 2024 18:21:47 +0000 Date: Fri, 19 Apr 2024 02:21:13 +0800 From: kernel test robot To: Kairui Song , linux-mm@kvack.org Cc: oe-kbuild-all@lists.linux.dev, Andrew Morton , Linux Memory Management List , "Huang, Ying" , Matthew Wilcox , Chris Li , Barry Song , Ryan Roberts , Neil Brown , Minchan Kim , Hugh Dickins , David Hildenbrand , Yosry Ahmed , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Kairui Song Subject: Re: [PATCH 8/8] mm/swap: reduce swap cache search space Message-ID: <202404190205.WSYYPQvi-lkp@intel.com> References: <20240417160842.76665-9-ryncsn@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240417160842.76665-9-ryncsn@gmail.com> X-Stat-Signature: c41djzubz89ksejbcfjdwrsshhy54qfi X-Rspamd-Queue-Id: 2F5AC4000E X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1713464518-784923 X-HE-Meta: U2FsdGVkX1+D4xFeDcdX562dyqpc3jOgsCTm7OyIUC70jPoD7Kf/3BMMCCSdfJRblCCJFXOWc8NyQwF5xLKUSHOdQv1rMjDpQwLQ5T+tSTgv95uk/Uhk5DRnrx8UxRbfJXTNNmy8EslP2zJ43eebiwT/iya5Sjr8cXLNjozGYykru80e7s/q5F9Ff4hS45xjOveqtUeQP/XC1IT59zSL3rCbrv3PNUnwk1ZeZPn5IHh0hnOOyyFDJgYSAk0b180uAN47sQyrqCS0Rr33QBsMlRhopRKXYYSQBygQbS2iKbrkTFCMFFxx19o8RBlf3OD/BQ/AN2TvxO7jtGp/6ZC0dOJPZJWrhgrgm163tIEx58phy5sactqMFqiqXm7RLwYyEgoxopGmZgQb0y5iBvEmLi7GJeHXrtXfPYkaoeqYeR/bySbOuADY/emxqdaeghAM/mtf7YgL9YeX4X1JxI+EDQwNyiPqZr/FQzgnJnrTXt0HqBb6EuTRPgx+CJOsNTOTprXDfe1r2HxeyXkIgOoHq/W+1MTkMLTbVjqzf6Er1zRJ9CW/SZEt2XyrlEIUfrgq+tncO/It8okaqxTYFU3lI9emxYzcWf3ogZbIBZnamoHEfMFO6YHzCK44XTv9E4ruFaYBJBjh2oktnNqmePBRQwUdDdUsGmm3XyXVueQ+jE9tCmicsCTmOnXHGwCAz9FouE4njycH/sDN0WG2/hd4+tSi5GWO+qh+at2/CsrHrhautzS5a8WTsUjgFt+WGdEbC/R2e+f5tJmd1CO0afgGDLDIQaTn4R3+l9JxCZed/BzwiXt/RI3XXV54+tCjS4YyRuCHOtSkkgjYNepbaaLnE2yXQXxU3yso 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 Kairui, kernel test robot noticed the following build errors: [auto build test ERROR on ceph-client/testing] [also build test ERROR on ceph-client/for-linus trondmy-nfs/linux-next konis-nilfs2/upstream jaegeuk-f2fs/dev-test jaegeuk-f2fs/dev cifs/for-next linus/master v6.9-rc4] [cannot apply to akpm-mm/mm-everything next-20240418] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Kairui-Song/NFS-remove-nfs_page_lengthg-and-usage-of-page_index/20240418-001343 base: https://github.com/ceph/ceph-client.git testing patch link: https://lore.kernel.org/r/20240417160842.76665-9-ryncsn%40gmail.com patch subject: [PATCH 8/8] mm/swap: reduce swap cache search space config: alpha-allnoconfig (https://download.01.org/0day-ci/archive/20240419/202404190205.WSYYPQvi-lkp@intel.com/config) compiler: alpha-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240419/202404190205.WSYYPQvi-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/202404190205.WSYYPQvi-lkp@intel.com/ All errors (new ones prefixed by >>): mm/shmem.c: In function 'shmem_replace_folio': >> mm/shmem.c:1765:22: error: implicit declaration of function 'swap_cache_index' [-Werror=implicit-function-declaration] 1765 | swap_index = swap_cache_index(entry); | ^~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors vim +/swap_cache_index +1765 mm/shmem.c 1753 1754 static int shmem_replace_folio(struct folio **foliop, gfp_t gfp, 1755 struct shmem_inode_info *info, pgoff_t index) 1756 { 1757 struct folio *old, *new; 1758 struct address_space *swap_mapping; 1759 swp_entry_t entry; 1760 pgoff_t swap_index; 1761 int error; 1762 1763 old = *foliop; 1764 entry = old->swap; > 1765 swap_index = swap_cache_index(entry); 1766 swap_mapping = swap_address_space(entry); 1767 1768 /* 1769 * We have arrived here because our zones are constrained, so don't 1770 * limit chance of success by further cpuset and node constraints. 1771 */ 1772 gfp &= ~GFP_CONSTRAINT_MASK; 1773 VM_BUG_ON_FOLIO(folio_test_large(old), old); 1774 new = shmem_alloc_folio(gfp, info, index); 1775 if (!new) 1776 return -ENOMEM; 1777 1778 folio_get(new); 1779 folio_copy(new, old); 1780 flush_dcache_folio(new); 1781 1782 __folio_set_locked(new); 1783 __folio_set_swapbacked(new); 1784 folio_mark_uptodate(new); 1785 new->swap = entry; 1786 folio_set_swapcache(new); 1787 1788 /* 1789 * Our caller will very soon move newpage out of swapcache, but it's 1790 * a nice clean interface for us to replace oldpage by newpage there. 1791 */ 1792 xa_lock_irq(&swap_mapping->i_pages); 1793 error = shmem_replace_entry(swap_mapping, swap_index, old, new); 1794 if (!error) { 1795 mem_cgroup_migrate(old, new); 1796 __lruvec_stat_mod_folio(new, NR_FILE_PAGES, 1); 1797 __lruvec_stat_mod_folio(new, NR_SHMEM, 1); 1798 __lruvec_stat_mod_folio(old, NR_FILE_PAGES, -1); 1799 __lruvec_stat_mod_folio(old, NR_SHMEM, -1); 1800 } 1801 xa_unlock_irq(&swap_mapping->i_pages); 1802 1803 if (unlikely(error)) { 1804 /* 1805 * Is this possible? I think not, now that our callers check 1806 * both PageSwapCache and page_private after getting page lock; 1807 * but be defensive. Reverse old to newpage for clear and free. 1808 */ 1809 old = new; 1810 } else { 1811 folio_add_lru(new); 1812 *foliop = new; 1813 } 1814 1815 folio_clear_swapcache(old); 1816 old->private = NULL; 1817 1818 folio_unlock(old); 1819 folio_put_refs(old, 2); 1820 return error; 1821 } 1822 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki