| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <5A90DA2E42F8AE43BC4A093BF06788481AA513F8@SHSMSX104.ccr.corp.intel.com>
Date: Fri, 27 Oct 2017 02:49:45 +0000
From: "Du, Fan" <fan.du@...el.com>
To: "Williams, Dan J" <dan.j.williams@...el.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@....de>,
"Hansen, Dave" <dave.hansen@...el.com>,
Michal Hocko <mhocko@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Du, Fan" <fan.du@...el.com>
Subject: RE: [PATCH v4] Add /proc/PID/smaps support for DAX
>-----Original Message-----
>From: linux-kernel-owner@...r.kernel.org
>[mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Dan Williams
>Sent: Thursday, October 26, 2017 5:17 PM
>To: Du, Fan <fan.du@...el.com>
>Cc: Andrew Morton <akpm@...ux-foundation.org>; Christoph Hellwig
><hch@....de>; Hansen, Dave <dave.hansen@...el.com>; Michal Hocko
><mhocko@...nel.org>; linux-kernel@...r.kernel.org
>Subject: Re: [PATCH v4] Add /proc/PID/smaps support for DAX
>
>On Wed, Oct 25, 2017 at 10:13 PM, Fan Du <fan.du@...el.com> wrote:
>>
>> Memory behind device DAX is not attached into normal memory
>> management system, when user mmap /dev/dax, smaps part is
>> currently missing, so no idea for user to check how much
>> device DAX memory are actually used in practice.
>>
>> Whether vma is backed up by normal page,huge page, or both
>> at the same time, this makes no difference for device DAX
>> user so far.
>>
>> Using existing smaps structure is enough to do the job, so
>> this patch tries to use existing RSS/PSS stuff for statistics.
>> An example reading is like this:
>> ----------------------------------------------------
>> 7f30fe200000-7f3102200000 rw-s 00000000 00:06 19567
>/dev/dax12.0
>> Size: 65536 kB
>> KernelPageSize: 4 kB
>> MMUPageSize: 4 kB
>> Rss: 65536 kB
>> Pss: 65536 kB
>> Shared_Clean: 0 kB
>> Shared_Dirty: 0 kB
>> Private_Clean: 0 kB
>> Private_Dirty: 65536 kB
>> Referenced: 65536 kB
>> Anonymous: 0 kB
>> LazyFree: 0 kB
>> AnonHugePages: 0 kB
>> ShmemPmdMapped: 0 kB
>> Shared_Hugetlb: 0 kB
>> Private_Hugetlb: 0 kB
>> Swap: 0 kB
>> SwapPss: 0 kB
>> Locked: 65536 kB
>> ProtectionKey: 0
>> VmFlags: rd wr sh mr mw me ms mm hg
>>
>> Signed-off-by: Fan Du <fan.du@...el.com>
>> ---
>> v4:
>> * Merge device DAX readings into existing smap counters
>> for simplicity.
>>
>> v3:
>> * Elaborate more about the usage suggested by Michal Hocko
>>
>> v2:
>> * Using pte_devmap to check valid pfn page structure,
>> Pointed out by Dan. thx!
>> fs/proc/task_mmu.c | 74
>++++++++++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 72 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> index 5589b4b..9b2d3e6 100644
>> --- a/fs/proc/task_mmu.c
>> +++ b/fs/proc/task_mmu.c
>> @@ -507,6 +507,55 @@ static void smaps_account(struct mem_size_stats
>*mss, struct page *page,
>> }
>> }
>>
>> +/* page structure behind DAX mappings is NOT compound page
>> + * when it's a huge page mappings, so introduce new API to
>> + * account for both PMD and PUD mapping.
>> + */
>> +static void smaps_account_dax_huge(struct mem_size_stats *mss,
>> + struct page *page, unsigned long size, bool
>young, bool dirty)
>> +{
>> + int mapcount = page_mapcount(page);
>> +
>> + if (PageAnon(page)) {
>> + mss->anonymous += size;
>> + if (!PageSwapBacked(page) && !dirty
>&& !PageDirty(page))
>> + mss->lazyfree += size;
>> + }
>> +
>> + mss->resident += size;
>> + /* Accumulate the size in pages that have been accessed. */
>> + if (young || page_is_young(page) || PageReferenced(page))
>> + mss->referenced += size;
>> +
>> + /*
>> + * page_count(page) == 1 guarantees the page is mapped exactly
>once.
>> + * If any subpage of the compound page mapped with PTE it
>would elevate
>> + * page_count().
>> + */
>> + if (page_count(page) == 1) {
>> + if (dirty || PageDirty(page))
>> + mss->private_dirty += size;
>> + else
>> + mss->private_clean += size;
>> + mss->pss += (u64)size << PSS_SHIFT;
>> + return;
>> + }
>> +
>> + if (mapcount >= 2) {
>> + if (dirty || PageDirty(page))
>> + mss->shared_dirty += size;
>> + else
>> + mss->shared_clean += size;
>> + mss->pss += (size << PSS_SHIFT) / mapcount;
>> + } else {
>> + if (dirty || PageDirty(page))
>> + mss->private_dirty += size;
>> + else
>> + mss->private_clean += size;
>> + mss->pss += size << PSS_SHIFT;
>> + }
>> +}
>> +
>> #ifdef CONFIG_SHMEM
>> static int smaps_pte_hole(unsigned long addr, unsigned long end,
>> struct mm_walk *walk)
>> @@ -528,7 +577,16 @@ static void smaps_pte_entry(pte_t *pte, unsigned
>long addr,
>> struct page *page = NULL;
>>
>> if (pte_present(*pte)) {
>> - page = vm_normal_page(vma, addr, *pte);
>> + if (!vma_is_dax(vma))
>> + page = vm_normal_page(vma, addr, *pte);
>> + else if (pte_devmap(*pte)) {
>> + struct dev_pagemap *pgmap;
>> +
>> + pgmap = get_dev_pagemap(pte_pfn(*pte),
>NULL);
>
>Where do you do the put_dev_pagemap?
Oops, my bad :(
will fix this in next version.
Powered by blists - more mailing lists