lkml.org 
[lkml]   [2018]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [bug] kpti, perf_event, bts: sporadic truncated trace
On Fri, 13 Jul 2018, Metzger, Markus T wrote:
> Hello Hugh,
>
> > A little "optimization" crept into alloc_bts_buffer() along the way, which now
> > places bts_interrupt_threshold not on a record boundary.
> > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This
> > address must point to an offset from the BTS buffer base that is a multiple of the
> > BTS record size."
> >
> > Please give the patch below a try, and let us know if it helps (if it does not, then I
> > think we'll need perfier expertise than I can give).
> >
> > Hugh
> >
> > --- 4.18-rc4/arch/x86/events/intel/ds.c 2018-06-03 14:15:21.000000000 -0700
> > +++ linux/arch/x86/events/intel/ds.c 2018-07-12 17:38:28.471378616 -0700
> > @@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu)
> > ds->bts_buffer_base = (unsigned long) cea;
> > ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL);
> > ds->bts_index = ds->bts_buffer_base;
> > - max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE);
> > - ds->bts_absolute_maximum = ds->bts_buffer_base + max;
> > - ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16);
> > + max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE;
> > + ds->bts_absolute_maximum = ds->bts_buffer_base +
> > + max * BTS_RECORD_SIZE;
> > + ds->bts_interrupt_threshold = ds->bts_absolute_maximum -
> > + (max / 16) * BTS_RECORD_SIZE;
> > return 0;
> > }
> >
>
> Your patch fixes it.

Oh, very welcome news! Thanks for putting in all the effort you did to
track down from your end: I'm relieved it was easier to fix than that.

>
> Will you send it to the list for inclusion?

Sure, I'll send to x86 guys and lkml later today. I can't promise that
it will make 4.18, since the regression it fixes pre-dates 4.18-rc; but
they don't usually insist on that rule for something as small and benign
as this, so I expect it'll make it.

> I'd appreciate if it could also be backported
> to 4.15, 4.16, and 4.17.

I'll mark it Cc stable, so that it will soon percolate through to the
4.14 longterm and 4.17 stable trees. But 4.15 and 4.16 stable trees are
now EOL, so you'll have to apply the patch where you need it yourself -
it has no release-dependent subtlety, it should apply cleanly at offset.

Hugh
\
 
 \ /
  Last update: 2018-07-15 22:07    [W:0.105 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site