Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754185AbbFKSty (ORCPT ); Thu, 11 Jun 2015 14:49:54 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:52448 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbbFKStw (ORCPT ); Thu, 11 Jun 2015 14:49:52 -0400 Date: Thu, 11 Jun 2015 11:49:46 -0700 From: Andrew Morton To: Alexey Dobriyan Cc: Calvin Owens , "Eric W. Biederman" , Al Viro , Miklos Szeredi , Zefan Li , Oleg Nesterov , Joe Perches , David Howells , Linux Kernel , kernel-team@fb.com, Andy Lutomirski , Cyrill Gorcunov , Kees Cook , "Kirill A. Shutemov" Subject: Re: [PATCH v6] procfs: Always expose /proc//map_files/ and make it readable Message-Id: <20150611114946.d9d259a363a86adba756bdfd@linux-foundation.org> In-Reply-To: References: <1432005006-3428-1-git-send-email-calvinowens@fb.com> <1433821173-2804704-1-git-send-email-calvinowens@fb.com> <20150609141300.b80eeec15b2c379146816c06@linux-foundation.org> <20150610013902.GA176908@mail.thefacebook.com> <20150610135832.af4e8970c45f3a40b64274e0@linux-foundation.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2460 Lines: 53 On Thu, 11 Jun 2015 14:10:45 +0300 Alexey Dobriyan wrote: > On Wed, Jun 10, 2015 at 11:58 PM, Andrew Morton > wrote: > > On Tue, 9 Jun 2015 18:39:02 -0700 Calvin Owens wrote: > > > >> On Tuesday 06/09 at 14:13 -0700, Andrew Morton wrote: > >> > On Mon, 8 Jun 2015 20:39:33 -0700 Calvin Owens wrote: > >> > > >> > > Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and > >> > > is only exposed if CONFIG_CHECKPOINT_RESTORE is set. > >> > > > >> > > This interface very useful because it allows userspace to stat() > >> > > deleted files that are still mapped by some process, which enables a > >> > > much quicker and more accurate answer to the question "How much disk > >> > > space is being consumed by files that are deleted but still mapped?" > >> > > than is currently possible. > >> > > >> > Why is that information useful? > >> > > >> > I could perhaps think of some use for "How much disk space is being > >> > consumed by files that are deleted but still open", but to count the > >> > mmapped-then-unlinked files while excluding the opened-then-unlinked > >> > files seems damned peculiar. > >> > >> Let's phrase the question a bit more generically: > >> > >> "How much disk space is being consumed by files that have been > >> unlinked, but are still referenced by some process?" > >> > >> There are two pieces to this problem: > >> 1) Unlinked files that are still open (whether mapped or not) > >> 2) Unlinked files that are not open, but are still mapped > >> > >> You can track down everything in (1) using /proc//fd/*, and you > >> can use stat() to figure out how much space they're using. > > > > This doesn't work if the mapped file has been unlinked? What does the > > /proc/pid/map_files listing look like for these? > > It says "(deleted)" like /proc/*/exe or any other symlink. Actually the symlink directs at "/home/akpm/foo (deleted)". And lo, if you do `stat -L' on the symlink, you get the info for the unlinked-but-still-mmapped inode. I never knew that. And I wouldn't have learned it from the documentation, which is careful to keep all this a secret. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/