linux-kernel - Re: [RFC PATCH v2 5/5] mm, shmem: Show location of non-resident shmem pages in smaps

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54171829.3090108@redhat.com>
Date:	Mon, 15 Sep 2014 18:47:37 +0200
From:	Jerome Marchand <jmarchan@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	linux-mm@...ck.org, Randy Dunlap <rdunlap@...radead.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux390@...ibm.com, Hugh Dickins <hughd@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-s390@...r.kernel.org
Subject: Re: [RFC PATCH v2 5/5] mm, shmem: Show location of non-resident shmem
 pages in smaps

On 09/15/2014 06:21 PM, Oleg Nesterov wrote:
> Hi Jerome,
> 
> Not sure I understand this patch correctly, will try to read it later.
> But a couple of nits/questions anyway,
> 
> On 09/15, Jerome Marchand wrote:
>>
>> +The ShmXXX lines only appears for shmem mapping. They show the amount of memory
>> +from the mapping that is currently:
>> + - resident in RAM but not mapped into any process (ShmNotMapped)
> 
> But how can we know that it is not mapped by another process?

Its mapcount is zero.

> 
> And in fact "not mapped" looks confusing (at least to me).

"Not mapped" as "not present in a page table". It does belong to a
userspace mapping though. I wonder if there is a less ambiguous terminology.

> IIUC it is actually
> mapped even by this process, just it never tried to fault these (resident or
> swapped) pages in. Right?

No these pages are in the page cache. This can happen when the only
process which have accessed these exits or munmap() the mapping.

> 
>> +void update_shmem_stats(struct mem_size_stats *mss, struct vm_area_struct *vma,
>> +			pgoff_t pgoff, unsigned long size)
> 
> static?
> 
>> +{
>> +	int count = 0;
>> +
>> +	switch (shmem_locate(vma, pgoff, &count)) {
>> +	case SHMEM_RESIDENT:
>> +		if (!count)
>> +			mss->shmem_notmapped += size;
>> +		break;
>> +	case SHMEM_SWAP:
>> +		mss->shmem_swap += size;
>> +		break;
>> +	}
>> +}
> 
> It seems that shmem_locate() and shmem_vma() are only defined if CONFIG_SHMEM,
> probably this series needs more ifdef's.

Now I wonder. Did I try to compile this with CONFIG_SHMEM unset?

> 
> And I am not sure why we ignore SHMEM_SWAPCACHE...

Hugh didn't like it as it is a small and transient value.

Thanks,
Jerome

> 
> Oleg.
> 



Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)