On Thu, Oct 17, 2013 at 08:24:17PM +0200, Oleg Nesterov wrote:
> Subject: [PATCH] perf: Factor out strncpy() in perf_event_mmap_event()
> From: Oleg Nesterov
> Date: Thu, 17 Oct 2013 20:04:17 +0200
>
> While this is really minor, but strncpy() does the unnecessary
> zero-padding till the end of t
On 10/17, Peter Zijlstra wrote:
>
> - name = arch_vma_name(vma);
> + name = (char *)arch_vma_name(vma);
Yes, this way we do not need another non-const ptr.
OK, please consider another cleanup on top of this change.
Just to "complete" the discussion, do not even bother to
On Thu, Oct 17, 2013 at 05:27:17PM +0200, Oleg Nesterov wrote:
> On 10/17, Oleg Nesterov wrote:
> >
> > - we do not really need "len", we can simply do
> >
> > size = strlen(name) + 1;
> > while (size % sizeof(u64))
> > name[size++] = '\0';
> >
> >
On Thu, Oct 17, 2013 at 05:20:27PM +0200, Oleg Nesterov wrote:
> On 10/16, Peter Zijlstra wrote:
> >
> > On Wed, Oct 16, 2013 at 10:58:00PM +0200, Oleg Nesterov wrote:
> > > OK. I'll wait for your review on this series, then send the next patch.
> > >
> >
> > Those two patches look good; thanks.
>
On 10/17, Oleg Nesterov wrote:
>
> - we do not really need "len", we can simply do
>
> size = strlen(name) + 1;
> while (size % sizeof(u64))
> name[size++] = '\0';
>
> although I won't argue if you dislike "size & 7" in while().
Or, p
On 10/16, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2013 at 10:58:00PM +0200, Oleg Nesterov wrote:
> > OK. I'll wait for your review on this series, then send the next patch.
> >
>
> Those two patches look good; thanks.
Thanks, can I have your acks for Ingo ?
> How about something like so on top?
On Wed, Oct 16, 2013 at 10:58:00PM +0200, Oleg Nesterov wrote:
> OK. I'll wait for your review on this series, then send the next patch.
>
Those two patches look good; thanks. How about something like so on top?
---
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5103,18 +5103,16 @@ st
On 10/16, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2013 at 10:43:48PM +0200, Oleg Nesterov wrote:
> > Peter, just in case. I understand that this all is minor. Just I am
> > confused. And in any case I do think we do not need __GFP_ZERO when
> > it comes to PAGE_SIZE allocation.
>
> Yeah; we could
On 10/16, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2013 at 10:43:48PM +0200, Oleg Nesterov wrote:
> > Yes, we can copy the garbage to the userspace. So what? This should not
> > matter at all. Exactly because userspace should never used the data after
> > the end of string, no?
>
> Security people
On Wed, Oct 16, 2013 at 10:43:48PM +0200, Oleg Nesterov wrote:
> Peter, just in case. I understand that this all is minor. Just I am
> confused. And in any case I do think we do not need __GFP_ZERO when
> it comes to PAGE_SIZE allocation.
Yeah; we could probably avoid it; if only the strcpy functi
On Wed, Oct 16, 2013 at 10:43:48PM +0200, Oleg Nesterov wrote:
> Yes, we can copy the garbage to the userspace. So what? This should not
> matter at all. Exactly because userspace should never used the data after
> the end of string, no?
Security people tell me to _never_ leak anything. I'm not ne
On 10/16, Peter Zijlstra wrote:
>
> On Wed, Oct 16, 2013 at 10:09:24PM +0200, Oleg Nesterov wrote:
> > 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.
>
> Righ
On Wed, Oct 16, 2013 at 10:09:24PM +0200, Oleg Nesterov wrote:
> 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.
Right, but x86_64 will return [vsyscall] and we'll
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
14 matches
Mail list logo
