linux-kernel - Re: [PATCH 12/13] maps: Add /proc/pid/pagemap interface

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, 4 Apr 2007 11:32:32 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Nikita Danilov <nikita@...sterfs.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 12/13] maps: Add /proc/pid/pagemap interface

On Wed, Apr 04, 2007 at 03:18:41PM +0400, Nikita Danilov wrote:
> This pushes binary data to the user space. Wasn't /proc supposed to be
> ascii-based to avoid compatibility problems (e.g., size of unsigned long
> changing, endianness, etc.)?

Most of what's in /proc is ASCII, true. But there are notable
exceptions - kcore, auxv, mem. This is just another window into memory
like kcore and mem. It's also a fairly big window. To examine a 1G
mapping, you need to read 1M of data.

ASCII would be rather ugly here. It's important that the interface be
seekable so that you can skip over wide ranges of data with no maps.
So all the elements would have to be nice fixed sizes. That'd mean 16
hex digits plus a space/newline. So to figure out what's at b7f81000,
I'd have to divide by 4096 (I already have to know the page size),
then multiply by 17, getting c37791. And then I'd have to copy more
than 2x the data in byte-wide chunks due to alignment concerns.

With the extra translation on both ends, the expanded data size, and
the alignment issues, this probably just got 10x-20x slower. Which
means taking a snapshot of a typical system and doing any sort of live
display just got a hell of a lot more impractical.

Now I could adjust these to only export u64s in some preferred
endianness. But given I already need details like the page size to
make any sense of it, it seems unnecessary. Also, the PFNs are fairly
opaque unless you're attempting to correlate them with /proc/kpagemap.

--
Mathematics is the supreme nostalgia of our time.
-
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/