From patchwork Fri Apr 27 18:43:15 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Baron X-Patchwork-Id: 155572 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id BB67EB6FE8 for ; Sat, 28 Apr 2012 04:43:33 +1000 (EST) Received: from localhost ([::1]:49212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNq8f-0000uV-As for incoming@patchwork.ozlabs.org; Fri, 27 Apr 2012 14:43:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNq8Y-0000uM-3n for qemu-devel@nongnu.org; Fri, 27 Apr 2012 14:43:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNq8W-0001gQ-0o for qemu-devel@nongnu.org; Fri, 27 Apr 2012 14:43:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNq8V-0001fq-PB for qemu-devel@nongnu.org; Fri, 27 Apr 2012 14:43:19 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3RIhGYZ006886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Apr 2012 14:43:16 -0400 Received: from redhat.com (dhcp-185-114.bos.redhat.com [10.16.185.114]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3RIhFpo008510; Fri, 27 Apr 2012 14:43:15 -0400 Date: Fri, 27 Apr 2012 14:43:15 -0400 From: Jason Baron To: Michael Kerrisk Message-ID: <20120427184311.GB13762@redhat.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Cc: mcgrathr@google.com, Linux API , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, avi@redhat.com, akpm@linux-foundation.org Subject: Re: [Qemu-devel] [PATCH 0/2] core dump: re-purpose VM_ALWAYSDUMP to user controlled VM_DONTDUMP X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Tue, Apr 24, 2012 at 10:42:16AM +1200, Michael Kerrisk wrote: > Jason, > > On Thu, Mar 8, 2012 at 6:00 AM, Jason Baron wrote: > > Hi, > > > > The motivation for this change was that I was looking at a way for a qemu-kvm > > process, to exclude the guest memory from its core dump, which can be quite > > large. There are already a number of filter flags in > > /proc//coredump_filter, however, these allow one to specify 'types' of > > kernel memory, not specific address ranges (which is needed in this case). > > > > Since there are no more vma flags available, the first patch eliminates the > > need for the 'VM_ALWAYSDUMP' flag. The flag is used internally by the kernel to > > mark vdso and vsyscall pages. However, it is simple enough to check if a vma > > covers a vdso or vsyscall page without the need for this flag. > > > > The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new > > 'VM_DONTDUMP' flag, which can be set by userspace using new madvise flags: > > 'MADV_DONTDUMP', and unset via 'MADV_DUMP'. The core dump filters continue to > > work the same as before unless 'MADV_DONTDUMP' is set on the region. > > > > The qemu code which implements this features is at: > > http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch > > > > In my testing the qemu core dump shrunk from 383MB -> 13MB with this patch. > > > > I also believe that the 'MADV_DONTDUMP' flag might be useful for security > > sensitive apps, which might want to select which areas are dumped. > > Since we have > MADV_DODUMP > MADV_DONTDUMP > MADV_NODUMP > heading for userspace in 3.4, would you be willing to write patches > for the madvise(2) man page to describe these flags? > > See http://www.kernel.org/doc/man-pages/download.html for details on > accessing man-pages Git. > > Cheers, > > Michael > > PS Please also CC linux-api@ when making API/ABI changes. > Ok, here's a stab at manpage patch, let me know if I should send it as a separate patch. Thanks. -Jason diff --git a/man2/madvise.2 b/man2/madvise.2 index 36f988a..472c23a 100644 --- a/man2/madvise.2 +++ b/man2/madvise.2 @@ -247,6 +247,22 @@ Ensures that memory in the address range specified by and .IR length will not be collapsed into huge pages. +.TP +.BR MADV_DONTDUMP " (since Linux 3.4)" +Explicitly exclude from a core dump those pages in the range specified by +.I addr +and +.IR length . +Applications may have large areas of memory which are known not to be useful in +diagnosing a core dump. This specification takes precedence over the bit mask that +is set via the +.I /proc/PID/coredump_filter +file (see +.BR core (5)). +.TP +.BR MADV_DODUMP " (since Linux 3.4)" +Undo the effect of an earlier +.BR MADV_DONTDUMP. .SH "RETURN VALUE" On success .BR madvise () @@ -356,4 +372,5 @@ from the system call, as it should). .BR mmap (2), .BR mprotect (2), .BR msync (2), -.BR munmap (2) +.BR munmap (2), +.BR core (5)