From: kernel test robot <lkp@intel.com>
To: Peter Xu <peterx@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
LKML <linux-kernel@vger.kernel.org>,
Andrew Lutomirski <luto@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Josef Bacik <josef@toxicpanda.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-fsdevel@vger.kernel.org, Dan Carpenter <error27@gmail.com>,
syzbot+48011b86c8ea329af1b9@syzkaller.appspotmail.com,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 1/3] mm: handle_mm_fault_one()
Date: Fri, 12 May 2023 11:28:57 +0800 [thread overview]
Message-ID: <202305121114.JAbwVHjS-lkp@intel.com> (raw)
In-Reply-To: <ZF2E6i4pqJr7m436@x1n>
Hi Peter,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/Peter-Xu/mm-handle_mm_fault_one/20230512-081554
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/ZF2E6i4pqJr7m436%40x1n
patch subject: [PATCH 1/3] mm: handle_mm_fault_one()
config: x86_64-randconfig-a014 (https://download.01.org/0day-ci/archive/20230512/202305121114.JAbwVHjS-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
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://github.com/intel-lab-lkp/linux/commit/0a03a4870c8a62e3ba52a0f9b50b307f509acb2b
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Peter-Xu/mm-handle_mm_fault_one/20230512-081554
git checkout 0a03a4870c8a62e3ba52a0f9b50b307f509acb2b
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 prepare
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202305121114.JAbwVHjS-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/x86/kernel/asm-offsets.c:14:
In file included from include/linux/suspend.h:5:
In file included from include/linux/swap.h:9:
In file included from include/linux/memcontrol.h:20:
>> include/linux/mm.h:2371:6: error: use of undeclared identifier 'fault'
if (fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED))
^
>> include/linux/mm.h:2396:20: error: use of undeclared identifier 'mm'
mmap_read_unlock(mm);
^
2 errors generated.
make[2]: *** [scripts/Makefile.build:114: arch/x86/kernel/asm-offsets.s] Error 1
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:1287: prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:226: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +/fault +2371 include/linux/mm.h
2362
2363 static inline bool
2364 mm_should_release_mmap(unsigned long flags, vm_fault_t retval)
2365 {
2366 /* The caller explicitly requested to keep the mmap read lock */
2367 if (flags & FAULT_FLAG_RETRY_NOWAIT)
2368 return false;
2369
2370 /* If the mmap read lock is already released, we're all good */
> 2371 if (fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED))
2372 return false;
2373
2374 /* Otherwise always release it */
2375 return true;
2376 }
2377
2378 /*
2379 * This is mostly handle_mm_fault(), but it also take care of releasing
2380 * mmap or vma read lock as long as possible (e.g. when !RETRY_NOWAIT).
2381 *
2382 * Normally it's the case when we got a hardware page fault, where we want
2383 * to release the lock right after the page fault. And it's not for case
2384 * like GUP where it can fault a range of pages continuously with mmap lock
2385 * being held during the process.
2386 */
2387 static inline vm_fault_t
2388 handle_mm_fault_one(struct vm_area_struct *vma, unsigned long address,
2389 unsigned int flags, struct pt_regs *regs)
2390 {
2391 vm_fault_t retval = handle_mm_fault(vma, address, flags, regs);
2392
2393 if (flags & FAULT_FLAG_VMA_LOCK)
2394 vma_end_read(vma);
2395 else if (mm_should_release_mmap(flags, retval))
> 2396 mmap_read_unlock(mm);
2397
2398 return retval;
2399 }
2400
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
next prev parent reply other threads:[~2023-05-12 3:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-06 16:04 [PATCH] filemap: Handle error return from __filemap_get_folio() Matthew Wilcox (Oracle)
2023-05-06 16:09 ` Linus Torvalds
2023-05-06 16:35 ` Linus Torvalds
2023-05-06 17:04 ` Linus Torvalds
2023-05-06 17:10 ` Linus Torvalds
2023-05-06 17:34 ` Linus Torvalds
2023-05-06 17:41 ` Andrew Morton
2023-05-08 13:56 ` Dan Carpenter
2023-05-09 7:43 ` Dan Carpenter
2023-05-09 17:37 ` Linus Torvalds
2023-05-09 20:49 ` Christoph Hellwig
2023-05-11 9:44 ` Dan Carpenter
2023-05-09 19:19 ` Johannes Weiner
2023-05-10 20:27 ` Peter Xu
2023-05-10 21:33 ` Linus Torvalds
2023-05-10 21:44 ` Linus Torvalds
2023-05-11 4:45 ` Peter Xu
2023-05-12 0:14 ` Peter Xu
2023-05-12 3:28 ` kernel test robot [this message]
2023-05-12 3:52 ` [PATCH 1/3] mm: handle_mm_fault_one() kernel test robot
2023-05-12 3:52 ` kernel test robot
2023-05-12 4:49 ` kernel test robot
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=202305121114.JAbwVHjS-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=error27@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=luto@kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=peterx@redhat.com \
--cc=syzbot+48011b86c8ea329af1b9@syzkaller.appspotmail.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/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.