All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: kbuild-all@lists.01.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>,
	Yafang Shao <laoar.shao@gmail.com>,
	Michal Hocko <mhocko@suse.com>, Roman Gushchin <guro@fb.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	kernel-team@fb.com
Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
Date: Sat, 15 Feb 2020 00:53:10 +0800	[thread overview]
Message-ID: <202002150049.JtbQNZ7x%lkp@intel.com> (raw)
In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org>

[-- Attachment #1: Type: text/plain, Size: 6051 bytes --]

Hi Johannes,

I love your patch! Yet something to improve:

[auto build test ERROR on vfs/for-next]
[also build test ERROR on linux/master linus/master v5.6-rc1 next-20200213]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Johannes-Weiner/vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-LRU/20200214-083756
base:   https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.5.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.5.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   fs/dax.c: In function 'grab_mapping_entry':
>> fs/dax.c:556:28: error: 'struct address_space' has no member named 'inode'
      inode_pages_clear(mapping->inode);
                               ^~
   fs/dax.c:558:26: error: 'struct address_space' has no member named 'inode'
      inode_pages_set(mapping->inode);
                             ^~

vim +556 fs/dax.c

   446	
   447	/*
   448	 * Find page cache entry at given index. If it is a DAX entry, return it
   449	 * with the entry locked. If the page cache doesn't contain an entry at
   450	 * that index, add a locked empty entry.
   451	 *
   452	 * When requesting an entry with size DAX_PMD, grab_mapping_entry() will
   453	 * either return that locked entry or will return VM_FAULT_FALLBACK.
   454	 * This will happen if there are any PTE entries within the PMD range
   455	 * that we are requesting.
   456	 *
   457	 * We always favor PTE entries over PMD entries. There isn't a flow where we
   458	 * evict PTE entries in order to 'upgrade' them to a PMD entry.  A PMD
   459	 * insertion will fail if it finds any PTE entries already in the tree, and a
   460	 * PTE insertion will cause an existing PMD entry to be unmapped and
   461	 * downgraded to PTE entries.  This happens for both PMD zero pages as
   462	 * well as PMD empty entries.
   463	 *
   464	 * The exception to this downgrade path is for PMD entries that have
   465	 * real storage backing them.  We will leave these real PMD entries in
   466	 * the tree, and PTE writes will simply dirty the entire PMD entry.
   467	 *
   468	 * Note: Unlike filemap_fault() we don't honor FAULT_FLAG_RETRY flags. For
   469	 * persistent memory the benefit is doubtful. We can add that later if we can
   470	 * show it helps.
   471	 *
   472	 * On error, this function does not return an ERR_PTR.  Instead it returns
   473	 * a VM_FAULT code, encoded as an xarray internal entry.  The ERR_PTR values
   474	 * overlap with xarray value entries.
   475	 */
   476	static void *grab_mapping_entry(struct xa_state *xas,
   477			struct address_space *mapping, unsigned int order)
   478	{
   479		unsigned long index = xas->xa_index;
   480		bool pmd_downgrade = false; /* splitting PMD entry into PTE entries? */
   481		int populated;
   482		void *entry;
   483	
   484	retry:
   485		populated = 0;
   486		xas_lock_irq(xas);
   487		entry = get_unlocked_entry(xas, order);
   488	
   489		if (entry) {
   490			if (dax_is_conflict(entry))
   491				goto fallback;
   492			if (!xa_is_value(entry)) {
   493				xas_set_err(xas, EIO);
   494				goto out_unlock;
   495			}
   496	
   497			if (order == 0) {
   498				if (dax_is_pmd_entry(entry) &&
   499				    (dax_is_zero_entry(entry) ||
   500				     dax_is_empty_entry(entry))) {
   501					pmd_downgrade = true;
   502				}
   503			}
   504		}
   505	
   506		if (pmd_downgrade) {
   507			/*
   508			 * Make sure 'entry' remains valid while we drop
   509			 * the i_pages lock.
   510			 */
   511			dax_lock_entry(xas, entry);
   512	
   513			/*
   514			 * Besides huge zero pages the only other thing that gets
   515			 * downgraded are empty entries which don't need to be
   516			 * unmapped.
   517			 */
   518			if (dax_is_zero_entry(entry)) {
   519				xas_unlock_irq(xas);
   520				unmap_mapping_pages(mapping,
   521						xas->xa_index & ~PG_PMD_COLOUR,
   522						PG_PMD_NR, false);
   523				xas_reset(xas);
   524				xas_lock_irq(xas);
   525			}
   526	
   527			dax_disassociate_entry(entry, mapping, false);
   528			xas_store(xas, NULL);	/* undo the PMD join */
   529			dax_wake_entry(xas, entry, true);
   530			mapping->nrexceptional--;
   531			if (mapping_empty(mapping))
   532				populated = -1;
   533			entry = NULL;
   534			xas_set(xas, index);
   535		}
   536	
   537		if (entry) {
   538			dax_lock_entry(xas, entry);
   539		} else {
   540			unsigned long flags = DAX_EMPTY;
   541	
   542			if (order > 0)
   543				flags |= DAX_PMD;
   544			entry = dax_make_entry(pfn_to_pfn_t(0), flags);
   545			dax_lock_entry(xas, entry);
   546			if (xas_error(xas))
   547				goto out_unlock;
   548			if (mapping_empty(mapping))
   549				populated++;
   550			mapping->nrexceptional++;
   551		}
   552	
   553	out_unlock:
   554		xas_unlock_irq(xas);
   555		if (populated == -1)
 > 556			inode_pages_clear(mapping->inode);
   557		else if (populated == 1)
   558			inode_pages_set(mapping->inode);
   559		if (xas_nomem(xas, mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM))
   560			goto retry;
   561		if (xas->xa_node == XA_ERROR(-ENOMEM))
   562			return xa_mk_internal(VM_FAULT_OOM);
   563		if (xas_error(xas))
   564			return xa_mk_internal(VM_FAULT_SIGBUS);
   565		return entry;
   566	fallback:
   567		xas_unlock_irq(xas);
   568		return xa_mk_internal(VM_FAULT_FALLBACK);
   569	}
   570	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 51877 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: kbuild test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
Date: Sat, 15 Feb 2020 00:53:10 +0800	[thread overview]
Message-ID: <202002150049.JtbQNZ7x%lkp@intel.com> (raw)
In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org>

[-- Attachment #1: Type: text/plain, Size: 6217 bytes --]

Hi Johannes,

I love your patch! Yet something to improve:

[auto build test ERROR on vfs/for-next]
[also build test ERROR on linux/master linus/master v5.6-rc1 next-20200213]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Johannes-Weiner/vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-LRU/20200214-083756
base:   https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.5.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.5.0 make.cross ARCH=m68k 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   fs/dax.c: In function 'grab_mapping_entry':
>> fs/dax.c:556:28: error: 'struct address_space' has no member named 'inode'
      inode_pages_clear(mapping->inode);
                               ^~
   fs/dax.c:558:26: error: 'struct address_space' has no member named 'inode'
      inode_pages_set(mapping->inode);
                             ^~

vim +556 fs/dax.c

   446	
   447	/*
   448	 * Find page cache entry at given index. If it is a DAX entry, return it
   449	 * with the entry locked. If the page cache doesn't contain an entry at
   450	 * that index, add a locked empty entry.
   451	 *
   452	 * When requesting an entry with size DAX_PMD, grab_mapping_entry() will
   453	 * either return that locked entry or will return VM_FAULT_FALLBACK.
   454	 * This will happen if there are any PTE entries within the PMD range
   455	 * that we are requesting.
   456	 *
   457	 * We always favor PTE entries over PMD entries. There isn't a flow where we
   458	 * evict PTE entries in order to 'upgrade' them to a PMD entry.  A PMD
   459	 * insertion will fail if it finds any PTE entries already in the tree, and a
   460	 * PTE insertion will cause an existing PMD entry to be unmapped and
   461	 * downgraded to PTE entries.  This happens for both PMD zero pages as
   462	 * well as PMD empty entries.
   463	 *
   464	 * The exception to this downgrade path is for PMD entries that have
   465	 * real storage backing them.  We will leave these real PMD entries in
   466	 * the tree, and PTE writes will simply dirty the entire PMD entry.
   467	 *
   468	 * Note: Unlike filemap_fault() we don't honor FAULT_FLAG_RETRY flags. For
   469	 * persistent memory the benefit is doubtful. We can add that later if we can
   470	 * show it helps.
   471	 *
   472	 * On error, this function does not return an ERR_PTR.  Instead it returns
   473	 * a VM_FAULT code, encoded as an xarray internal entry.  The ERR_PTR values
   474	 * overlap with xarray value entries.
   475	 */
   476	static void *grab_mapping_entry(struct xa_state *xas,
   477			struct address_space *mapping, unsigned int order)
   478	{
   479		unsigned long index = xas->xa_index;
   480		bool pmd_downgrade = false; /* splitting PMD entry into PTE entries? */
   481		int populated;
   482		void *entry;
   483	
   484	retry:
   485		populated = 0;
   486		xas_lock_irq(xas);
   487		entry = get_unlocked_entry(xas, order);
   488	
   489		if (entry) {
   490			if (dax_is_conflict(entry))
   491				goto fallback;
   492			if (!xa_is_value(entry)) {
   493				xas_set_err(xas, EIO);
   494				goto out_unlock;
   495			}
   496	
   497			if (order == 0) {
   498				if (dax_is_pmd_entry(entry) &&
   499				    (dax_is_zero_entry(entry) ||
   500				     dax_is_empty_entry(entry))) {
   501					pmd_downgrade = true;
   502				}
   503			}
   504		}
   505	
   506		if (pmd_downgrade) {
   507			/*
   508			 * Make sure 'entry' remains valid while we drop
   509			 * the i_pages lock.
   510			 */
   511			dax_lock_entry(xas, entry);
   512	
   513			/*
   514			 * Besides huge zero pages the only other thing that gets
   515			 * downgraded are empty entries which don't need to be
   516			 * unmapped.
   517			 */
   518			if (dax_is_zero_entry(entry)) {
   519				xas_unlock_irq(xas);
   520				unmap_mapping_pages(mapping,
   521						xas->xa_index & ~PG_PMD_COLOUR,
   522						PG_PMD_NR, false);
   523				xas_reset(xas);
   524				xas_lock_irq(xas);
   525			}
   526	
   527			dax_disassociate_entry(entry, mapping, false);
   528			xas_store(xas, NULL);	/* undo the PMD join */
   529			dax_wake_entry(xas, entry, true);
   530			mapping->nrexceptional--;
   531			if (mapping_empty(mapping))
   532				populated = -1;
   533			entry = NULL;
   534			xas_set(xas, index);
   535		}
   536	
   537		if (entry) {
   538			dax_lock_entry(xas, entry);
   539		} else {
   540			unsigned long flags = DAX_EMPTY;
   541	
   542			if (order > 0)
   543				flags |= DAX_PMD;
   544			entry = dax_make_entry(pfn_to_pfn_t(0), flags);
   545			dax_lock_entry(xas, entry);
   546			if (xas_error(xas))
   547				goto out_unlock;
   548			if (mapping_empty(mapping))
   549				populated++;
   550			mapping->nrexceptional++;
   551		}
   552	
   553	out_unlock:
   554		xas_unlock_irq(xas);
   555		if (populated == -1)
 > 556			inode_pages_clear(mapping->inode);
   557		else if (populated == 1)
   558			inode_pages_set(mapping->inode);
   559		if (xas_nomem(xas, mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM))
   560			goto retry;
   561		if (xas->xa_node == XA_ERROR(-ENOMEM))
   562			return xa_mk_internal(VM_FAULT_OOM);
   563		if (xas_error(xas))
   564			return xa_mk_internal(VM_FAULT_SIGBUS);
   565		return entry;
   566	fallback:
   567		xas_unlock_irq(xas);
   568		return xa_mk_internal(VM_FAULT_FALLBACK);
   569	}
   570	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 51877 bytes --]

  parent reply	other threads:[~2020-02-14 16:53 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 17:55 [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Johannes Weiner
2020-02-11 18:20 ` Johannes Weiner
2020-02-11 19:05 ` Rik van Riel
2020-02-11 19:05   ` Rik van Riel
2020-02-11 19:31   ` Johannes Weiner
2020-02-11 23:44     ` Andrew Morton
2020-02-12  0:28       ` Linus Torvalds
2020-02-12  0:28         ` Linus Torvalds
2020-02-12  0:47         ` Andrew Morton
2020-02-12  1:03           ` Linus Torvalds
2020-02-12  1:03             ` Linus Torvalds
2020-02-12  1:03             ` Linus Torvalds
2020-02-12  8:50             ` Russell King - ARM Linux admin
2020-02-12  8:50               ` Russell King - ARM Linux admin
2020-02-13  9:50               ` Lucas Stach
2020-02-13  9:50                 ` Lucas Stach
2020-02-13  9:50                 ` Lucas Stach
2020-02-13 16:52               ` Arnd Bergmann
2020-02-13 16:52                 ` Arnd Bergmann
2020-02-13 16:52                 ` Arnd Bergmann
2020-02-15 11:25                 ` Geert Uytterhoeven
2020-02-15 11:25                   ` [cip-dev] " Geert Uytterhoeven
2020-02-15 11:25                   ` Geert Uytterhoeven
2020-02-15 11:25                   ` Geert Uytterhoeven
2020-02-15 16:59                   ` Arnd Bergmann
2020-02-15 16:59                     ` [cip-dev] " Arnd Bergmann
2020-02-15 16:59                     ` Arnd Bergmann
2020-02-15 16:59                     ` Arnd Bergmann
2020-02-16  9:44                     ` Geert Uytterhoeven
2020-02-16  9:44                       ` [cip-dev] " Geert Uytterhoeven
2020-02-16  9:44                       ` Geert Uytterhoeven
2020-02-16  9:44                       ` Geert Uytterhoeven
2020-02-16 19:54                       ` Chris Paterson
2020-02-16 19:54                         ` [cip-dev] " Chris Paterson
2020-02-16 19:54                         ` Chris Paterson
2020-02-16 20:38                         ` Arnd Bergmann
2020-02-16 20:38                           ` [cip-dev] " Arnd Bergmann
2020-02-16 20:38                           ` Arnd Bergmann
2020-02-16 20:38                           ` Arnd Bergmann
2020-02-20 14:35                           ` Chris Paterson
2020-02-20 14:35                             ` [cip-dev] " Chris Paterson
2020-02-20 14:35                             ` Chris Paterson
2020-02-26 18:04                 ` santosh.shilimkar
2020-02-26 18:04                   ` santosh.shilimkar
2020-02-26 21:01                   ` Arnd Bergmann
2020-02-26 21:01                     ` Arnd Bergmann
2020-02-26 21:01                     ` Arnd Bergmann
2020-02-26 21:11                     ` santosh.shilimkar
2020-02-26 21:11                       ` santosh.shilimkar
2020-03-06 20:34                       ` Nishanth Menon
2020-03-06 20:34                         ` Nishanth Menon
2020-03-07  1:08                         ` santosh.shilimkar
2020-03-07  1:08                           ` santosh.shilimkar
2020-03-08 10:58                         ` Arnd Bergmann
2020-03-08 10:58                           ` Arnd Bergmann
2020-03-08 10:58                           ` Arnd Bergmann
2020-03-08 14:19                           ` Russell King - ARM Linux admin
2020-03-08 14:19                             ` Russell King - ARM Linux admin
2020-03-09 13:33                             ` Arnd Bergmann
2020-03-09 13:33                               ` Arnd Bergmann
2020-03-09 13:33                               ` Arnd Bergmann
2020-03-09 14:04                               ` Russell King - ARM Linux admin
2020-03-09 14:04                                 ` Russell King - ARM Linux admin
2020-03-09 15:04                                 ` Arnd Bergmann
2020-03-09 15:04                                   ` Arnd Bergmann
2020-03-09 15:04                                   ` Arnd Bergmann
2020-03-10  9:16                                   ` Michal Hocko
2020-03-10  9:16                                     ` Michal Hocko
2020-03-09 15:59                           ` Catalin Marinas
2020-03-09 15:59                             ` Catalin Marinas
2020-03-09 16:09                             ` Russell King - ARM Linux admin
2020-03-09 16:09                               ` Russell King - ARM Linux admin
2020-03-09 16:57                               ` Catalin Marinas
2020-03-09 16:57                                 ` Catalin Marinas
2020-03-09 19:46                               ` Arnd Bergmann
2020-03-09 19:46                                 ` Arnd Bergmann
2020-03-09 19:46                                 ` Arnd Bergmann
2020-03-11 14:29                                 ` Catalin Marinas
2020-03-11 14:29                                   ` Catalin Marinas
2020-03-11 16:59                                   ` Arnd Bergmann
2020-03-11 16:59                                     ` Arnd Bergmann
2020-03-11 16:59                                     ` Arnd Bergmann
2020-03-11 17:26                                     ` Catalin Marinas
2020-03-11 17:26                                       ` Catalin Marinas
2020-03-11 22:21                                       ` Arnd Bergmann
2020-03-11 22:21                                         ` Arnd Bergmann
2020-03-11 22:21                                         ` Arnd Bergmann
2020-02-12  3:58         ` Matthew Wilcox
2020-02-12  8:09         ` Michal Hocko
2020-02-17 13:31         ` Pavel Machek
2020-02-12 16:35       ` Johannes Weiner
2020-02-12 18:26         ` Andrew Morton
2020-02-12 18:52           ` Johannes Weiner
2020-02-12 12:25 ` Yafang Shao
2020-02-12 12:25   ` Yafang Shao
2020-02-12 16:42   ` Johannes Weiner
2020-02-13  1:47     ` Yafang Shao
2020-02-13  1:47       ` Yafang Shao
2020-02-13 13:46       ` Johannes Weiner
2020-02-14  2:02         ` Yafang Shao
2020-02-14  2:02           ` Yafang Shao
2020-02-13 18:34 ` [PATCH v2] " Johannes Weiner
2020-02-14 16:53 ` kbuild test robot [this message]
2020-02-14 16:53   ` [PATCH] " kbuild test robot
2020-02-14 21:30 ` kbuild test robot
2020-02-14 21:30   ` kbuild test robot
2020-02-14 21:30 ` [PATCH] vfs: fix boolreturn.cocci warnings kbuild test robot
2020-02-14 21:30   ` kbuild test robot
2020-05-12 21:29 ` [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Johannes Weiner
2020-05-13  1:32   ` Yafang Shao
2020-05-13  1:32     ` Yafang Shao
2020-05-13 13:00     ` Johannes Weiner
2020-05-13 21:15   ` Andrew Morton
2020-05-14 11:27     ` Johannes Weiner
2020-05-14  2:24   ` Andrew Morton
2020-05-14 10:37     ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202002150049.JtbQNZ7x%lkp@intel.com \
    --to=lkp@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=kbuild-all@lists.01.org \
    --cc=kernel-team@fb.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.