From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Calvin Owens <calvinowens@fb.com>,
Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Al Viro <viro@zeniv.linux.org.uk>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Peter Feiner <pfeiner@google.com>,
Grant Likely <grant.likely@secretlab.ca>,
linux-kernel <linux-kernel@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [RFC][PATCH] procfs: Add /proc/<pid>/mapped_files
Date: Thu, 15 Jan 2015 00:51:50 +0100 [thread overview]
Message-ID: <87y4p4gbu1.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <20150114144531.2564398d03c19fd48e4749d9@linux-foundation.org> (Andrew Morton's message of "Wed, 14 Jan 2015 14:45:31 -0800")
On Wed, Jan 14 2015, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 14 Jan 2015 13:03:26 -0800 Calvin Owens <calvinowens@fb.com> wrote:
>>
>> If I understand the current behavior, the "[stack]" marker will get put
>> next to *any* mapping that encompasses the current value in the task's
>> %sp, regardless of how the mapping was created or ucontext stuff. If
>> you use flags on the VMA structs things could potentially be marked as
>> stacks even though %sp points somewhere else.
>>
>> It's probable that nobody cares (you'd obviously have to be doing crazy
>> things to be pointing %sp at arbitrary places), but that's why I was
>> hesitant to mess with it.
>
> Fixing the N^2 search would of course be much better than adding a new
> proc file to sidestep it.
>
> Could we do something like refreshing the new vma.vm_flags:VM_IS_STACK
> on each thread at the time when /proc/PID/maps is opened? So do a walk
> of the threads, use each thread's sp to hunt down the thread's stack's
> vma, then set VM_IS_STACK and fill in the new vma.stack_tid field?
So this would be roughly #tasks*log(#vmas) + #vmas. Sounds
good. Especially since all the work will be done by the reader, so
there's no extra bookkeeping to do in sys_clone etc. Concurrent readers
could influence what each other end up seeing, but most of the time the
update will be idempotent, and the information may be stale anyway by
the time the reader has a chance to process it.
> There are still several flags unused in vma.vm_flags btw.
>
> I'm not sure that we can repurpose vm_pgoff (or vm_private_data) for
> this: a badly behaved thread could make its sp point at a random vma
> then trick the kernel into scribbling on that vma's vm_proff?
Well, we could still check vm_file for being NULL before writing to
vm_pgoff/vm_stack_tid.
> Adding a new field to the vma wouldn't kill us, I guess. That would
> remove the need for a VM_IS_STACK.
Either way, it seems that that decision can be changed later.
Rasmus
next prev parent reply other threads:[~2015-01-14 23:51 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 0:20 Calvin Owens
2015-01-14 0:23 ` Calvin Owens
2015-01-14 14:13 ` Rasmus Villemoes
2015-01-14 14:37 ` Siddhesh Poyarekar
2015-01-14 14:53 ` Rasmus Villemoes
2015-01-14 21:03 ` Calvin Owens
2015-01-14 22:45 ` Andrew Morton
2015-01-14 23:51 ` Rasmus Villemoes [this message]
2015-01-16 1:15 ` Andrew Morton
2015-01-16 11:00 ` Kirill A. Shutemov
2015-01-14 15:25 ` Kirill A. Shutemov
2015-01-14 15:33 ` Cyrill Gorcunov
2015-01-14 20:46 ` Calvin Owens
2015-01-14 21:16 ` Cyrill Gorcunov
2015-01-22 2:45 ` [RFC][PATCH] procfs: Always expose /proc/<pid>/map_files/ and make it readable Calvin Owens
2015-01-22 7:16 ` Cyrill Gorcunov
2015-01-22 11:02 ` Kirill A. Shutemov
2015-01-22 21:00 ` Calvin Owens
2015-01-22 21:27 ` Kirill A. Shutemov
2015-01-23 5:52 ` Calvin Owens
2015-01-24 3:15 ` [RFC][PATCH v2] " Calvin Owens
2015-01-26 12:47 ` Kirill A. Shutemov
2015-01-26 21:00 ` Cyrill Gorcunov
2015-01-26 23:43 ` Andrew Morton
2015-01-27 0:15 ` Kees Cook
2015-01-27 7:37 ` Cyrill Gorcunov
2015-01-27 19:53 ` Kees Cook
2015-01-27 21:35 ` Cyrill Gorcunov
2015-01-27 21:46 ` Pavel Emelyanov
2015-01-27 0:19 ` Kirill A. Shutemov
2015-01-27 6:46 ` Cyrill Gorcunov
2015-01-27 6:50 ` Andrew Morton
2015-01-27 7:23 ` Cyrill Gorcunov
2015-01-28 4:38 ` Calvin Owens
2015-01-30 1:30 ` Kees Cook
2015-01-31 1:58 ` Calvin Owens
2015-02-02 14:01 ` Austin S Hemmelgarn
2015-02-04 3:53 ` Calvin Owens
2015-02-02 20:16 ` Andy Lutomirski
2015-02-04 3:28 ` Calvin Owens
2015-02-12 2:29 ` [RFC][PATCH v3] " Calvin Owens
2015-02-12 7:45 ` Cyrill Gorcunov
2015-02-14 20:40 ` [RFC][PATCH v4] " Calvin Owens
2015-03-10 22:17 ` Cyrill Gorcunov
2015-04-28 22:23 ` Calvin Owens
2015-04-29 7:32 ` Cyrill Gorcunov
2015-05-19 3:10 ` [PATCH v5] " Calvin Owens
2015-05-19 3:29 ` Joe Perches
2015-05-19 18:04 ` Andy Lutomirski
2015-05-21 1:52 ` Calvin Owens
2015-05-21 2:10 ` Andy Lutomirski
2015-06-09 3:39 ` [PATCH v6] " Calvin Owens
2015-06-09 17:27 ` Kees Cook
2015-06-09 17:47 ` Andy Lutomirski
2015-06-09 18:15 ` Cyrill Gorcunov
2015-06-09 21:13 ` Andrew Morton
2015-06-10 1:39 ` Calvin Owens
2015-06-10 20:58 ` Andrew Morton
2015-06-11 11:10 ` Alexey Dobriyan
2015-06-11 18:49 ` Andrew Morton
2015-06-12 9:55 ` Alexey Dobriyan
2015-06-19 2:32 ` [PATCH v7] " Calvin Owens
2015-07-15 22:21 ` Andrew Morton
2015-07-15 23:39 ` Calvin Owens
2015-02-14 20:44 ` [PATCH] procfs: Return -ESRCH on /proc/N/fd/* when PID N doesn't exist Calvin Owens
2015-01-14 22:40 ` [RFC][PATCH] procfs: Add /proc/<pid>/mapped_files Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4p4gbu1.fsf@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=calvinowens@fb.com \
--cc=ebiederm@xmission.com \
--cc=grant.likely@secretlab.ca \
--cc=kernel-team@fb.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pfeiner@google.com \
--cc=siddhesh.poyarekar@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®