From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by kanga.kvack.org (Postfix) with ESMTP id D5C206B0036 for ; Fri, 16 May 2014 18:56:20 -0400 (EDT) Received: by mail-ee0-f43.google.com with SMTP id d17so1895852eek.16 for ; Fri, 16 May 2014 15:56:20 -0700 (PDT) Received: from mail.zytor.com (terminus.zytor.com. [2001:1868:205::10]) by mx.google.com with ESMTPS id c6si8091669eem.120.2014.05.16.15.56.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 May 2014 15:56:19 -0700 (PDT) Message-ID: <53769785.6060809@zytor.com> Date: Fri, 16 May 2014 15:56:05 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: mm: NULL ptr deref handling mmaping of special mappings References: <20140514221140.GF28328@moon> <20140515084558.GI28328@moon> <20140515195320.GR28328@moon> <20140515201914.GS28328@moon> <20140515213124.GT28328@moon> <20140515215722.GU28328@moon> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski , Cyrill Gorcunov Cc: Andrew Morton , Sasha Levin , "linux-mm@kvack.org" , Dave Jones , LKML , Pavel Emelyanov On 05/16/2014 03:40 PM, Andy Lutomirski wrote: > > My current draft is here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups > > On 64-bit userspace, it results in: > > 7fffa1dfd000-7fffa1dfe000 r-xp 00000000 00:00 0 [vdso] > 7fffa1dfe000-7fffa1e00000 r--p 00000000 00:00 0 [vvar] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > > On 32-bit userspace, it results in: > > f7748000-f7749000 r-xp 00000000 00:00 0 [vdso] > f7749000-f774b000 r--p 00000000 00:00 0 [vvar] > ffd94000-ffdb5000 rw-p 00000000 00:00 0 [stack] > > Is this good for CRIU? Another approach would be to name both of > these things "vdso", since they are sort of both the vdso, but that > might be a bit confusing -- [vvar] is not static text the way that > [vdso] is. > > If I backport this for 3.15 (which might be nasty -- I would argue > that the code change is actually a cleanup, but it's fairly > intrusive), then [vvar] will be *before* [vdso], not after it. I'd be > very hesitant to name both of them "[vdso]" in that case, since there > is probably code that assumes that the beginning of "[vdso]" is a DSO. > > Note that it is *not* safe to blindly read from "[vvar]". On some > configurations you *will* get SIGBUS if you try to read from some of > the vvar pages. (That's what started this whole thread.) Some pages > in "[vvar]" may have strange caching modes, so SIGBUS might not be the > only surprising thing about poking at it. > mremap() should work on these pages, right? -hpa -- 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