On Mon, Mar 11, 2013 at 06:44:45PM +0100, Peter Zijlstra wrote:
> On Mon, 2013-03-11 at 17:43 +0100, Jiri Olsa wrote:
>
> > I did not know there were other plans for that, seemed useless
>
> I like to keep form, confuses me less :-)
ook
>
> Anyway, why are we getting to that part of perf_outpu
On Mon, 2013-03-11 at 17:43 +0100, Jiri Olsa wrote:
> I did not know there were other plans for that, seemed useless
I like to keep form, confuses me less :-)
Anyway, why are we getting to that part of perf_output_begin() if we
don't have any data pages to begin with? Shouldn't we bail before th
On Mon, Mar 11, 2013 at 05:26:33PM +0100, Peter Zijlstra wrote:
> On Mon, 2013-03-11 at 12:21 +0100, Jiri Olsa wrote:
> > > pg_nr = offset >> page_shift;
> > > pg_offset = offset & (1 << page_shift) - 1;
> > >
> > > You just wrecked that.
> > >
> > > > handle->page &= rb->nr_pages - 1;
On Mon, 2013-03-11 at 12:21 +0100, Jiri Olsa wrote:
> > pg_nr = offset >> page_shift;
> > pg_offset = offset & (1 << page_shift) - 1;
> >
> > You just wrecked that.
> >
> > > handle->page &= rb->nr_pages - 1;
>
> here's ^^^ where the handle->page becomes 0 due to (rb->nr_pages == 0)
t
* Jiri Olsa wrote:
> > > struct page *
> > > perf_mmap_to_page(struct ring_buffer *rb, unsigned long pgoff)
> > > {
> > > - if (pgoff > (1UL << page_order(rb)))
> > > + if (pgoff > page_nr(rb))
> > > return NULL;
> >
> > This is just wrong.. you have page_nr() be 1+2^n, but the com
heya ;)
great to hear from you again!
On Mon, Mar 11, 2013 at 10:40:43AM +0100, Peter Zijlstra wrote:
> On Fri, 2013-03-01 at 17:34 +0100, Jiri Olsa wrote:
> > If we allocate perf ring buffer with the size of single page,
SNIP
> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_bu
On Fri, 2013-03-01 at 17:34 +0100, Jiri Olsa wrote:
> If we allocate perf ring buffer with the size of single page,
> we will get memory corruption when releasing it. It's caused
> by rb_free_work function (CONFIG_PERF_USE_VMALLOC option).
>
> For single page sized ring buffer the page_order is -1
2013/3/6 Jiri Olsa :
> nope, because CONFIG_PERF_USE_VMALLOC rb uses only 1st slot
> of rg->data_pages[], so rb->nr_page is either 0 or 1
>
> the actuall number of pages is counted via rb->page_order
> (which is -1 for case with no data pages)
Ah right.
--
To unsubscribe from this list: send the l
On Wed, Mar 06, 2013 at 04:20:15PM +0100, Frederic Weisbecker wrote:
> 2013/3/1 Jiri Olsa :
> > If we allocate perf ring buffer with the size of single page,
> > we will get memory corruption when releasing it. It's caused
> > by rb_free_work function (CONFIG_PERF_USE_VMALLOC option).
> >
> > For s
2013/3/1 Jiri Olsa :
> If we allocate perf ring buffer with the size of single page,
> we will get memory corruption when releasing it. It's caused
> by rb_free_work function (CONFIG_PERF_USE_VMALLOC option).
>
> For single page sized ring buffer the page_order is -1 (because
> nr_pages is 0). This
If we allocate perf ring buffer with the size of single page,
we will get memory corruption when releasing it. It's caused
by rb_free_work function (CONFIG_PERF_USE_VMALLOC option).
For single page sized ring buffer the page_order is -1 (because
nr_pages is 0). This needs to be recognized in the r
11 matches
Mail list logo
