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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/