Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751457AbeABQoq (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Tue, 2 Jan 2018 11:44:46 -0500
Received: from mail-wm0-f66.google.com ([74.125.82.66]:34839 "EHLO
        mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751128AbeABQoo (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 2 Jan 2018 11:44:44 -0500
X-Google-Smtp-Source: ACJfBosVkR6qrKVnUxqVzTuj4qxLK3f6uiwnQACI+UOwpypotpzozro2Xb81RWPBPObgnQzZBJvli/AnorrdWiEdejA=
MIME-Version: 1.0
In-Reply-To: <20171214173653.s6vsgiwfty3tzyzs@hirez.programming.kicks-ass.net>
References: <20171214112726.742649793@infradead.org> <20171214113851.197682513@infradead.org>
 <CALCETrXzaa8svjHdm3G3=FKvAZoQx-CboE6YecdPsva+Lf_bJg@mail.gmail.com> <20171214173653.s6vsgiwfty3tzyzs@hirez.programming.kicks-ass.net>
From: Dmitry Safonov <0x7f454c46@gmail.com>
Date: Tue, 2 Jan 2018 16:44:22 +0000
Message-ID: <CAJwJo6ZujJah9rTnhogGBR-7B9t7vuXi7vBTn2N=N4bc-FL3hw@mail.gmail.com>
Subject: Re: [PATCH v2 02/17] mm: Exempt special mappings from mlock(),
 mprotect() and madvise()
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Borislav Petkov <bpetkov@suse.de>,
        Greg KH <gregkh@linuxfoundation.org>,
        Kees Cook <keescook@google.com>,
        Hugh Dickins <hughd@google.com>,
        Brian Gerst <brgerst@gmail.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <jgross@suse.com>,
        David Laight <David.Laight@aculab.com>,
        Eduardo Valentin <eduval@amazon.com>,
        "Liguori, Anthony" <aliguori@amazon.com>,
        Will Deacon <will.deacon@arm.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Dan Williams <dan.j.williams@intel.com>, crml <criu@openvz.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

Hi, sorry for the late reply,

2017-12-14 17:36 GMT+00:00 Peter Zijlstra <peterz@infradead.org>:
> On Thu, Dec 14, 2017 at 08:19:36AM -0800, Andy Lutomirski wrote:
>> On Thu, Dec 14, 2017 at 3:27 AM, Peter Zijlstra <peterz@infradead.org> 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