On September 12, 2019 8:00:39 AM GMT+01:00, Adrian Hunter
wrote:
>On 29/08/19 2:46 PM, Peter Zijlstra wrote:
>> On Thu, Aug 29, 2019 at 12:40:56PM +0300, Adrian Hunter wrote:
>>> Can you expand on "and ensure the poke_handler preserves the
>existing
>>> control flow"? Whatever the INT3-handler
On 29/08/19 2:46 PM, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 12:40:56PM +0300, Adrian Hunter wrote:
>> Can you expand on "and ensure the poke_handler preserves the existing
>> control flow"? Whatever the INT3-handler does will be traced normally so
>> long as it does not itself execute
On Thu, Aug 29, 2019 at 12:40:56PM +0300, Adrian Hunter wrote:
> Can you expand on "and ensure the poke_handler preserves the existing
> control flow"? Whatever the INT3-handler does will be traced normally so
> long as it does not itself execute self-modified code.
My thinking was that the code
On 29/08/19 11:53 AM, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 11:23:52AM +0300, Adrian Hunter wrote:
>> On 9/01/19 12:35 PM, Peter Zijlstra wrote:
>>> On Tue, Jan 08, 2019 at 12:47:42PM -0800, Nadav Amit wrote:
>>>
A general solution is more complicated, however, due to the racy
On Thu, Aug 29, 2019 at 11:23:52AM +0300, Adrian Hunter wrote:
> On 9/01/19 12:35 PM, Peter Zijlstra wrote:
> > On Tue, Jan 08, 2019 at 12:47:42PM -0800, Nadav Amit wrote:
> >
> >> A general solution is more complicated, however, due to the racy nature of
> >> cross-modifying code. There would
On 9/01/19 12:35 PM, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 12:47:42PM -0800, Nadav Amit wrote:
>
>> A general solution is more complicated, however, due to the racy nature of
>> cross-modifying code. There would need to be TSC recording of the time
>> before the modifications start and
On Tue, Jan 08, 2019 at 12:47:42PM -0800, Nadav Amit wrote:
> A general solution is more complicated, however, due to the racy nature of
> cross-modifying code. There would need to be TSC recording of the time
> before the modifications start and after they are done.
>
> BTW: I am not sure that
> BTW: I am not sure that static-keys are much better. Their change also
> affects the control flow, and they do affect the control flow.
Static keys have the same problem, but they only change infrequently so usually
it's not too big a problem if you dump the kernel close to the tracing
> On Jan 8, 2019, at 11:01 AM, Peter Zijlstra wrote:
>
> On Tue, Jan 08, 2019 at 10:28:02AM -0800, Nadav Amit wrote:
>> Is it really that important for debugging to get the instructions at the
>> time of execution? Wouldn’t it be easier to annotate the instructions that
>> might change? After
On Tue, Jan 08, 2019 at 10:28:02AM -0800, Nadav Amit wrote:
> Is it really that important for debugging to get the instructions at the
> time of execution? Wouldn’t it be easier to annotate the instructions that
> might change? After all, it is not as if any instruction can change to any
> other
On Tue, Jan 08, 2019 at 09:27:21AM -0800, Andi Kleen wrote:
> It doesn't work when the code is modified in place, like the
> patch in the $SUBJECT.
For in-place modification a-la jump_label / static_call etc. we can
'trivially' log the new instruction and the decoder can do matching
in-place
> On Jan 8, 2019, at 9:27 AM, Andi Kleen wrote:
>
> On Tue, Jan 08, 2019 at 11:10:58AM +0100, Peter Zijlstra wrote:
>> On Tue, Jan 08, 2019 at 12:01:11PM +0200, Adrian Hunter wrote:
>>> The problem is that the jitted code gets freed from memory, which is why I
>>> suggested the ability to pin it
On Tue, Jan 08, 2019 at 11:10:58AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 12:01:11PM +0200, Adrian Hunter wrote:
> > The problem is that the jitted code gets freed from memory, which is why I
> > suggested the ability to pin it for a while.
>
> Then what do you tell the guy that
On Tue, Jan 08, 2019 at 12:01:11PM +0200, Adrian Hunter wrote:
> The problem is that the jitted code gets freed from memory, which is why I
> suggested the ability to pin it for a while.
Then what do you tell the guy that keeps PT running for a day and runs
out of memory because he likes to JIT a
On 8/01/19 11:25 AM, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote:
>> On 7/01/19 6:32 PM, Peter Zijlstra wrote:
>>> On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
Nadav Amit writes:
>
> - Do we use periodic learning or not? Josh
On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote:
> On 7/01/19 6:32 PM, Peter Zijlstra wrote:
> > On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
> >> Nadav Amit writes:
> >>>
> >>> - Do we use periodic learning or not? Josh suggested to reconfigure the
> >>> branches
On 7/01/19 6:32 PM, Peter Zijlstra wrote:
> On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
>> Nadav Amit writes:
>>>
>>> - Do we use periodic learning or not? Josh suggested to reconfigure the
>>> branches whenever a new target is found. However, I do not know at
>>> this time
On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
> Nadav Amit writes:
> >
> > - Do we use periodic learning or not? Josh suggested to reconfigure the
> > branches whenever a new target is found. However, I do not know at
> > this time how to do learning efficiently, without making
Nadav Amit writes:
>
> - Do we use periodic learning or not? Josh suggested to reconfigure the
> branches whenever a new target is found. However, I do not know at
> this time how to do learning efficiently, without making learning much
> more expensive.
FWIW frequent patching will likely
On Thu, Jan 03, 2019 at 06:30:08PM +, Nadav Amit wrote:
> > On Jan 3, 2019, at 10:10 AM, Josh Poimboeuf wrote:
> >
> > On Mon, Dec 31, 2018 at 07:53:06PM +, Nadav Amit wrote:
> >>> On Dec 31, 2018, at 11:51 AM, Andy Lutomirski wrote:
> >>>
> >>> On Sun, Dec 30, 2018 at 11:20 PM Nadav
> On Jan 3, 2019, at 10:10 AM, Josh Poimboeuf wrote:
>
> On Mon, Dec 31, 2018 at 07:53:06PM +, Nadav Amit wrote:
>>> On Dec 31, 2018, at 11:51 AM, Andy Lutomirski wrote:
>>>
>>> On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
This is a revised version of optpolines (formerly named
On Mon, Dec 31, 2018 at 07:53:06PM +, Nadav Amit wrote:
> > On Dec 31, 2018, at 11:51 AM, Andy Lutomirski wrote:
> >
> > On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
> >> This is a revised version of optpolines (formerly named retpolines) for
> >> dynamic indirect branch promotion in
> On Dec 31, 2018, at 11:51 AM, Andy Lutomirski wrote:
>
> On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>> This is a revised version of optpolines (formerly named retpolines) for
>> dynamic indirect branch promotion in order to reduce retpoline overheads
>> [1].
>
> Some of your
On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit wrote:
>
> This is a revised version of optpolines (formerly named retpolines) for
> dynamic indirect branch promotion in order to reduce retpoline overheads
> [1].
Some of your changelogs still call them "relpolines".
I have a crazy suggestion: maybe
This is a revised version of optpolines (formerly named retpolines) for
dynamic indirect branch promotion in order to reduce retpoline overheads
[1].
This version address some of the concerns that were raised before.
Accordingly, the code was slightly simplified and patching is now done
using the
25 matches
Mail list logo
