Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751261AbbD2Ud5 (ORCPT ); Wed, 29 Apr 2015 16:33:57 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:32893 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750758AbbD2Udz (ORCPT ); Wed, 29 Apr 2015 16:33:55 -0400 MIME-Version: 1.0 In-Reply-To: <20150429193622.GA11892@node.dhcp.inet.fi> References: <20150429193622.GA11892@node.dhcp.inet.fi> Date: Wed, 29 Apr 2015 13:33:54 -0700 X-Google-Sender-Auth: IQ73ueF6TLfvDu0JL-5EeDWvwQ4 Message-ID: Subject: Re: Regression: Requiring CAP_SYS_ADMIN for /proc//pagemap causes application-level breakage From: Linus Torvalds To: "Kirill A. Shutemov" Cc: Mark Williamson , Mark Seaborn , kernel list , "Kirill A. Shutemov" , Pavel Emelyanov , Konstantin Khlebnikov , Andrew Morton , Andy Lutomirski , Linux API , Finn Grimwood , Daniel James Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 35 On Wed, Apr 29, 2015 at 12:36 PM, Kirill A. Shutemov wrote: > > Emm.. I have hard time to understand how writable bit is enough to get > soft-dirty-alike functionality. I don't think it is. For anonymous pages, maybe you can play tricks with comparing the page 'anon_vma' with the vma->anon_vma. I haven't really thought that through, but does something like static inline bool page_is_dirty_in_vma(struct page *page, struct vm_area_struct *vma) { struct anon_vma *anon_vma = vma->anon_vma; return page->mapping == (void *)anon_vma + PAGE_MAPPING_ANON; } end up working as a "page has been dirtied in this mapping"? If the page came from another process and hasn't been written to, it will have the anon_vma pointing to the originalting vma. I may be high on some bad drugs, though. As mentioned, I didn't really think this through. Linus -- 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/