On Mon, Feb 25, 2019 at 02:21:03PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 25, 2019 at 12:47:00AM -0800, h...@zytor.com wrote:
> > It doesn't have to understand the contents of the memop, but it seems
> > that the presence of a modrm with mode ≠ 3 should be plenty. It needs
> > to know that
> On Feb 25, 2019, at 3:53 AM, Peter Zijlstra wrote:
>
>> On Mon, Feb 25, 2019 at 11:51:44AM +0100, Peter Zijlstra wrote:
>>> On Fri, Feb 22, 2019 at 03:55:25PM -0800, Andy Lutomirski wrote:
>>> I'm wondering if we can just change the code that does getreg() and
>>> load_gs_index() so it
On Mon, Feb 25, 2019 at 12:47:00AM -0800, h...@zytor.com wrote:
> It doesn't have to understand the contents of the memop, but it seems
> that the presence of a modrm with mode ≠ 3 should be plenty. It needs
> to know that much in order to know the length of instructions anyway.
> For extra
On Mon, Feb 25, 2019 at 08:33:35AM +, Julien Thierry wrote:
> > It has an AC_SAFE(func) annotation which allows marking specific
> > functions as safe to call. The patch includes 2 instances which were
> > required to make arch/x86 'build':
> I haven't looked at all the details. But could the
On Mon, Feb 25, 2019 at 11:51:44AM +0100, Peter Zijlstra wrote:
> On Fri, Feb 22, 2019 at 03:55:25PM -0800, Andy Lutomirski wrote:
> > I'm wondering if we can just change the code that does getreg() and
> > load_gs_index() so it doesn't do it with AC set. Also, what about
> > paravirt kernels?
On Fri, Feb 22, 2019 at 03:55:25PM -0800, Andy Lutomirski wrote:
> I'm wondering if we can just change the code that does getreg() and
> load_gs_index() so it doesn't do it with AC set. Also, what about
> paravirt kernels? They'll call into PV code for load_gs_index() with
> AC set.
Paravirt
On February 23, 2019 12:39:42 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 03:39:48PM -0800, h...@zytor.com wrote:
>> Objtool could also detect CLAC-STAC or STAC-CLAC sequences without
>> memory operations and remove them; don't know how often that happens,
>> but I know it *does*
On February 23, 2019 12:39:42 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 03:39:48PM -0800, h...@zytor.com wrote:
>> Objtool could also detect CLAC-STAC or STAC-CLAC sequences without
>> memory operations and remove them; don't know how often that happens,
>> but I know it *does*
On 22/02/2019 22:26, Peter Zijlstra wrote:
> On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
>
>> But correct :)
>
>> I agree, that a function which is doing the actual copy should be callable,
>> but random other functions? NO!
>
> So find the below patch -- which spotted
On Sat, Feb 23, 2019 at 09:37:06AM +0100, Peter Zijlstra wrote:
> On Fri, Feb 22, 2019 at 03:55:25PM -0800, Andy Lutomirski wrote:
> > On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote:
>
> > > arch/x86/entry/entry_64.o: warning: objtool:
> > > .altinstr_replacement+0xb1: redundant CLAC
>
On Fri, Feb 22, 2019 at 03:34:00PM -0800, Linus Torvalds wrote:
> Can you make it do DF too while at it?
Sure.
On Fri, Feb 22, 2019 at 03:39:48PM -0800, h...@zytor.com wrote:
> Objtool could also detect CLAC-STAC or STAC-CLAC sequences without
> memory operations and remove them; don't know how often that happens,
> but I know it *does* happen.
Objtool doesn't know about memops; that'd be a lot of work.
On Fri, Feb 22, 2019 at 03:55:25PM -0800, Andy Lutomirski wrote:
> On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote:
> > arch/x86/entry/entry_64.o: warning: objtool: .altinstr_replacement+0xb1:
> > redundant CLAC
>
> Does objtool understand altinstr?
Yep, otherwise it would've never
On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote:
>
> On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
>
> > But correct :)
>
> > I agree, that a function which is doing the actual copy should be callable,
> > but random other functions? NO!
>
> So find the below patch --
On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra wrote:
>
> So find the below patch -- which spotted fail in ptrace.c
>
> It has an AC_SAFE(func) annotation which allows marking specific
> functions as safe to call. The patch includes 2 instances which were
> required to make arch/x86 'build':
On February 22, 2019 2:26:35 PM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
>
>> But correct :)
>
>> I agree, that a function which is doing the actual copy should be
>callable,
>> but random other functions? NO!
>
>So find the below patch --
On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
> But correct :)
> I agree, that a function which is doing the actual copy should be callable,
> but random other functions? NO!
So find the below patch -- which spotted fail in ptrace.c
It has an AC_SAFE(func) annotation which
17 matches
Mail list logo
