From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f197.google.com (mail-wr0-f197.google.com [209.85.128.197]) by kanga.kvack.org (Postfix) with ESMTP id 19E586B02BA for ; Tue, 2 Jan 2018 11:44:45 -0500 (EST) Received: by mail-wr0-f197.google.com with SMTP id o32so23323131wrf.20 for ; Tue, 02 Jan 2018 08:44:45 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id x10sor23604091edb.55.2018.01.02.08.44.43 for (Google Transport Security); Tue, 02 Jan 2018 08:44:43 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20171214173653.s6vsgiwfty3tzyzs@hirez.programming.kicks-ass.net> References: <20171214112726.742649793@infradead.org> <20171214113851.197682513@infradead.org> <20171214173653.s6vsgiwfty3tzyzs@hirez.programming.kicks-ass.net> From: Dmitry Safonov <0x7f454c46@gmail.com> Date: Tue, 2 Jan 2018 16:44:22 +0000 Message-ID: Subject: Re: [PATCH v2 02/17] mm: Exempt special mappings from mlock(), mprotect() and madvise() Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , Thomas Gleixner , X86 ML , Linus Torvalds , Dave Hansen , Borislav Petkov , Greg KH , Kees Cook , Hugh Dickins , Brian Gerst , Josh Poimboeuf , Denys Vlasenko , Boris Ostrovsky , Juergen Gross , David Laight , Eduardo Valentin , "Liguori, Anthony" , Will Deacon , "linux-mm@kvack.org" , "Kirill A. Shutemov" , Dan Williams , crml Hi, sorry for the late reply, 2017-12-14 17:36 GMT+00:00 Peter Zijlstra : > On Thu, Dec 14, 2017 at 08:19:36AM -0800, Andy Lutomirski wrote: >> On Thu, Dec 14, 2017 at 3:27 AM, Peter Zijlstra wrote: >> > It makes no sense to ever prod at special mappings with any of these >> > syscalls. >> > >> > XXX should we include munmap() ? >> >> This is an ABI break for the vdso. Maybe that's okay, but mremap() on >> the vdso is certainly used, and I can imagine debuggers using >> mprotect(). > > *groan*, ok so mremap() will actually still work after this, but yes, > mprotect() will not. I hadn't figured people would muck with the VDSO > like that. mremap() is needed for CRIU, at least. Please, don't restrict munmap(), as ARCH_MAP_VDSO_* allows to map vdso iff it's not already mapped. We don't need +w vdso mapping, but I guess that may break gdb breakpoints on vdso. Also, AFAICS, vma_is_special_mapping() has two parameters in linux-next, and your patches set doesn't change that. Thanks, Dmitry -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org