* [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
@ 2023-08-13 8:17 kernel test robot
2023-08-14 19:47 ` Suren Baghdasaryan
2023-08-14 20:06 ` Andrew Morton
0 siblings, 2 replies; 7+ messages in thread
From: kernel test robot @ 2023-08-13 8:17 UTC (permalink / raw)
To: Matthew Wilcox (Oracle)
Cc: oe-kbuild-all, Andrew Morton, Linux Memory Management List,
Suren Baghdasaryan
tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable
head: 5fb2ea3111f4ecc6dc4891ce5b00f0217aae9a04
commit: 4aaa60dad4d1c96151dec51098aed866bb6e867d [219/240] mm: allow per-VMA locks on file-backed VMAs
config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-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/202308131610.jF4ncWp6-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/build_bug.h:5,
from include/linux/container_of.h:5,
from include/linux/list.h:5,
from include/linux/smp.h:12,
from include/linux/kernel_stat.h:5,
from mm/memory.c:42:
mm/memory.c: In function 'lock_vma_under_rcu':
>> mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? [-Werror=implicit-function-declaration]
5410 | if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
| ^~~~~~~~~~
include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
77 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
cc1: some warnings being treated as errors
vim +5410 mm/memory.c
c2508ec5a58db6 Linus Torvalds 2023-06-15 5382
50ee3253720614 Suren Baghdasaryan 2023-02-27 5383 #ifdef CONFIG_PER_VMA_LOCK
50ee3253720614 Suren Baghdasaryan 2023-02-27 5384 /*
50ee3253720614 Suren Baghdasaryan 2023-02-27 5385 * Lookup and lock a VMA under RCU protection. Returned VMA is guaranteed to be
50ee3253720614 Suren Baghdasaryan 2023-02-27 5386 * stable and not isolated. If the VMA is not found or is being modified the
50ee3253720614 Suren Baghdasaryan 2023-02-27 5387 * function returns NULL.
50ee3253720614 Suren Baghdasaryan 2023-02-27 5388 */
50ee3253720614 Suren Baghdasaryan 2023-02-27 5389 struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
50ee3253720614 Suren Baghdasaryan 2023-02-27 5390 unsigned long address)
50ee3253720614 Suren Baghdasaryan 2023-02-27 5391 {
50ee3253720614 Suren Baghdasaryan 2023-02-27 5392 MA_STATE(mas, &mm->mm_mt, address, address);
50ee3253720614 Suren Baghdasaryan 2023-02-27 5393 struct vm_area_struct *vma;
50ee3253720614 Suren Baghdasaryan 2023-02-27 5394
50ee3253720614 Suren Baghdasaryan 2023-02-27 5395 rcu_read_lock();
50ee3253720614 Suren Baghdasaryan 2023-02-27 5396 retry:
50ee3253720614 Suren Baghdasaryan 2023-02-27 5397 vma = mas_walk(&mas);
50ee3253720614 Suren Baghdasaryan 2023-02-27 5398 if (!vma)
50ee3253720614 Suren Baghdasaryan 2023-02-27 5399 goto inval;
50ee3253720614 Suren Baghdasaryan 2023-02-27 5400
50ee3253720614 Suren Baghdasaryan 2023-02-27 5401 if (!vma_start_read(vma))
50ee3253720614 Suren Baghdasaryan 2023-02-27 5402 goto inval;
50ee3253720614 Suren Baghdasaryan 2023-02-27 5403
657b5146955eba Jann Horn 2023-07-26 5404 /*
657b5146955eba Jann Horn 2023-07-26 5405 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
657b5146955eba Jann Horn 2023-07-26 5406 * This check must happen after vma_start_read(); otherwise, a
657b5146955eba Jann Horn 2023-07-26 5407 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
657b5146955eba Jann Horn 2023-07-26 5408 * from its anon_vma.
657b5146955eba Jann Horn 2023-07-26 5409 */
657b5146955eba Jann Horn 2023-07-26 @5410 if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
657b5146955eba Jann Horn 2023-07-26 5411 goto inval_end_read;
657b5146955eba Jann Horn 2023-07-26 5412
444eeb17437a0e Suren Baghdasaryan 2023-02-27 5413 /*
444eeb17437a0e Suren Baghdasaryan 2023-02-27 5414 * Due to the possibility of userfault handler dropping mmap_lock, avoid
444eeb17437a0e Suren Baghdasaryan 2023-02-27 5415 * it for now and fall back to page fault handling under mmap_lock.
444eeb17437a0e Suren Baghdasaryan 2023-02-27 5416 */
657b5146955eba Jann Horn 2023-07-26 5417 if (userfaultfd_armed(vma))
657b5146955eba Jann Horn 2023-07-26 5418 goto inval_end_read;
444eeb17437a0e Suren Baghdasaryan 2023-02-27 5419
50ee3253720614 Suren Baghdasaryan 2023-02-27 5420 /* Check since vm_start/vm_end might change before we lock the VMA */
657b5146955eba Jann Horn 2023-07-26 5421 if (unlikely(address < vma->vm_start || address >= vma->vm_end))
657b5146955eba Jann Horn 2023-07-26 5422 goto inval_end_read;
50ee3253720614 Suren Baghdasaryan 2023-02-27 5423
50ee3253720614 Suren Baghdasaryan 2023-02-27 5424 /* Check if the VMA got isolated after we found it */
50ee3253720614 Suren Baghdasaryan 2023-02-27 5425 if (vma->detached) {
50ee3253720614 Suren Baghdasaryan 2023-02-27 5426 vma_end_read(vma);
52f238653e452e Suren Baghdasaryan 2023-02-27 5427 count_vm_vma_lock_event(VMA_LOCK_MISS);
50ee3253720614 Suren Baghdasaryan 2023-02-27 5428 /* The area was replaced with another one */
50ee3253720614 Suren Baghdasaryan 2023-02-27 5429 goto retry;
50ee3253720614 Suren Baghdasaryan 2023-02-27 5430 }
50ee3253720614 Suren Baghdasaryan 2023-02-27 5431
50ee3253720614 Suren Baghdasaryan 2023-02-27 5432 rcu_read_unlock();
50ee3253720614 Suren Baghdasaryan 2023-02-27 5433 return vma;
657b5146955eba Jann Horn 2023-07-26 5434
657b5146955eba Jann Horn 2023-07-26 5435 inval_end_read:
657b5146955eba Jann Horn 2023-07-26 5436 vma_end_read(vma);
50ee3253720614 Suren Baghdasaryan 2023-02-27 5437 inval:
50ee3253720614 Suren Baghdasaryan 2023-02-27 5438 rcu_read_unlock();
52f238653e452e Suren Baghdasaryan 2023-02-27 5439 count_vm_vma_lock_event(VMA_LOCK_ABORT);
50ee3253720614 Suren Baghdasaryan 2023-02-27 5440 return NULL;
50ee3253720614 Suren Baghdasaryan 2023-02-27 5441 }
50ee3253720614 Suren Baghdasaryan 2023-02-27 5442 #endif /* CONFIG_PER_VMA_LOCK */
50ee3253720614 Suren Baghdasaryan 2023-02-27 5443
:::::: The code at line 5410 was first introduced by commit
:::::: 657b5146955eba331e01b9a6ae89ce2e716ba306 mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock
:::::: TO: Jann Horn <jannh@google.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
2023-08-13 8:17 [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? kernel test robot
@ 2023-08-14 19:47 ` Suren Baghdasaryan
2023-08-14 20:06 ` Andrew Morton
1 sibling, 0 replies; 7+ messages in thread
From: Suren Baghdasaryan @ 2023-08-14 19:47 UTC (permalink / raw)
To: kernel test robot
Cc: Matthew Wilcox (Oracle),
oe-kbuild-all, Andrew Morton, Linux Memory Management List
On Sun, Aug 13, 2023 at 1:17 AM kernel test robot <lkp@intel.com> wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable
> head: 5fb2ea3111f4ecc6dc4891ce5b00f0217aae9a04
> commit: 4aaa60dad4d1c96151dec51098aed866bb6e867d [219/240] mm: allow per-VMA locks on file-backed VMAs
> config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce: (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-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/202308131610.jF4ncWp6-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/build_bug.h:5,
> from include/linux/container_of.h:5,
> from include/linux/list.h:5,
> from include/linux/smp.h:12,
> from include/linux/kernel_stat.h:5,
> from mm/memory.c:42:
> mm/memory.c: In function 'lock_vma_under_rcu':
> >> mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? [-Werror=implicit-function-declaration]
> 5410 | if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> | ^~~~~~~~~~
> include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
> 77 | # define unlikely(x) __builtin_expect(!!(x), 0)
> | ^
> cc1: some warnings being treated as errors
Same issue as https://lore.kernel.org/all/202308121909.XNYBtqNI-lkp@intel.com/
with the same fix that Matthew suggested.
>
>
> vim +5410 mm/memory.c
>
> c2508ec5a58db6 Linus Torvalds 2023-06-15 5382
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5383 #ifdef CONFIG_PER_VMA_LOCK
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5384 /*
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5385 * Lookup and lock a VMA under RCU protection. Returned VMA is guaranteed to be
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5386 * stable and not isolated. If the VMA is not found or is being modified the
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5387 * function returns NULL.
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5388 */
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5389 struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5390 unsigned long address)
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5391 {
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5392 MA_STATE(mas, &mm->mm_mt, address, address);
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5393 struct vm_area_struct *vma;
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5394
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5395 rcu_read_lock();
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5396 retry:
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5397 vma = mas_walk(&mas);
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5398 if (!vma)
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5399 goto inval;
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5400
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5401 if (!vma_start_read(vma))
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5402 goto inval;
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5403
> 657b5146955eba Jann Horn 2023-07-26 5404 /*
> 657b5146955eba Jann Horn 2023-07-26 5405 * find_mergeable_anon_vma uses adjacent vmas which are not locked.
> 657b5146955eba Jann Horn 2023-07-26 5406 * This check must happen after vma_start_read(); otherwise, a
> 657b5146955eba Jann Horn 2023-07-26 5407 * concurrent mremap() with MREMAP_DONTUNMAP could dissociate the VMA
> 657b5146955eba Jann Horn 2023-07-26 5408 * from its anon_vma.
> 657b5146955eba Jann Horn 2023-07-26 5409 */
> 657b5146955eba Jann Horn 2023-07-26 @5410 if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> 657b5146955eba Jann Horn 2023-07-26 5411 goto inval_end_read;
> 657b5146955eba Jann Horn 2023-07-26 5412
> 444eeb17437a0e Suren Baghdasaryan 2023-02-27 5413 /*
> 444eeb17437a0e Suren Baghdasaryan 2023-02-27 5414 * Due to the possibility of userfault handler dropping mmap_lock, avoid
> 444eeb17437a0e Suren Baghdasaryan 2023-02-27 5415 * it for now and fall back to page fault handling under mmap_lock.
> 444eeb17437a0e Suren Baghdasaryan 2023-02-27 5416 */
> 657b5146955eba Jann Horn 2023-07-26 5417 if (userfaultfd_armed(vma))
> 657b5146955eba Jann Horn 2023-07-26 5418 goto inval_end_read;
> 444eeb17437a0e Suren Baghdasaryan 2023-02-27 5419
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5420 /* Check since vm_start/vm_end might change before we lock the VMA */
> 657b5146955eba Jann Horn 2023-07-26 5421 if (unlikely(address < vma->vm_start || address >= vma->vm_end))
> 657b5146955eba Jann Horn 2023-07-26 5422 goto inval_end_read;
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5423
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5424 /* Check if the VMA got isolated after we found it */
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5425 if (vma->detached) {
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5426 vma_end_read(vma);
> 52f238653e452e Suren Baghdasaryan 2023-02-27 5427 count_vm_vma_lock_event(VMA_LOCK_MISS);
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5428 /* The area was replaced with another one */
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5429 goto retry;
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5430 }
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5431
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5432 rcu_read_unlock();
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5433 return vma;
> 657b5146955eba Jann Horn 2023-07-26 5434
> 657b5146955eba Jann Horn 2023-07-26 5435 inval_end_read:
> 657b5146955eba Jann Horn 2023-07-26 5436 vma_end_read(vma);
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5437 inval:
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5438 rcu_read_unlock();
> 52f238653e452e Suren Baghdasaryan 2023-02-27 5439 count_vm_vma_lock_event(VMA_LOCK_ABORT);
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5440 return NULL;
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5441 }
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5442 #endif /* CONFIG_PER_VMA_LOCK */
> 50ee3253720614 Suren Baghdasaryan 2023-02-27 5443
>
> :::::: The code at line 5410 was first introduced by commit
> :::::: 657b5146955eba331e01b9a6ae89ce2e716ba306 mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock
>
> :::::: TO: Jann Horn <jannh@google.com>
> :::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
2023-08-13 8:17 [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? kernel test robot
2023-08-14 19:47 ` Suren Baghdasaryan
@ 2023-08-14 20:06 ` Andrew Morton
2023-08-14 20:09 ` Suren Baghdasaryan
1 sibling, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2023-08-14 20:06 UTC (permalink / raw)
To: kernel test robot
Cc: Matthew Wilcox (Oracle),
oe-kbuild-all, Linux Memory Management List, Suren Baghdasaryan
On Sun, 13 Aug 2023 16:17:21 +0800 kernel test robot <lkp@intel.com> wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable
> head: 5fb2ea3111f4ecc6dc4891ce5b00f0217aae9a04
> commit: 4aaa60dad4d1c96151dec51098aed866bb6e867d [219/240] mm: allow per-VMA locks on file-backed VMAs
> config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce: (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-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/202308131610.jF4ncWp6-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/build_bug.h:5,
> from include/linux/container_of.h:5,
> from include/linux/list.h:5,
> from include/linux/smp.h:12,
> from include/linux/kernel_stat.h:5,
> from mm/memory.c:42:
> mm/memory.c: In function 'lock_vma_under_rcu':
> >> mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? [-Werror=implicit-function-declaration]
> 5410 | if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> | ^~~~~~~~~~
> include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
> 77 | # define unlikely(x) __builtin_expect(!!(x), 0)
> | ^
> cc1: some warnings being treated as errors
>
This later gets accidentally fixed by Suren's "mm: handle userfaults
under VMA lock".
If Matthew can suggest a fix for this I can queue it close to "mm:
allow per-VMA locks on file-backed VMAs" to minimize the size of the
bisection hole?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
2023-08-14 20:06 ` Andrew Morton
@ 2023-08-14 20:09 ` Suren Baghdasaryan
2023-08-14 20:33 ` Suren Baghdasaryan
0 siblings, 1 reply; 7+ messages in thread
From: Suren Baghdasaryan @ 2023-08-14 20:09 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel test robot, Matthew Wilcox (Oracle),
oe-kbuild-all, Linux Memory Management List
On Mon, Aug 14, 2023 at 1:06 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Sun, 13 Aug 2023 16:17:21 +0800 kernel test robot <lkp@intel.com> wrote:
>
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable
> > head: 5fb2ea3111f4ecc6dc4891ce5b00f0217aae9a04
> > commit: 4aaa60dad4d1c96151dec51098aed866bb6e867d [219/240] mm: allow per-VMA locks on file-backed VMAs
> > config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-lkp@intel.com/config)
> > compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> > reproduce: (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-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/202308131610.jF4ncWp6-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> > In file included from include/linux/build_bug.h:5,
> > from include/linux/container_of.h:5,
> > from include/linux/list.h:5,
> > from include/linux/smp.h:12,
> > from include/linux/kernel_stat.h:5,
> > from mm/memory.c:42:
> > mm/memory.c: In function 'lock_vma_under_rcu':
> > >> mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? [-Werror=implicit-function-declaration]
> > 5410 | if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > | ^~~~~~~~~~
> > include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
> > 77 | # define unlikely(x) __builtin_expect(!!(x), 0)
> > | ^
> > cc1: some warnings being treated as errors
> >
>
> This later gets accidentally fixed by Suren's "mm: handle userfaults
> under VMA lock".
>
> If Matthew can suggest a fix for this I can queue it close to "mm:
> allow per-VMA locks on file-backed VMAs" to minimize the size of the
> bisection hole?
I thought Matthew's suggestion here
https://lore.kernel.org/all/ZNerqcNS4EBJA%2F2v@casper.infradead.org/
would fix this. Dos it not?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
2023-08-14 20:09 ` Suren Baghdasaryan
@ 2023-08-14 20:33 ` Suren Baghdasaryan
2023-08-14 20:41 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Suren Baghdasaryan @ 2023-08-14 20:33 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel test robot, Matthew Wilcox (Oracle),
oe-kbuild-all, Linux Memory Management List
On Mon, Aug 14, 2023 at 1:09 PM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Mon, Aug 14, 2023 at 1:06 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Sun, 13 Aug 2023 16:17:21 +0800 kernel test robot <lkp@intel.com> wrote:
> >
> > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable
> > > head: 5fb2ea3111f4ecc6dc4891ce5b00f0217aae9a04
> > > commit: 4aaa60dad4d1c96151dec51098aed866bb6e867d [219/240] mm: allow per-VMA locks on file-backed VMAs
> > > config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-lkp@intel.com/config)
> > > compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> > > reproduce: (https://download.01.org/0day-ci/archive/20230813/202308131610.jF4ncWp6-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/202308131610.jF4ncWp6-lkp@intel.com/
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > In file included from include/linux/build_bug.h:5,
> > > from include/linux/container_of.h:5,
> > > from include/linux/list.h:5,
> > > from include/linux/smp.h:12,
> > > from include/linux/kernel_stat.h:5,
> > > from mm/memory.c:42:
> > > mm/memory.c: In function 'lock_vma_under_rcu':
> > > >> mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? [-Werror=implicit-function-declaration]
> > > 5410 | if (unlikely(!vma->anon_vma && !vma_is_tcp(vma)))
> > > | ^~~~~~~~~~
> > > include/linux/compiler.h:77:45: note: in definition of macro 'unlikely'
> > > 77 | # define unlikely(x) __builtin_expect(!!(x), 0)
> > > | ^
> > > cc1: some warnings being treated as errors
> > >
> >
> > This later gets accidentally fixed by Suren's "mm: handle userfaults
> > under VMA lock".
Andrew, is "mm: handle userfaults under VMA lock" merged into
mm-stable? I could not find it and in fact the whole "Per-VMA lock
support for swap and userfaults" patchset
(https://lore.kernel.org/all/CAJuCfpHSFikZ=h34yS980BmUP5M=+j6rB4_b-q7MCc10Xs24+w@mail.gmail.com/)
seems to be missing in mm-stable. That's problematic because Matthew's
"Handle most file-backed faults under the VMA lock" patchset
(https://lore.kernel.org/all/20230724185410.1124082-1-willy@infradead.org/)
requires at least one patch from my patchset to work correctly, this
one: https://lore.kernel.org/all/20230630211957.1341547-4-surenb@google.com/.
An additional note,
https://lore.kernel.org/all/20230812002033.1002367-1-willy@infradead.org/
is fixing a known issue in "Handle most file-backed faults under the
VMA lock" patchset and it's missing from mm-stable too. As Matthew
mentioned in that patch, ideally it should be placed before "mm:
handle faults that merely update the accessed bit under the VMA lock"
Thanks,
Suren.
> >
> > If Matthew can suggest a fix for this I can queue it close to "mm:
> > allow per-VMA locks on file-backed VMAs" to minimize the size of the
> > bisection hole?
>
> I thought Matthew's suggestion here
> https://lore.kernel.org/all/ZNerqcNS4EBJA%2F2v@casper.infradead.org/
> would fix this. Dos it not?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
2023-08-14 20:33 ` Suren Baghdasaryan
@ 2023-08-14 20:41 ` Andrew Morton
2023-08-14 20:55 ` Suren Baghdasaryan
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2023-08-14 20:41 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: kernel test robot, Matthew Wilcox (Oracle),
oe-kbuild-all, Linux Memory Management List
On Mon, 14 Aug 2023 13:33:19 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
> Andrew, is "mm: handle userfaults under VMA lock" merged into
> mm-stable? I could not find it and in fact the whole "Per-VMA lock
> support for swap and userfaults" patchset
> (https://lore.kernel.org/all/CAJuCfpHSFikZ=h34yS980BmUP5M=+j6rB4_b-q7MCc10Xs24+w@mail.gmail.com/)
> seems to be missing in mm-stable. That's problematic because Matthew's
> "Handle most file-backed faults under the VMA lock" patchset
> (https://lore.kernel.org/all/20230724185410.1124082-1-willy@infradead.org/)
> requires at least one patch from my patchset to work correctly, this
> one: https://lore.kernel.org/all/20230630211957.1341547-4-surenb@google.com/.
>
> An additional note,
> https://lore.kernel.org/all/20230812002033.1002367-1-willy@infradead.org/
> is fixing a known issue in "Handle most file-backed faults under the
> VMA lock" patchset and it's missing from mm-stable too. As Matthew
> mentioned in that patch, ideally it should be placed before "mm:
> handle faults that merely update the accessed bit under the VMA lock"
>
I was unaware of these dependencies.
All the above-mentioned patches are in mm-unstable, so we have
bisection holes.
If I get sent a replacement patch series, I'll move it to
back-of-queue, because I'll assume all previous testing is invalidated.
I assume this is how this misordering came about. If I get sent
little -fix patches, I don't do this reordering.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'?
2023-08-14 20:41 ` Andrew Morton
@ 2023-08-14 20:55 ` Suren Baghdasaryan
0 siblings, 0 replies; 7+ messages in thread
From: Suren Baghdasaryan @ 2023-08-14 20:55 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel test robot, Matthew Wilcox (Oracle),
oe-kbuild-all, Linux Memory Management List
On Mon, Aug 14, 2023 at 1:41 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 14 Aug 2023 13:33:19 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
>
> > Andrew, is "mm: handle userfaults under VMA lock" merged into
> > mm-stable? I could not find it and in fact the whole "Per-VMA lock
> > support for swap and userfaults" patchset
> > (https://lore.kernel.org/all/CAJuCfpHSFikZ=h34yS980BmUP5M=+j6rB4_b-q7MCc10Xs24+w@mail.gmail.com/)
> > seems to be missing in mm-stable. That's problematic because Matthew's
> > "Handle most file-backed faults under the VMA lock" patchset
> > (https://lore.kernel.org/all/20230724185410.1124082-1-willy@infradead.org/)
> > requires at least one patch from my patchset to work correctly, this
> > one: https://lore.kernel.org/all/20230630211957.1341547-4-surenb@google.com/.
> >
> > An additional note,
> > https://lore.kernel.org/all/20230812002033.1002367-1-willy@infradead.org/
> > is fixing a known issue in "Handle most file-backed faults under the
> > VMA lock" patchset and it's missing from mm-stable too. As Matthew
> > mentioned in that patch, ideally it should be placed before "mm:
> > handle faults that merely update the accessed bit under the VMA lock"
> >
>
> I was unaware of these dependencies.
I didn't notice the reordering in mm-unstable but now I see them
reordered there as well. Should have warned you earlier :(
>
> All the above-mentioned patches are in mm-unstable, so we have
> bisection holes.
>
> If I get sent a replacement patch series, I'll move it to
> back-of-queue, because I'll assume all previous testing is invalidated.
> I assume this is how this misordering came about. If I get sent
> little -fix patches, I don't do this reordering.
Possibly the recent riscv fixup for my patch series reordered things...
Reordering my patchset before Matthew's would fix that bisection hole
but up to you. I was just worried that if one patchset is merged
without the other, this hole would produce multiple issues.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-08-14 20:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-13 8:17 [akpm-mm:mm-stable 219/240] mm/memory.c:5410:41: error: implicit declaration of function 'vma_is_tcp'; did you mean 'vma_is_dax'? kernel test robot
2023-08-14 19:47 ` Suren Baghdasaryan
2023-08-14 20:06 ` Andrew Morton
2023-08-14 20:09 ` Suren Baghdasaryan
2023-08-14 20:33 ` Suren Baghdasaryan
2023-08-14 20:41 ` Andrew Morton
2023-08-14 20:55 ` Suren Baghdasaryan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox