From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] (Was: perf_event_mmap(vma) && !vma->vm_mm)
Date: Wed, 16 Oct 2013 22:09:24 +0200 [thread overview]
Message-ID: <20131016200924.GA23214@redhat.com> (raw)
In-Reply-To: <20131014102426.GX3081@twins.programming.kicks-ass.net>
Peter,
you know, I was going to forget about this, but then I looked at
perf_event_mmap_event() again and I am even more puzzled.
I believe it asks for cleanups.
On 10/14, Peter Zijlstra wrote:
>
> On Sat, Oct 12, 2013 at 09:22:03PM +0200, Oleg Nesterov wrote:
> >
> > But please ignore, the only question is that I can't understand
> > this
> >
> > if (!vma->vm_mm) {
> > name = strncpy(tmp, "[vdso]", sizeof(tmp));
> > goto got_name;
> > }
> >
> > code in perf_event_mmap_event() and I am just curious. How it is
> > possible that vma->vm_mm == NULL ? perf_event_mmap(vma) is never
> > called with, say, vma == gate_vma. And even if it was possible
> > arch_vma_name() should handle this case?
>
> Uuuhhhh... I wrote that didn't I ;-)
>
> So I think that was due to the x86_32 gate_vma, but yes I don't think
> we'd ever call perf_event_mmap() (perf_counter_mmap at the time) on it.
OK, so I think this code should die, it only adds the confusion.
Note also that at least on x86_64 "[vdso]" is not correct (if !vma_mm
was possible), this adds more confusion.
> Also, the x86_32 arch_vma_name() didn't deal with the gate_vma (it still
> doesn't appear to do so) as opposed to x86_64 which does.
Hmm... I am looking into arch/x86/vdso/vdso32-setup.c, it seems it does.
But probably I missed something, this doesn't matter.
> But the main reason I added it was because task_mmu.c:show_map_vma() did
> so too; I just wanted to be extra careful.
Yes, but this code can actually hit gate_vma. (and I'd say that if some
arch/ has the global gate_vma-like vma's, it should implement arch_vma_name
correctly, but this is off-topic).
---------------------------------------------------------------------------
Please look at these 2 simple patches. Initially I was going to send
the 3rd patch, but I simply can't understand the "align" logic.
First of all, we surely do not need __GFP_ZERO for kzalloc(PATH_MAX),
even if we need to nullify the alignment. So I am going to send another
patch in any case.
But do we really need to nullify the extra bytes after strlen()? If yes,
for what? If no, we can simply do s/kzalloc/kmalloc/ and kill that
memset(tmp, 0, sizeof(tmp)) at the start.
Otoh. Why do we need the temporary string buffer (char tmp[16]) at all?
We either use the result from d_path() (which has a room), or we use a
string literal (may be returned by arch_vma_name), in the latter case
it is safe to assume we can read the extra 7 bytes from .data?
IOW. Could you explain why the patch below (on top of 1-2) is wrong?
Thanks,
Oleg.
--- x/kernel/events/core.c
+++ x/kernel/events/core.c
@@ -5098,19 +5098,16 @@ static void perf_event_mmap_event(struct perf_mmap_event *mmap_event)
int maj = 0, min = 0;
u64 ino = 0, gen = 0;
unsigned int size;
- char tmp[16];
char *buf = NULL;
const char *name;
- memset(tmp, 0, sizeof(tmp));
-
if (file) {
struct inode *inode;
dev_t dev;
- buf = kzalloc(PATH_MAX, GFP_KERNEL);
+ buf = kmalloc(PATH_MAX, GFP_KERNEL);
if (!buf) {
- name = strncpy(tmp, "//enomem", sizeof(tmp));
+ name = "//enomem";
goto got_name;
}
/*
@@ -5120,7 +5117,7 @@ static void perf_event_mmap_event(struct perf_mmap_event *mmap_event)
*/
name = d_path(&file->f_path, buf, PATH_MAX - sizeof(u64));
if (IS_ERR(name)) {
- name = strncpy(tmp, "//toolong", sizeof(tmp));
+ name = "//toolong";
goto got_name;
}
inode = file_inode(vma->vm_file);
@@ -5133,23 +5130,21 @@ static void perf_event_mmap_event(struct perf_mmap_event *mmap_event)
} else {
name = arch_vma_name(vma);
if (name) {
- name = strncpy(tmp, name, sizeof(tmp) - 1);
- tmp[sizeof(tmp) - 1] = '\0';
goto got_name;
}
if (vma->vm_start <= vma->vm_mm->start_brk &&
vma->vm_end >= vma->vm_mm->brk) {
- name = strncpy(tmp, "[heap]", sizeof(tmp));
+ name = "[heap]";
goto got_name;
}
if (vma->vm_start <= vma->vm_mm->start_stack &&
vma->vm_end >= vma->vm_mm->start_stack) {
- name = strncpy(tmp, "[stack]", sizeof(tmp));
+ name = "[stack]";
goto got_name;
}
- name = strncpy(tmp, "//anon", sizeof(tmp));
+ name = "//anon";
goto got_name;
}
next prev parent reply other threads:[~2013-10-16 20:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-12 19:22 perf_event_mmap(vma) && !vma->vm_mm Oleg Nesterov
2013-10-14 10:24 ` Peter Zijlstra
2013-10-16 20:09 ` Oleg Nesterov [this message]
2013-10-16 20:09 ` [PATCH 1/2] perf: Kill the dead !vma->vm_mm code in perf_event_mmap_event() Oleg Nesterov
2013-10-29 14:08 ` [tip:perf/core] perf: Kill the dead !vma-> vm_mm " tip-bot for Oleg Nesterov
2013-10-16 20:10 ` [PATCH 2/2] perf: Do not waste PAGE_SIZE bytes for ALIGN(8) " Oleg Nesterov
2013-10-29 14:08 ` [tip:perf/core] " tip-bot for Oleg Nesterov
2013-10-16 20:28 ` [PATCH 0/2] (Was: perf_event_mmap(vma) && !vma->vm_mm) Peter Zijlstra
2013-10-16 20:43 ` Oleg Nesterov
2013-10-16 20:55 ` Peter Zijlstra
2013-10-16 20:55 ` Oleg Nesterov
2013-10-16 20:58 ` Peter Zijlstra
2013-10-16 20:58 ` Oleg Nesterov
2013-10-16 21:16 ` Peter Zijlstra
2013-10-17 15:20 ` Oleg Nesterov
2013-10-17 15:27 ` Oleg Nesterov
2013-10-17 16:47 ` Peter Zijlstra
2013-10-17 18:24 ` Oleg Nesterov
2013-10-17 21:32 ` Peter Zijlstra
2013-11-06 13:19 ` [tip:perf/core] perf: Factor out strncpy() in perf_event_mmap_event() tip-bot for Oleg Nesterov
2013-10-17 16:38 ` [PATCH 0/2] (Was: perf_event_mmap(vma) && !vma->vm_mm) Peter Zijlstra
2013-10-17 15:22 ` [PATCH 3/2] perf: Optimize the fill/align code in perf_event_mmap_event() Oleg Nesterov
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=20131016200924.GA23214@redhat.com \
--to=oleg@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.