lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <202209142012.hlbabN1C-lkp@intel.com>
Date:   Wed, 14 Sep 2022 20:39:58 +0800
From:   kernel test robot <lkp@...el.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org
Subject: [djbw-nvdimm:libnvdimm-pending 16/22] drivers/dax/mapping.c:947:
 undefined reference to `dax_flush'

Hi Dan,

FYI, the error/warning was bisected to this commit, please ignore it if it's irrelevant.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git libnvdimm-pending
head:   e27a0356de15f16934325784c6b1d89cf0f13458
commit: 155ac6b670cf6385f6dd14910560d569560af889 [16/22] devdax: Move address_space helpers to the DAX core
config: arc-randconfig-r043-20220914
compiler: arc-elf-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/commit/?id=155ac6b670cf6385f6dd14910560d569560af889
        git remote add djbw-nvdimm https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git
        git fetch --no-tags djbw-nvdimm libnvdimm-pending
        git checkout 155ac6b670cf6385f6dd14910560d569560af889
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arc SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@...el.com>

All errors (new ones prefixed by >>):

   arc-elf-ld: drivers/dax/mapping.o: in function `dax_writeback_one':
>> drivers/dax/mapping.c:947: undefined reference to `dax_flush'
>> arc-elf-ld: drivers/dax/mapping.c:947: undefined reference to `dax_flush'


vim +947 drivers/dax/mapping.c

   873	
   874	int dax_writeback_one(struct xa_state *xas, struct dax_device *dax_dev,
   875			      struct address_space *mapping, void *entry)
   876	{
   877		unsigned long pfn, index, count, end;
   878		long ret = 0;
   879		struct vm_area_struct *vma;
   880	
   881		/*
   882		 * A page got tagged dirty in DAX mapping? Something is seriously
   883		 * wrong.
   884		 */
   885		if (WARN_ON(!xa_is_value(entry)))
   886			return -EIO;
   887	
   888		if (unlikely(dax_is_locked(entry))) {
   889			void *old_entry = entry;
   890	
   891			entry = get_unlocked_entry(xas, 0);
   892	
   893			/* Entry got punched out / reallocated? */
   894			if (!entry || WARN_ON_ONCE(!xa_is_value(entry)))
   895				goto put_unlocked;
   896			/*
   897			 * Entry got reallocated elsewhere? No need to writeback.
   898			 * We have to compare pfns as we must not bail out due to
   899			 * difference in lockbit or entry type.
   900			 */
   901			if (dax_to_pfn(old_entry) != dax_to_pfn(entry))
   902				goto put_unlocked;
   903			if (WARN_ON_ONCE(dax_is_empty_entry(entry) ||
   904						dax_is_zero_entry(entry))) {
   905				ret = -EIO;
   906				goto put_unlocked;
   907			}
   908	
   909			/* Another fsync thread may have already done this entry */
   910			if (!xas_get_mark(xas, PAGECACHE_TAG_TOWRITE))
   911				goto put_unlocked;
   912		}
   913	
   914		/* Lock the entry to serialize with page faults */
   915		dax_lock_entry(xas, entry);
   916	
   917		/*
   918		 * We can clear the tag now but we have to be careful so that concurrent
   919		 * dax_writeback_one() calls for the same index cannot finish before we
   920		 * actually flush the caches. This is achieved as the calls will look
   921		 * at the entry only under the i_pages lock and once they do that
   922		 * they will see the entry locked and wait for it to unlock.
   923		 */
   924		xas_clear_mark(xas, PAGECACHE_TAG_TOWRITE);
   925		xas_unlock_irq(xas);
   926	
   927		/*
   928		 * If dax_writeback_mapping_range() was given a wbc->range_start
   929		 * in the middle of a PMD, the 'index' we use needs to be
   930		 * aligned to the start of the PMD.
   931		 * This allows us to flush for PMD_SIZE and not have to worry about
   932		 * partial PMD writebacks.
   933		 */
   934		pfn = dax_to_pfn(entry);
   935		count = 1UL << dax_entry_order(entry);
   936		index = xas->xa_index & ~(count - 1);
   937		end = index + count - 1;
   938	
   939		/* Walk all mappings of a given index of a file and writeprotect them */
   940		i_mmap_lock_read(mapping);
   941		vma_interval_tree_foreach(vma, &mapping->i_mmap, index, end) {
   942			pfn_mkclean_range(pfn, count, index, vma);
   943			cond_resched();
   944		}
   945		i_mmap_unlock_read(mapping);
   946	
 > 947		dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE);
   948		/*
   949		 * After we have flushed the cache, we can clear the dirty tag. There
   950		 * cannot be new dirty data in the pfn after the flush has completed as
   951		 * the pfn mappings are writeprotected and fault waits for mapping
   952		 * entry lock.
   953		 */
   954		xas_reset(xas);
   955		xas_lock_irq(xas);
   956		xas_store(xas, entry);
   957		xas_clear_mark(xas, PAGECACHE_TAG_DIRTY);
   958		dax_wake_entry(xas, entry, WAKE_NEXT);
   959	
   960		trace_dax_writeback_one(mapping->host, index, count);
   961		return ret;
   962	
   963	 put_unlocked:
   964		put_unlocked_entry(xas, entry, WAKE_NEXT);
   965		return ret;
   966	}
   967	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

View attachment "config" of type "text/plain" (200321 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ