Messages in this thread | | | Date | Wed, 14 Jan 2015 17:25:01 +0200 | From | "Kirill A. Shutemov" <> | Subject | Re: [RFC][PATCH] procfs: Add /proc/<pid>/mapped_files |
| |
On Tue, Jan 13, 2015 at 04:20:29PM -0800, Calvin Owens wrote: > Commit b76437579d1344b6 ("procfs: mark thread stack correctly in > proc/<pid>/maps") introduced logic to mark thread stacks with the > "[stack:%d]" marker in /proc/<pid>/maps. > > This causes reading /proc/<pid>/maps to take O(N^2) time, where N is > the number of threads sharing an address space, since each line of > output requires iterating over the VMA list looking for ranges that > correspond to the stack pointer in any task's register set. When > dealing with highly-threaded Java applications, reading this file can > take hours and trigger softlockup dumps. > > Eliminating the "[stack:%d]" marker is not a viable option since it's > been there for some time, and I don't see a way to do the stack check > more efficiently that wouldn't end up making the whole thing really > ugly. > > The use case I'm specifically concerned with is the lsof command, so > this patch adds an additional file, "mapped_files", that simply > iterates over the VMAs associated with the task and outputs a > newline-delimited list of the pathnames of the files associated with > the VMAs, if any. > > This gives lsof and suchlike a way to determine the pathnames of files > mapped into a process without incurring the O(N^2) behavior of the > maps file.
We already have /proc/PID/map_files/ directory which lists all mapped files. Should we consider relaxing permission checking there and move it outside CONFIG_CHECKPOINT_RESTORE instead?
Restriction to CAP_SYSADMIN for follow_link is undertansble, but why do we restrict readdir and readlink?
-- Kirill A. Shutemov
| |