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: <202009270850.DNoD6AzQ%lkp@intel.com>
Date:   Sun, 27 Sep 2020 08:55:03 +0800
From:   kernel test robot <lkp@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     kbuild-all@...ts.01.org, clang-built-linux@...glegroups.com,
        linux-kernel@...r.kernel.org,
        "Paul E. McKenney" <paulmck@...nel.org>
Subject: [rcu:urezki-pcount.2020.09.26a 5/17] include/linux/pagemap.h:181:2:
 error: called object type 'void' is not a function or function pointer

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git urezki-pcount.2020.09.26a
head:   e9bed2a1239b017d78cec5de66adce0560f6d077
commit: 2fa3b3dd18ef5ef28a9dd40f6711211c62ac929b [5/17] mm/pagemap: Cleanup PREEMPT_COUNT leftovers
config: x86_64-randconfig-a002-20200927 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project a83eb048cb9a75da7a07a9d5318bbdbf54885c87)
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
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?id=2fa3b3dd18ef5ef28a9dd40f6711211c62ac929b
        git remote add rcu https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
        git fetch --no-tags rcu urezki-pcount.2020.09.26a
        git checkout 2fa3b3dd18ef5ef28a9dd40f6711211c62ac929b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/asm-offsets.c:13:
   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:22:
   In file included from include/linux/writeback.h:14:
   In file included from include/linux/blk-cgroup.h:23:
   In file included from include/linux/blkdev.h:13:
>> include/linux/pagemap.h:181:2: error: called object type 'void' is not a function or function pointer
           VM_BUG_ON_PAGE(page_count(page) == 0, page);
           ^
   include/linux/mmdebug.h:46:36: note: expanded from macro 'VM_BUG_ON_PAGE'
   #define VM_BUG_ON_PAGE(cond, page) VM_BUG_ON(cond)
                                      ^
   include/linux/mmdebug.h:45:25: note: expanded from macro 'VM_BUG_ON'
   #define VM_BUG_ON(cond) BUILD_BUG_ON_INVALID(cond)
                           ^
   include/linux/build_bug.h:30:33: note: expanded from macro 'BUILD_BUG_ON_INVALID'
   #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
                                   ^
   1 error generated.
   make[2]: *** [scripts/Makefile.build:117: arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1198: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:185: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.

vim +/void +181 include/linux/pagemap.h

^1da177e4c3f41 Linus Torvalds         2005-04-16  123  
e286781d5f2e9c Nick Piggin            2008-07-25  124  /*
e286781d5f2e9c Nick Piggin            2008-07-25  125   * speculatively take a reference to a page.
0139aa7b7fa12c Joonsoo Kim            2016-05-19  126   * If the page is free (_refcount == 0), then _refcount is untouched, and 0
0139aa7b7fa12c Joonsoo Kim            2016-05-19  127   * is returned. Otherwise, _refcount is incremented by 1 and 1 is returned.
e286781d5f2e9c Nick Piggin            2008-07-25  128   *
e286781d5f2e9c Nick Piggin            2008-07-25  129   * This function must be called inside the same rcu_read_lock() section as has
e286781d5f2e9c Nick Piggin            2008-07-25  130   * been used to lookup the page in the pagecache radix-tree (or page table):
0139aa7b7fa12c Joonsoo Kim            2016-05-19  131   * this allows allocators to use a synchronize_rcu() to stabilize _refcount.
e286781d5f2e9c Nick Piggin            2008-07-25  132   *
e286781d5f2e9c Nick Piggin            2008-07-25  133   * Unless an RCU grace period has passed, the count of all pages coming out
e286781d5f2e9c Nick Piggin            2008-07-25  134   * of the allocator must be considered unstable. page_count may return higher
e286781d5f2e9c Nick Piggin            2008-07-25  135   * than expected, and put_page must be able to do the right thing when the
e286781d5f2e9c Nick Piggin            2008-07-25  136   * page has been finished with, no matter what it is subsequently allocated
e286781d5f2e9c Nick Piggin            2008-07-25  137   * for (because put_page is what is used here to drop an invalid speculative
e286781d5f2e9c Nick Piggin            2008-07-25  138   * reference).
e286781d5f2e9c Nick Piggin            2008-07-25  139   *
e286781d5f2e9c Nick Piggin            2008-07-25  140   * This is the interesting part of the lockless pagecache (and lockless
e286781d5f2e9c Nick Piggin            2008-07-25  141   * get_user_pages) locking protocol, where the lookup-side (eg. find_get_page)
e286781d5f2e9c Nick Piggin            2008-07-25  142   * has the following pattern:
e286781d5f2e9c Nick Piggin            2008-07-25  143   * 1. find page in radix tree
e286781d5f2e9c Nick Piggin            2008-07-25  144   * 2. conditionally increment refcount
e286781d5f2e9c Nick Piggin            2008-07-25  145   * 3. check the page is still in pagecache (if no, goto 1)
e286781d5f2e9c Nick Piggin            2008-07-25  146   *
0139aa7b7fa12c Joonsoo Kim            2016-05-19  147   * Remove-side that cares about stability of _refcount (eg. reclaim) has the
b93b016313b3ba Matthew Wilcox         2018-04-10  148   * following (with the i_pages lock held):
e286781d5f2e9c Nick Piggin            2008-07-25  149   * A. atomically check refcount is correct and set it to 0 (atomic_cmpxchg)
e286781d5f2e9c Nick Piggin            2008-07-25  150   * B. remove page from pagecache
e286781d5f2e9c Nick Piggin            2008-07-25  151   * C. free the page
e286781d5f2e9c Nick Piggin            2008-07-25  152   *
e286781d5f2e9c Nick Piggin            2008-07-25  153   * There are 2 critical interleavings that matter:
e286781d5f2e9c Nick Piggin            2008-07-25  154   * - 2 runs before A: in this case, A sees elevated refcount and bails out
e286781d5f2e9c Nick Piggin            2008-07-25  155   * - A runs before 2: in this case, 2 sees zero refcount and retries;
e286781d5f2e9c Nick Piggin            2008-07-25  156   *   subsequently, B will complete and 1 will find no page, causing the
e286781d5f2e9c Nick Piggin            2008-07-25  157   *   lookup to return NULL.
e286781d5f2e9c Nick Piggin            2008-07-25  158   *
e286781d5f2e9c Nick Piggin            2008-07-25  159   * It is possible that between 1 and 2, the page is removed then the exact same
e286781d5f2e9c Nick Piggin            2008-07-25  160   * page is inserted into the same position in pagecache. That's OK: the
b93b016313b3ba Matthew Wilcox         2018-04-10  161   * old find_get_page using a lock could equally have run before or after
e286781d5f2e9c Nick Piggin            2008-07-25  162   * such a re-insertion, depending on order that locks are granted.
e286781d5f2e9c Nick Piggin            2008-07-25  163   *
e286781d5f2e9c Nick Piggin            2008-07-25  164   * Lookups racing against pagecache insertion isn't a big problem: either 1
e286781d5f2e9c Nick Piggin            2008-07-25  165   * will find the page or it will not. Likewise, the old find_get_page could run
e286781d5f2e9c Nick Piggin            2008-07-25  166   * either before the insertion or afterwards, depending on timing.
e286781d5f2e9c Nick Piggin            2008-07-25  167   */
494eec70f05496 john.hubbard@...il.com 2019-03-05  168  static inline int __page_cache_add_speculative(struct page *page, int count)
e286781d5f2e9c Nick Piggin            2008-07-25  169  {
8375ad98cc1def Paul E. McKenney       2013-04-29  170  #ifdef CONFIG_TINY_RCU
2fa3b3dd18ef5e Thomas Gleixner        2020-09-14  171  	VM_BUG_ON(preemptible())
e286781d5f2e9c Nick Piggin            2008-07-25  172  	/*
e286781d5f2e9c Nick Piggin            2008-07-25  173  	 * Preempt must be disabled here - we rely on rcu_read_lock doing
e286781d5f2e9c Nick Piggin            2008-07-25  174  	 * this for us.
e286781d5f2e9c Nick Piggin            2008-07-25  175  	 *
e286781d5f2e9c Nick Piggin            2008-07-25  176  	 * Pagecache won't be truncated from interrupt context, so if we have
e286781d5f2e9c Nick Piggin            2008-07-25  177  	 * found a page in the radix tree here, we have pinned its refcount by
e286781d5f2e9c Nick Piggin            2008-07-25  178  	 * disabling preempt, and hence no need for the "speculative get" that
e286781d5f2e9c Nick Piggin            2008-07-25  179  	 * SMP requires.
e286781d5f2e9c Nick Piggin            2008-07-25  180  	 */
309381feaee564 Sasha Levin            2014-01-23 @181  	VM_BUG_ON_PAGE(page_count(page) == 0, page);
494eec70f05496 john.hubbard@...il.com 2019-03-05  182  	page_ref_add(page, count);
e286781d5f2e9c Nick Piggin            2008-07-25  183  

:::::: The code at line 181 was first introduced by commit
:::::: 309381feaee564281c3d9e90fbca8963bb7428ad mm: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE

:::::: TO: Sasha Levin <sasha.levin@...cle.com>
:::::: CC: Linus Torvalds <torvalds@...ux-foundation.org>

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

Download attachment ".config.gz" of type "application/gzip" (30295 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ