From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC PATCH v2 23/27] mm/mmap: Add IBT bitmap size to address space limit check Date: Tue, 10 Jul 2018 16:57:39 -0700 Message-ID: <7cdadb28-a9aa-550b-9e31-30691b64b504@linux.intel.com> References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-24-yu-cheng.yu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20180710222639.8241-24-yu-cheng.yu@intel.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra List-Id: linux-api@vger.kernel.org On 07/10/2018 03:26 PM, Yu-cheng Yu wrote: > The indirect branch tracking legacy bitmap takes a large address > space. This causes may_expand_vm() failure on the address limit > check. For a IBT-enabled task, add the bitmap size to the > address limit. This appears to require that we set up current->thread.cet.ibt_bitmap_size _before_ calling may_expand_vm(). What keeps the ibt_mmap() itself from hitting the address limit?