linux-kernel - Re: [PATCH 3/5] perf_counter: rework ioctl()s

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]

Date:	Wed, 13 May 2009 08:18:22 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/5] perf_counter: rework ioctl()s

Corey Ashford writes:

> Another hypothesis is that the old PAPI code would open, mmap, close, 
> then reopen, and mmap again.  I wonder if because I wasn't munmap'ing 
> before the close, that I got some strange behavior from the kernel. 

In general an mmap will keep a reference to the file it is mapping,
which means that if you do an mmap on a fd and then close the fd, the
file stays open until the region is munmapped.  So your old PAPI code
would have ended up with more counters active than you expected, if
you thought closing the fd would have destroyed the counter.

That is, you don't have to munmap before close, but you do have to do
both close and munmap to destroy the counter.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/