From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A525C678DB for ; Sat, 4 Mar 2023 14:03:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 598176B0072; Sat, 4 Mar 2023 09:03:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 547C76B0073; Sat, 4 Mar 2023 09:03:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E88D6B0074; Sat, 4 Mar 2023 09:03:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2E5ED6B0072 for ; Sat, 4 Mar 2023 09:03:02 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DC733C09F6 for ; Sat, 4 Mar 2023 14:03:01 +0000 (UTC) X-FDA: 80531382162.25.91C9FED Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf22.hostedemail.com (Postfix) with ESMTP id 27ED3C001B for ; Sat, 4 Mar 2023 14:02:57 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=XlqBQJzA; spf=pass (imf22.hostedemail.com: domain of lkp@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=lkp@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677938580; a=rsa-sha256; cv=none; b=gsgiovAuki+ek1DFEo+53ARe2/SYr6bc5RC4e6oZstijZa8Tgt+LTXVD4/cxBqvzHvexD9 GSeshRc7fGWp4x0dg8wm2eOHTpfHKgLhSUcBCAOUMwanCNELK9QtxynrFbZ6f0RPYUoyY5 hekgHMU/N8loEcouEvfO3g1cEhSsSNA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=XlqBQJzA; spf=pass (imf22.hostedemail.com: domain of lkp@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=lkp@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677938580; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=MwfaqjDiyplRAezLM+LrhYnow9eBlPcPv4XRRwczZ3A=; b=Qrv970uDAfCPiV5DQKuwfwylQwyN+b4u3wvgu5iCZESza2W+FziznPtVVctUg5rLqi6wJM +aXhtSDxwz+t9NoO3EjfpHDMAMM+GhdanDOKI5kiRWtIkUfLMipX91eaCf9hzNlOurzkoN 6udHDEDLNzsintl+zz+Gtb8c/mwO6Cc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1677938578; x=1709474578; h=date:from:to:cc:subject:message-id:mime-version; bh=uOFv4OKBE54zZEDErhYTE0rWOKCJekwkXCpp2YrA4U4=; b=XlqBQJzAzudLJgnkbtW71gF3h83v1ELwtIQ7Gd3aceie5ysnKp0NzJio WGoP9HDzV/tVjAp8NxVHuLgfzwG7t3C++0oCfkzB631icpGavoH90Ygxq QhaQvf1sOKVFOSUJ+vJnhOqFq2awUkFQ1NOAoeOcVUUzYB5T3nSHtQ00Q kSM/5i8pTGmoeptnUi3Riz8qZQBsWC0ZHJ19ahff+l2NWm+WGVPG9IWDN qQxQR3fTjpgwqucuqoBm6aI/iZzIvZE4omSfCdKC/hpIRnbBSEDcdyn7q URUysdPbVe8DGQCXEIYof+NyUxdUQMDNrEZAz7C5eSSUv69hMn+Fnaln5 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10639"; a="362861715" X-IronPort-AV: E=Sophos;i="5.98,233,1673942400"; d="scan'208";a="362861715" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2023 06:02:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10639"; a="677983648" X-IronPort-AV: E=Sophos;i="5.98,233,1673942400"; d="scan'208";a="677983648" Received: from lkp-server01.sh.intel.com (HELO 776573491cc5) ([10.239.97.150]) by fmsmga007.fm.intel.com with ESMTP; 04 Mar 2023 06:02:54 -0800 Received: from kbuild by 776573491cc5 with local (Exim 4.96) (envelope-from ) id 1pYSTO-0002CK-14; Sat, 04 Mar 2023 14:02:54 +0000 Date: Sat, 4 Mar 2023 22:02:51 +0800 From: kernel test robot To: Suren Baghdasaryan Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev, Andrew Morton , Linux Memory Management List Subject: [akpm-mm:mm-unstable 83/143] mm/khugepaged.c:1704:9: error: implicit declaration of function 'vma_try_start_write' is invalid in C99 Message-ID: <202303042159.qPwZsZsh-lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 27ED3C001B X-Rspamd-Server: rspam01 X-Stat-Signature: eih5ims7pe7n84juugkmbbrapu56foh7 X-HE-Tag: 1677938577-127909 X-HE-Meta: U2FsdGVkX1/GLTLXIBQPwmZ6sxR/kGnDM7F0nYYEalq7g8szSAU0cnmhBB034GMvtOfTxDGG9PUzWofHjHaPTWIkaq0OXLTiISyQ25lR330UB7pLfjzHiVam2VCpEm3Ed264pe9QCYx3R2Aw/IiT7QEWeJ2rAIL+QKHsy+7DYbSwxdUJHJ+g5RzIMBNnBU2Ug3YuCBCgfMohKrxl4+JdCApzmHvZvty6ScTJTkY3sxxluvyvbDJW13f503byL0bmVNVhRlsHCw+CzU/FzHtwfL0zSi0vYXE/xe8jCPQLTC8GVRf2bRU+My9ZhmI5nQekXX7GKa5UhJNQjbw1VJjrpCtagPU3ngNyVh0cE0sVkMaAa4KhEW/Oa/CPhnMemYoxkAUrqKUoKo9zBaffvSL81oCWssc08syJlW3gsYMvUGwv00d2mDs/OcQrZ3Eprhpp1jG+hWEqnKz0JGNPQK84AoKTEySuL8yoqX8rqJ8MNbQSE0ZNDTXnnA1MvAdo/2VLy73fP7zouWMX4l+uPr0qpT1jnwMlIdyvN7YUi+wfCI1KeeUi6ztQZLCL2IYLOLPgGbiZgtgf6hkafaZVSpt6uA4WxRycfW59XQYzQw7d1qNkUS/OqSPOn3Ytl3fctjlScfA7YfCHCykcIMU0shEqooaoI7SM9g5+GkP/xuhFjih5ysUkqKl00zggNaIRudVVXL5qD7EKnztWV3k2YIRRtLk3r8E1aMGPhm0VzVKQ0phEwt6/EKptw7P+IC7NlqLP+y0sue5fcdBA63Ia2zUrfy6nLKfc3BTeqb2GEkbOMXB/cp4eLR7q5To7gDUEblfHdzFVUpyuceKNkcO+hD7RgHhlXLbkAnEFCmVysTcqmQrt5MTjojkLQtUuwncqjvJdvwNyVmpjcX3moGkH/djUnnTJhWGrOVlkd6X3iPfT2vksipva6Smj3Oqf80WQNGCYKNbiVNgLVddPdnHcj69 VC6hpFBi pA9J7ENP89LkvoKGR6Fot+a+FC25WcLHnZJfXe3KrOD88qxqIZ+B5sLbIPPZtlnTIiagKCmmnaI8BCetzfWP7FKNY7iGN3cw4JgqRK/xEdFFmR9aGeCzEQAjDY0YDUtcfK4jIjmZQsE9eUeV1xldbxfC5WxrbH5YKBLL6PczpOYzWFcPkkGSjcSiKzc9tEoQcFDXf2CX0v8Xdse6Bd7JiYCtscNePYaKghOpDy2mKEsyP6x50lNxu+tiHha5751IHKekFx8ozKZc3B0P02BGLAp6brOS7eGeER1IcOdKjO7umzJ8rzgoDsh3A4Vz2V/Lq5O+P5l5E9mhCW5krjSv7En/kjquw7PB55c9FNBTlLWwWWDl9R57KR6IQALsTL0PiZHkhnm+vwh/Y7Ni8Yn2u1WMwONlMCKbj7GTQmCCkPyKfjP4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable head: df3ae4347aff9be1e9763ffa3b1015fca348bfbd commit: 92e3612279f925881e96dcc89acfb6bf96a2bb2a [83/143] mm/khugepaged: fix vm_lock/i_mmap_rwsem inversion in retract_page_tables config: i386-randconfig-a002 (https://download.01.org/0day-ci/archive/20230304/202303042159.qPwZsZsh-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://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?id=92e3612279f925881e96dcc89acfb6bf96a2bb2a git remote add akpm-mm https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git git fetch --no-tags akpm-mm mm-unstable git checkout 92e3612279f925881e96dcc89acfb6bf96a2bb2a # 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=i386 olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303042159.qPwZsZsh-lkp@intel.com/ All errors (new ones prefixed by >>): >> mm/khugepaged.c:1704:9: error: implicit declaration of function 'vma_try_start_write' is invalid in C99 [-Werror,-Wimplicit-function-declaration] if (!vma_try_start_write(vma)) ^ mm/khugepaged.c:1704:9: note: did you mean 'vma_start_write'? include/linux/mm.h:719:20: note: 'vma_start_write' declared here static inline void vma_start_write(struct vm_area_struct *vma) {} ^ 1 error generated. vim +/vma_try_start_write +1704 mm/khugepaged.c 1641 1642 static int retract_page_tables(struct address_space *mapping, pgoff_t pgoff, 1643 struct mm_struct *target_mm, 1644 unsigned long target_addr, struct page *hpage, 1645 struct collapse_control *cc) 1646 { 1647 struct vm_area_struct *vma; 1648 int target_result = SCAN_FAIL; 1649 1650 i_mmap_lock_write(mapping); 1651 vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) { 1652 int result = SCAN_FAIL; 1653 struct mm_struct *mm = NULL; 1654 unsigned long addr = 0; 1655 pmd_t *pmd; 1656 bool is_target = false; 1657 1658 /* 1659 * Check vma->anon_vma to exclude MAP_PRIVATE mappings that 1660 * got written to. These VMAs are likely not worth investing 1661 * mmap_write_lock(mm) as PMD-mapping is likely to be split 1662 * later. 1663 * 1664 * Note that vma->anon_vma check is racy: it can be set up after 1665 * the check but before we took mmap_lock by the fault path. 1666 * But page lock would prevent establishing any new ptes of the 1667 * page, so we are safe. 1668 * 1669 * An alternative would be drop the check, but check that page 1670 * table is clear before calling pmdp_collapse_flush() under 1671 * ptl. It has higher chance to recover THP for the VMA, but 1672 * has higher cost too. It would also probably require locking 1673 * the anon_vma. 1674 */ 1675 if (READ_ONCE(vma->anon_vma)) { 1676 result = SCAN_PAGE_ANON; 1677 goto next; 1678 } 1679 addr = vma->vm_start + ((pgoff - vma->vm_pgoff) << PAGE_SHIFT); 1680 if (addr & ~HPAGE_PMD_MASK || 1681 vma->vm_end < addr + HPAGE_PMD_SIZE) { 1682 result = SCAN_VMA_CHECK; 1683 goto next; 1684 } 1685 mm = vma->vm_mm; 1686 is_target = mm == target_mm && addr == target_addr; 1687 result = find_pmd_or_thp_or_none(mm, addr, &pmd); 1688 if (result != SCAN_SUCCEED) 1689 goto next; 1690 /* 1691 * We need exclusive mmap_lock to retract page table. 1692 * 1693 * We use trylock due to lock inversion: we need to acquire 1694 * mmap_lock while holding page lock. Fault path does it in 1695 * reverse order. Trylock is a way to avoid deadlock. 1696 * 1697 * Also, it's not MADV_COLLAPSE's job to collapse other 1698 * mappings - let khugepaged take care of them later. 1699 */ 1700 result = SCAN_PTE_MAPPED_HUGEPAGE; 1701 if ((cc->is_khugepaged || is_target) && 1702 mmap_write_trylock(mm)) { 1703 /* trylock for the same lock inversion as above */ > 1704 if (!vma_try_start_write(vma)) 1705 goto unlock_next; 1706 1707 /* 1708 * Re-check whether we have an ->anon_vma, because 1709 * collapse_and_free_pmd() requires that either no 1710 * ->anon_vma exists or the anon_vma is locked. 1711 * We already checked ->anon_vma above, but that check 1712 * is racy because ->anon_vma can be populated under the 1713 * mmap lock in read mode. 1714 */ 1715 if (vma->anon_vma) { 1716 result = SCAN_PAGE_ANON; 1717 goto unlock_next; 1718 } 1719 /* 1720 * When a vma is registered with uffd-wp, we can't 1721 * recycle the pmd pgtable because there can be pte 1722 * markers installed. Skip it only, so the rest mm/vma 1723 * can still have the same file mapped hugely, however 1724 * it'll always mapped in small page size for uffd-wp 1725 * registered ranges. 1726 */ 1727 if (hpage_collapse_test_exit(mm)) { 1728 result = SCAN_ANY_PROCESS; 1729 goto unlock_next; 1730 } 1731 if (userfaultfd_wp(vma)) { 1732 result = SCAN_PTE_UFFD_WP; 1733 goto unlock_next; 1734 } 1735 collapse_and_free_pmd(mm, vma, addr, pmd); 1736 if (!cc->is_khugepaged && is_target) 1737 result = set_huge_pmd(vma, addr, pmd, hpage); 1738 else 1739 result = SCAN_SUCCEED; 1740 1741 unlock_next: 1742 mmap_write_unlock(mm); 1743 goto next; 1744 } 1745 /* 1746 * Calling context will handle target mm/addr. Otherwise, let 1747 * khugepaged try again later. 1748 */ 1749 if (!is_target) { 1750 khugepaged_add_pte_mapped_thp(mm, addr); 1751 continue; 1752 } 1753 next: 1754 if (is_target) 1755 target_result = result; 1756 } 1757 i_mmap_unlock_write(mapping); 1758 return target_result; 1759 } 1760 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests