linux-kernel - Re: [bug report][stable] perf probe: failed to add events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7ccd9cb-3a66-98a9-faa1-7ee5ed20ff88@linux.alibaba.com>
Date:   Tue, 26 Feb 2019 20:32:34 +0800
From:   Joseph Qi <joseph.qi@...ux.alibaba.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        luto@...nel.org, Jiufei Xue <jiufei.xue@...ux.alibaba.com>,
        Xu Yu <xuyu@...ux.alibaba.com>, peterz@...radead.org,
        mingo@...hat.com, acme@...nel.org
Subject: Re: [bug report][stable] perf probe: failed to add events



On 19/2/26 17:05, Greg KH wrote:
> On Tue, Feb 26, 2019 at 03:31:14PM +0800, Joseph Qi wrote:
>> Hi,
>>
>> I'm using kernel v4.19.24 and have found that there is an issue when
>> using perf probe to define a new dynamic tracepoint.
>>
>> $ perf probe -a handle_mm_fault
>> Failed to write event: Numerical result out of range
>>   Error: Failed to add events.
>>
>> I've also tried kernel v4.20, and it can pass.
> 
> Ick, has this ever worked on the 4.19 stable tree?  If so, any chance
> you can run 'git bisect' to find the offending commit?
> 
>From my test, v4.19.0 also has this issue.
Bisect locates that it is introduced by commit bf904d2762ee
"x86/pti/64: Remove the SYSCALL64 entry trampoline".

Thanks,
Joseph

>> So I've bisected and finally found the first good commit is:
>> bf904d2762ee x86/pti/64: Remove the SYSCALL64 entry trampoline
>> which is based on another commit:
>> 98f05b5138f0 Use the TSS sp2 slot for SYSCALL/SYSRET scratch space
>>
>> Once I've backpoted these two commits into 4.19.24, the above case can
>> pass, though I'm not sure how it is fixed.
>> So is there any plan to let them go into stable as well?
> 
> If they are needed, I'll gladly queue them up, but this feels like
> something might have broken, so it should be easier to just revert the
> offending commit instead.
> 
> Andy, any ideas?
> 
> thanks,
> 
> greg k-h
>