On Wed, Mar 06, 2019 at 09:59:11AM -0800, Linus Torvalds wrote:
> Maybe we could just get rid of that oddity, and just make __ASM_CLAC
> be a string to begin with.
Seems to work.. I'll add it to the pile.
---
arch/x86/include/asm/smap.h | 19 +--
1 file changed, 9
On Wed, Mar 6, 2019 at 9:37 AM Peter Zijlstra wrote:
>
> The below seems to 'work'.
Yeah, and makes things cheaper for the non-SMAP case too. Looks sane.
One note:
+ asm volatile (ALTERNATIVE("", "pushf; pop %0; "
__stringify(__ASM_CLAC),
Hmm. Every single use of __ASM_CLAC is together
On Wed, Mar 06, 2019 at 06:14:51PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 06, 2019 at 02:13:47PM +0100, Peter Zijlstra wrote:
> > +static __always_inline unsigned long smap_save(void)
> > +{
> > + unsigned long flags = arch_local_save_flags();
> > + clac();
> > + return flags;
> > +}
> >
On Wed, Mar 6, 2019 at 9:14 AM Peter Zijlstra wrote:
>
> And that (obviously) explodes.. Anybody got any clue why that Xen
> trainwreck wants to paravirt: "PUSHF;POP" and "PUSH;POPF" !?
Trying to regenerate the IF flag? I dunno.
But yeah, I think you could just force all of it into an explicit
On Wed, Mar 06, 2019 at 02:13:47PM +0100, Peter Zijlstra wrote:
> +static __always_inline unsigned long smap_save(void)
> +{
> + unsigned long flags = arch_local_save_flags();
> + clac();
> + return flags;
> +}
> +
> +static __always_inline void smap_restore(unsigned long flags)
> +{
>
On Wed, Mar 6, 2019 at 3:56 PM Peter Zijlstra wrote:
>
> On Wed, Mar 06, 2019 at 03:40:51PM +0100, Dmitry Vyukov wrote:
> > On Wed, Mar 6, 2019 at 3:34 PM Peter Zijlstra wrote:
>
> > > mm/kasan/generic_report.o: warning: objtool:
> > > __asan_report_load1_noabort()+0x0: call to __fentry__()
On Wed, Mar 06, 2019 at 03:40:51PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 6, 2019 at 3:34 PM Peter Zijlstra wrote:
> > mm/kasan/generic_report.o: warning: objtool:
> > __asan_report_load1_noabort()+0x0: call to __fentry__() with UACCESS enabled
> But if it makes things simpler for the
On Wed, Mar 6, 2019 at 3:40 PM Dmitry Vyukov wrote:
>
> On Wed, Mar 6, 2019 at 3:34 PM Peter Zijlstra wrote:
> >
> > On Wed, Mar 06, 2019 at 03:12:37PM +0100, Peter Zijlstra wrote:
> > > On Wed, Mar 06, 2019 at 03:01:33PM +0100, Dmitry Vyukov wrote:
> > > > On Wed, Mar 6, 2019 at 2:57 PM Peter
On Wed, Mar 6, 2019 at 3:34 PM Peter Zijlstra wrote:
>
> On Wed, Mar 06, 2019 at 03:12:37PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 06, 2019 at 03:01:33PM +0100, Dmitry Vyukov wrote:
> > > On Wed, Mar 6, 2019 at 2:57 PM Peter Zijlstra
> > > wrote:
> >
> > > > I've not found callers of
On Wed, Mar 06, 2019 at 03:12:37PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 06, 2019 at 03:01:33PM +0100, Dmitry Vyukov wrote:
> > On Wed, Mar 6, 2019 at 2:57 PM Peter Zijlstra wrote:
>
> > > I've not found callers of __asan_report_load* with AC=1 in the kernel
> > > yet. Under what condtions
On Wed, Mar 06, 2019 at 03:01:33PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 6, 2019 at 2:57 PM Peter Zijlstra wrote:
> > I've not found callers of __asan_report_load* with AC=1 in the kernel
> > yet. Under what condtions does GCC emit calls to these functions?
>
> CONFIG_KASAN_INLINE=y
> Then
On Wed, Mar 6, 2019 at 2:57 PM Peter Zijlstra wrote:
>
> On Wed, Mar 06, 2019 at 02:39:33PM +0100, Dmitry Vyukov wrote:
> > On Wed, Mar 6, 2019 at 2:13 PM Peter Zijlstra wrote:
>
> > > annotated:
> > >
> > > 0150 <__asan_load1>:
> > > 150: 48 b8 ff ff ff ff ff
On Wed, Mar 06, 2019 at 02:39:33PM +0100, Dmitry Vyukov wrote:
> On Wed, Mar 6, 2019 at 2:13 PM Peter Zijlstra wrote:
> > annotated:
> >
> > 0150 <__asan_load1>:
> > 150: 48 b8 ff ff ff ff ffmovabs $0x7fff,%rax
> > 0007 157: 7f ff ff
> > 000a
On Wed, Mar 6, 2019 at 2:13 PM Peter Zijlstra wrote:
>
> On Fri, Mar 01, 2019 at 04:23:05PM +0100, Peter Zijlstra wrote:
>
> > But yes, I'll try some annotation, see what that looks like.
>
> OK; that took a lot of time.. and a number of objtool bugs fixed but I
> think I have something that I
On Fri, Mar 01, 2019 at 04:23:05PM +0100, Peter Zijlstra wrote:
> But yes, I'll try some annotation, see what that looks like.
OK; that took a lot of time.. and a number of objtool bugs fixed but I
think I have something that I don't hate -- although it is not as solid
as I'd like it to be.
On Fri, Mar 01, 2019 at 04:06:17PM +0100, Dmitry Vyukov wrote:
> It involves asm, hardware exceptions, UD2 instructions. It also seems
> to use arch-dependent code in arch-independent files: there is no RSI
> on other arches, does this compile on non-x86?
> > +#ifndef kasan_report
> > +#define
On Fri, Mar 1, 2019 at 3:46 PM Peter Zijlstra wrote:
>
> On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
> > On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
> > >
> > > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
> > > UACCESS context, and
On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
> >
> > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
> > UACCESS context, and kasan_report() is most definitely _NOT_ safe to
> > be called from there,
On Thu, Feb 28, 2019 at 6:46 PM Peter Zijlstra wrote:
>
> On Thu, Feb 28, 2019 at 05:03:09PM +0100, Dmitry Vyukov wrote:
>
> > I am missing some knowledge about SMAP to answer this.
> > In short, these tools insert lots of callbacks into runtime for memory
> > accesses, function entry/exit,
On Thu, Feb 28, 2019 at 05:03:09PM +0100, Dmitry Vyukov wrote:
> I am missing some knowledge about SMAP to answer this.
> In short, these tools insert lots of callbacks into runtime for memory
> accesses, function entry/exit, atomicops and some other. These
> callbacks can do things of different
On Thu, Feb 28, 2019 at 4:46 PM Peter Zijlstra wrote:
>
> On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
> > On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
> > >
> > > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
> > > UACCESS context, and
On 2/28/19 6:52 PM, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 4:46 PM Peter Zijlstra wrote:
>>
>> On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
>>> On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get
On Thu, Feb 28, 2019 at 4:46 PM Peter Zijlstra wrote:
>
> On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
> > On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
> > >
> > > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
> > > UACCESS context, and
On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
> >
> > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
> > UACCESS context, and kasan_report() is most definitely _NOT_ safe to
> > be called from there,
On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote:
>
> Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
> UACCESS context, and kasan_report() is most definitely _NOT_ safe to
> be called from there, move it into an exception much like BUG/WARN.
>
> *compile tested only*
Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from
UACCESS context, and kasan_report() is most definitely _NOT_ safe to
be called from there, move it into an exception much like BUG/WARN.
*compile tested only*
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Signed-off-by: Peter Zijlstra
26 matches
Mail list logo
