> On Dec 12, 2018, at 1:36 PM, Edward Cree wrote:
>
> On 12/12/18 21:15, Nadav Amit wrote:
>>> On Dec 12, 2018, at 10:33 AM, Edward Cree wrote:
>>>
>>> AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an
>>> additional call and ret. So I wouldn't expect it to be too ex
On 12/12/18 21:15, Nadav Amit wrote:
>> On Dec 12, 2018, at 10:33 AM, Edward Cree wrote:
>>
>> AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an
>> additional call and ret. So I wouldn't expect it to be too expensive.
>> More to the point, it seems like it's easier to
> On Dec 12, 2018, at 10:33 AM, Edward Cree wrote:
>
> On 12/12/18 18:14, Nadav Amit wrote:
>> Second, (2i) is not very intuitive for me. Using the out-of-line static
>> calls seems to me as less performant than the inline (potentially, I didn’t
>> check).
>>
>> Anyhow, the use of out-of-line st
On 12/12/18 18:14, Nadav Amit wrote:
> Second, (2i) is not very intuitive for me. Using the out-of-line static
> calls seems to me as less performant than the inline (potentially, I didn’t
> check).
>
> Anyhow, the use of out-of-line static calls seems to me as
> counter-intuitive. I think (didn’t
> On Dec 12, 2018, at 9:11 AM, Edward Cree wrote:
>
> On 12/12/18 05:59, Nadav Amit wrote:
>> Thanks for cc’ing me. (I didn’t know about the other patch-sets.)
> Well in my case, that's because I haven't posted any yet. (Will follow up
> shortly with what I currently have, though it's not prett
On 12/12/18 05:59, Nadav Amit wrote:
> Thanks for cc’ing me. (I didn’t know about the other patch-sets.)
Well in my case, that's because I haven't posted any yet. (Will follow up
shortly with what I currently have, though it's not pretty.)
Looking at your patches, it seems you've got a much more
> On Dec 11, 2018, at 10:05 AM, Josh Poimboeuf wrote:
>
> On Fri, Dec 07, 2018 at 04:06:32PM +, Edward Cree wrote:
>> Sorry if this has been pointed out before (it's a very long thread), but
>> in the out-of-line implementation, it appears that static_call_update()
>> never alters key->func.
On Fri, Dec 07, 2018 at 04:06:32PM +, Edward Cree wrote:
> Sorry if this has been pointed out before (it's a very long thread), but
> in the out-of-line implementation, it appears that static_call_update()
> never alters key->func. Am I right in thinking that this should be
> fixed by addin
Hi!
> These patches are related to two similar patch sets from Ard and Steve:
>
> - https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheu...@linaro.org
> - https://lkml.kernel.org/r/20181006015110.653946...@goodmis.org
>
> The code is also heavily inspired by the jump label code, as some
On 07/12/18 16:06, Edward Cree wrote:
> Sorry if this has been pointed out before (it's a very long thread), but
> in the out-of-line implementation, it appears that static_call_update()
> never alters key->func. Am I right in thinking that this should be
> fixed by adding 'WRITE_ONCE(key->func
Sorry if this has been pointed out before (it's a very long thread), but
in the out-of-line implementation, it appears that static_call_update()
never alters key->func. Am I right in thinking that this should be
fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
arch_static_
>> On Dec 5, 2018, at 7:04 AM, Josh Poimboeuf wrote:
>
>
>> Anyway, I have a new objection to Josh’s create_gap proposal: what on
>> Earth will kernel CET do to it? Maybe my longjmp-like hack is
>> actually better.
>
> Does CET even care about iret? I assumed it didn't. If it does, your
> propo
On Tue, Dec 04, 2018 at 03:41:01PM -0800, Andy Lutomirski wrote:
>
>
> > On Dec 4, 2018, at 3:08 PM, Steven Rostedt wrote:
> >
> >
> > Where did this end up BTW?
> >
> > I know that there's controversy about the
> > CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the
> > CONFIG_H
> On Dec 4, 2018, at 3:08 PM, Steven Rostedt wrote:
>
>
> Where did this end up BTW?
>
> I know that there's controversy about the
> CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the
> CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the
> v1 patch 0 descrip
Where did this end up BTW?
I know that there's controversy about the
CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the
CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the
v1 patch 0 description:
There are three separate implementations, depending on what the a
On Mon, 26 Nov 2018 16:24:20 -0600
Josh Poimboeuf wrote:
> Should I add your tracepoint patch to the next version of my patches?
>
No, not yet. Especially since I haven't totally vetted them.
When yours are ready, I'll post an RFC, and then we can add them in. I
would want an Acked-by from Mat
On Mon, Nov 26, 2018 at 03:54:05PM -0500, Steven Rostedt wrote:
> In summary, we had this:
>
> No RETPOLINES:
> 1.4503 +- 0.0148 seconds time elapsed ( +- 1.02% )
>
> baseline RETPOLINES:
> 1.5120 +- 0.0133 seconds time elapsed ( +- 0.88% )
>
> Added direct calls for
On Mon, Nov 26, 2018 at 07:54:56AM -0600, Josh Poimboeuf wrote:
> v2:
> - fix STATIC_CALL_TRAMP() macro by using __PASTE() [Ard]
> - rename optimized/unoptimized -> inline/out-of-line [Ard]
> - tweak arch interfaces for PLT and add key->tramp field [Ard]
> - rename 'poison' to 'defuse' and do it af
v2:
- fix STATIC_CALL_TRAMP() macro by using __PASTE() [Ard]
- rename optimized/unoptimized -> inline/out-of-line [Ard]
- tweak arch interfaces for PLT and add key->tramp field [Ard]
- rename 'poison' to 'defuse' and do it after all sites have been patched [Ard]
- fix .init handling [Ard, Steven]
-
19 matches
Mail list logo
