Received-SPF: pass (google.com: domain of linux-kernel+bounces-150624-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 19 Apr 2024 02:21:13 +0800
From: kernel test robot <lkp@intel.com>
To: Kairui Song <ryncsn@gmail.com>, linux-mm@kvack.org
Cc: oe-kbuild-all@lists.linux.dev,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	"Huang, Ying" <ying.huang@intel.com>,
	Matthew Wilcox <willy@infradead.org>, Chris Li <chrisl@kernel.org>,
	Barry Song <v-songbaohua@oppo.com>,
	Ryan Roberts <ryan.roberts@arm.com>, Neil Brown <neilb@suse.de>,
	Minchan Kim <minchan@kernel.org>, Hugh Dickins <hughd@google.com>,
	David Hildenbrand <david@redhat.com>,
	Yosry Ahmed <yosryahmed@google.com>, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Kairui Song <kasong@tencent.com>
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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240417160842.76665-9-ryncsn@gmail.com>

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 <lkp@intel.com>
| 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