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 777F4CF0429 for ; Tue, 8 Oct 2024 22:45:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B7466B009D; Tue, 8 Oct 2024 18:45:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0415E6B009F; Tue, 8 Oct 2024 18:45:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFC9F6B00A2; Tue, 8 Oct 2024 18:45:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BCE506B009D for ; Tue, 8 Oct 2024 18:45:20 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0A142160C0E for ; Tue, 8 Oct 2024 22:45:19 +0000 (UTC) X-FDA: 82651917600.19.69A1FA0 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by imf26.hostedemail.com (Postfix) with ESMTP id 8877714001A for ; Tue, 8 Oct 2024 22:45:17 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dgsU16Om; spf=pass (imf26.hostedemail.com: domain of lkp@intel.com designates 198.175.65.18 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=1728427338; 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:in-reply-to:references:references:dkim-signature; bh=JwYNvXx60NruI8DRN7fBAKAv0tmSvOH2sv3YnOfqUto=; b=L0P9iP8ALlfnaBM4E2Esb1Dn9YKWU5eTJzKqpC3jmdH3LueBsAZ0j7qmZ2QRoRXo3IlYOr WgCbr7aZwB8FPWyjvOKW0bNK2ii1ShbWGLP9RZq2VwB8C5VNGsag/u5CoIRQu4SuF6c5/i 7/2QwsxeTSu9NERkr9eS7XDc46+HXxU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dgsU16Om; spf=pass (imf26.hostedemail.com: domain of lkp@intel.com designates 198.175.65.18 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=1728427338; a=rsa-sha256; cv=none; b=kU9ovHT6LlcODk8f5mLRcckeixWCqEIKTtlDaVlgKYGcWR+yysCgwskcZabBW0uZAnJORK Co0S/bTt+UR/t8NTzh2G0hmKWdAIo4xbJtvpitmNuWaZP/COHmg5AiBfbvvzSV1WKamEbu I8t+k09tKNWnmmfgEX7ActoSUrRi+ew= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728427518; x=1759963518; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Gk580rjiDxgF7YwO5s3wxuTmM7IrxPdN+2ai82g118U=; b=dgsU16Om9tPoVlGSRKLIlY7QabNOXfZWP0MQIXAizJ9JVTAmxKofUCb5 5U7YuJOb5A6HMglD5MPa9pYryqz2owGmJWzl39t3UOh8wPZwzu0XdMUSp x7qvFcf18EWRQdR0KiZ409DVOq7UdjBHdYCxoOm5T/FIhJrfbarfNShMN g9lzvmhm9d7iGlMp3P++IhPEJjYkDfraNRHnRCuPE2BIVJ1J2ZCiY1/2M zA564vBGqKqO5UbItkA2NsemH+DfNM8VAhR2Rfgm/PwgOmV5UR4vWiPqU 083zkALo07B83SF7AEDv7IA3ETU2jWvtWlYO+3ZEhFEkhVgyc0vwS9xf0 g==; X-CSE-ConnectionGUID: c0kmwqCQQoWZdgvj/2WwMg== X-CSE-MsgGUID: dk0PMls1QEG2838sQJBDdA== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="27810510" X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="27810510" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 15:45:16 -0700 X-CSE-ConnectionGUID: xhvqv0qXQxOYbkci+1Si9w== X-CSE-MsgGUID: taWMAtFRRgiW0/f99iXx3Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,188,1725346800"; d="scan'208";a="99368575" Received: from lkp-server01.sh.intel.com (HELO a48cf1aa22e8) ([10.239.97.150]) by fmviesa002.fm.intel.com with ESMTP; 08 Oct 2024 15:45:12 -0700 Received: from kbuild by a48cf1aa22e8 with local (Exim 4.96) (envelope-from ) id 1syIx4-0008Rq-19; Tue, 08 Oct 2024 22:45:10 +0000 Date: Wed, 9 Oct 2024 06:45:08 +0800 From: kernel test robot To: Jann Horn , Andrew Morton Cc: oe-kbuild-all@lists.linux.dev, Linux Memory Management List , Hugh Dickins , Oleg Nesterov , Michal Hocko , Helge Deller , Vlastimil Babka , Ben Hutchings , Willy Tarreau , Rik van Riel , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jann Horn Subject: Re: [PATCH] mm: Enforce a minimal stack gap even against inaccessible VMAs Message-ID: <202410090632.brLG8w0b-lkp@intel.com> References: <20241008-stack-gap-inaccessible-v1-1-848d4d891f21@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241008-stack-gap-inaccessible-v1-1-848d4d891f21@google.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8877714001A X-Stat-Signature: brzx3aurkfeqcgz8hu43jr6absfugag3 X-Rspam-User: X-HE-Tag: 1728427517-407402 X-HE-Meta: U2FsdGVkX1/aSbbHCy6Np/8/wueR6CRLiqoxKhtGCKSHePC7DTROxubSi/biqzvxc1QbmGzW2U4XSguR+lvFr/1mnjyYc9loHM0E5vFVSJSO4BALhek3GuqaM1Jy5JmzE664/0p4wXkIADH2HEDpfUZTXCd5t/Ng/967UlhEVDog4IKgH4AyDioxtiSBnb1gWj+9qmRy31JUKLkQ3q3l3Kst5+iJwrF3OciVMbqmzwSDhw450Ar/KY1zxh52WY7wR7RhVUlzgxW8PXBomigonROEMC1E+gkDJBLFtX7SNwRouGlPWv9PBb2LOFN5MBStszJiLJw04vN1upaBWfvlYXCvEXySmVKoWakn3KjWjOC4XSBZTMN9tK7wrQvfOvYYHyxEq737NyppQ1QWQnX8FhSNCEmBJlaekOPagvjC65WeVuxJ6GgixlxTWNJwfg96ZetrZCkb/WmaWuMVdIlZxhGNvoK01DtqmrSRmHEn8kHGVKNsQ/2ED93vK/v89UaSCQdyiPJernSn8soVf52MynBOpGxG7+LlUNz++yD5/j5Uw3i9nKOTqr+Nf6qfeeDJRA6U8c1HxzfC0xLFHAPbWui+AB4FinyUHYBXgnUBTaPCjVTNqPbcAbvRcwK3jf3amrcO3AICK/su4BzUPzbjs8/+AW22F+7dECqenCpfcPSewygtW932K08bKpp27vF9BcT52CcX/KNgehm4Q6XRsOaX8K1yrV4xUl/0Lf/zKuIpzq+tbVjIMHsKix5CWZXH+UYXK9+zyuzs/qcGj8iIOJwsWjJTD9ndVj1QzFWET7I61+PMmfoVMvnKCg2sjyucDNzVJVqIfdUKZ/fO459QgwFHgum7IbNIPh8+leCKpHT54zK5MX6ienMHNoBUXWMG8QCs6Muam0r++XDWLw0aA/7JE6yDPlNUelL0s83bXwXXUYFFWOHWpEirxinzgmtod48vr7dO7rw3RC44cmZ wqo7GGpc Sox4ikhh56eOjX6mN2Pye6iMZJWhVlrkFzOj4S+esQSqh62saMwyu4TOdPXymQYO9vqH/zuOgMfgG7B8WsU8xU4zxc6dUIW+PwUrl+PE/12jfAblvFHfbQJdvuzKRQpaSmD1Zc/rqm+ijZ9ye/FNHzgY4PplWsuZg51h8pAo08iNj6g/98KPCcm3hsYJ+TnbRjuRZaWMzt9/wN1DnJyqHrAoJ9oGiHmhQXlRT+MKUeJPWD0atcraBZGurx5+kmtwmN2H3Wg1ZIohH2Ug7HlSSVQ5Hr1zMYbxLvtY4ATeEPxqmMu3T8OXBJvo0DKT3L1cuUaXViK3tOHYqDqHrjWgKT29wkW2OIW13QusZ 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: List-Subscribe: List-Unsubscribe: Hi Jann, kernel test robot noticed the following build errors: [auto build test ERROR on 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b] url: https://github.com/intel-lab-lkp/linux/commits/Jann-Horn/mm-Enforce-a-minimal-stack-gap-even-against-inaccessible-VMAs/20241008-065733 base: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b patch link: https://lore.kernel.org/r/20241008-stack-gap-inaccessible-v1-1-848d4d891f21%40google.com patch subject: [PATCH] mm: Enforce a minimal stack gap even against inaccessible VMAs config: parisc-randconfig-r072-20241009 (https://download.01.org/0day-ci/archive/20241009/202410090632.brLG8w0b-lkp@intel.com/config) compiler: hppa-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241009/202410090632.brLG8w0b-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 | Closes: https://lore.kernel.org/oe-kbuild-all/202410090632.brLG8w0b-lkp@intel.com/ All errors (new ones prefixed by >>): mm/mmap.c: In function 'expand_upwards': >> mm/mmap.c:1069:39: error: 'prev' undeclared (first use in this function) 1069 | if (vma_is_accessible(prev)) | ^~~~ mm/mmap.c:1069:39: note: each undeclared identifier is reported only once for each function it appears in vim +/prev +1069 mm/mmap.c 1036 1037 #if defined(CONFIG_STACK_GROWSUP) 1038 /* 1039 * PA-RISC uses this for its stack. 1040 * vma is the last one with address > vma->vm_end. Have to extend vma. 1041 */ 1042 static int expand_upwards(struct vm_area_struct *vma, unsigned long address) 1043 { 1044 struct mm_struct *mm = vma->vm_mm; 1045 struct vm_area_struct *next; 1046 unsigned long gap_addr; 1047 int error = 0; 1048 VMA_ITERATOR(vmi, mm, vma->vm_start); 1049 1050 if (!(vma->vm_flags & VM_GROWSUP)) 1051 return -EFAULT; 1052 1053 /* Guard against exceeding limits of the address space. */ 1054 address &= PAGE_MASK; 1055 if (address >= (TASK_SIZE & PAGE_MASK)) 1056 return -ENOMEM; 1057 address += PAGE_SIZE; 1058 1059 /* Enforce stack_guard_gap */ 1060 gap_addr = address + stack_guard_gap; 1061 1062 /* Guard against overflow */ 1063 if (gap_addr < address || gap_addr > TASK_SIZE) 1064 gap_addr = TASK_SIZE; 1065 1066 next = find_vma_intersection(mm, vma->vm_end, gap_addr); 1067 if (next && !(next->vm_flags & VM_GROWSUP)) { 1068 /* see comments in expand_downwards() */ > 1069 if (vma_is_accessible(prev)) 1070 return -ENOMEM; 1071 if (address == next->vm_start) 1072 return -ENOMEM; 1073 } 1074 1075 if (next) 1076 vma_iter_prev_range_limit(&vmi, address); 1077 1078 vma_iter_config(&vmi, vma->vm_start, address); 1079 if (vma_iter_prealloc(&vmi, vma)) 1080 return -ENOMEM; 1081 1082 /* We must make sure the anon_vma is allocated. */ 1083 if (unlikely(anon_vma_prepare(vma))) { 1084 vma_iter_free(&vmi); 1085 return -ENOMEM; 1086 } 1087 1088 /* Lock the VMA before expanding to prevent concurrent page faults */ 1089 vma_start_write(vma); 1090 /* 1091 * vma->vm_start/vm_end cannot change under us because the caller 1092 * is required to hold the mmap_lock in read mode. We need the 1093 * anon_vma lock to serialize against concurrent expand_stacks. 1094 */ 1095 anon_vma_lock_write(vma->anon_vma); 1096 1097 /* Somebody else might have raced and expanded it already */ 1098 if (address > vma->vm_end) { 1099 unsigned long size, grow; 1100 1101 size = address - vma->vm_start; 1102 grow = (address - vma->vm_end) >> PAGE_SHIFT; 1103 1104 error = -ENOMEM; 1105 if (vma->vm_pgoff + (size >> PAGE_SHIFT) >= vma->vm_pgoff) { 1106 error = acct_stack_growth(vma, size, grow); 1107 if (!error) { 1108 /* 1109 * We only hold a shared mmap_lock lock here, so 1110 * we need to protect against concurrent vma 1111 * expansions. anon_vma_lock_write() doesn't 1112 * help here, as we don't guarantee that all 1113 * growable vmas in a mm share the same root 1114 * anon vma. So, we reuse mm->page_table_lock 1115 * to guard against concurrent vma expansions. 1116 */ 1117 spin_lock(&mm->page_table_lock); 1118 if (vma->vm_flags & VM_LOCKED) 1119 mm->locked_vm += grow; 1120 vm_stat_account(mm, vma->vm_flags, grow); 1121 anon_vma_interval_tree_pre_update_vma(vma); 1122 vma->vm_end = address; 1123 /* Overwrite old entry in mtree. */ 1124 vma_iter_store(&vmi, vma); 1125 anon_vma_interval_tree_post_update_vma(vma); 1126 spin_unlock(&mm->page_table_lock); 1127 1128 perf_event_mmap(vma); 1129 } 1130 } 1131 } 1132 anon_vma_unlock_write(vma->anon_vma); 1133 vma_iter_free(&vmi); 1134 validate_mm(mm); 1135 return error; 1136 } 1137 #endif /* CONFIG_STACK_GROWSUP */ 1138 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki