On 6/16/2018 8:56 AM, Kyle Huey wrote:
On Fri, Jun 15, 2018 at 5:50 PM, Jin, Yao wrote:
Hi All,
This patch raised many questions, I was prepared. :)
I'd like to try another proposal that it adds a special flag in the returned
perf_sample_data to indicate the perf binary that this sample is
On Fri, Jun 15, 2018 at 5:50 PM, Jin, Yao wrote:
> Hi All,
>
> This patch raised many questions, I was prepared. :)
>
> I'd like to try another proposal that it adds a special flag in the returned
> perf_sample_data to indicate the perf binary that this sample is a leaked
> sample.
>
> For example
Hi All,
This patch raised many questions, I was prepared. :)
I'd like to try another proposal that it adds a special flag in the
returned perf_sample_data to indicate the perf binary that this sample
is a leaked sample.
For example, create a new PERF_SAMPLE_RETURN_LEAKAGE in
perf_event_samp
On Fri, Jun 15, 2018 at 10:16 AM, Kyle Huey wrote:
>
> If you want a sysctl for your own reasons that's fine. But we don't
> want a sysctl. We want to work without any further configuration.
Also toggling a sysctl would require root privileges, but rr does not
currently need to run as root. Thus
On Thu, Jun 14, 2018 at 10:11 PM, Jin, Yao wrote:
>
>
> On 6/15/2018 11:35 AM, Kyle Huey wrote:
>>
>> I strongly object to this patch as written. As I said when I
>> originally reported[0] the regression introduced by the previous
>> version of this patch a year ago.
>>
>> "It seems like this chan
Hi,
On Fri, Jun 15, 2018 at 1:12 AM Peter Zijlstra wrote:
>
> On Fri, Jun 15, 2018 at 04:01:45PM +0800, Jin, Yao wrote:
>
> > Bring more overhead to kernel if we zero the bits considering the number of
> > leaked samples may be not too small?
>
> Keeping the samples at least allows you to know how
On 6/15/2018 4:12 PM, Peter Zijlstra wrote:
On Fri, Jun 15, 2018 at 04:01:45PM +0800, Jin, Yao wrote:
Bring more overhead to kernel if we zero the bits considering the number of
leaked samples may be not too small?
Keeping the samples at least allows you to know how many samples
happened a
On Fri, Jun 15, 2018 at 04:01:45PM +0800, Jin, Yao wrote:
> Bring more overhead to kernel if we zero the bits considering the number of
> leaked samples may be not too small?
Keeping the samples at least allows you to know how many samples
happened and such things.
> And the skid information may
On 6/15/2018 3:45 PM, Peter Zijlstra wrote:
On Fri, Jun 15, 2018 at 06:03:21PM +0800, Jin Yao wrote:
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This might be a security issue because it can leak kernel ad
On Fri, Jun 15, 2018 at 06:03:21PM +0800, Jin Yao wrote:
> On workloads that do a lot of kernel entry/exits we see kernel
> samples, even though :u is specified. This is due to skid existing.
>
> This might be a security issue because it can leak kernel addresses even
> though kernel sampling supp
On 6/15/2018 11:35 AM, Kyle Huey wrote:
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually pe
I strongly object to this patch as written. As I said when I
originally reported[0] the regression introduced by the previous
version of this patch a year ago.
"It seems like this change should, at a bare minimum, be limited to
counters that actually perform sampling of register state when the
int
12 matches
Mail list logo
