On Thu, Feb 28, 2019 at 11:05:10AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 10:59 AM Dmitry Vyukov wrote:
> > I guess this warning originated for user-space where programmer does
> > not define them and does not generally know about them and signature
> > is not a public contract
On Thu, Feb 28, 2019 at 10:59 AM Dmitry Vyukov wrote:
>
> On Thu, Feb 28, 2019 at 10:40 AM Peter Zijlstra wrote:
> >
> > On Wed, Feb 27, 2019 at 06:28:16PM +0100, Peter Zijlstra wrote:
> > > On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> > > > On Wed, Feb 27, 2019 at 3:33 PM
On Thu, Feb 28, 2019 at 10:40 AM Peter Zijlstra wrote:
>
> On Wed, Feb 27, 2019 at 06:28:16PM +0100, Peter Zijlstra wrote:
> > On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> > > On Wed, Feb 27, 2019 at 3:33 PM Peter Zijlstra
> > > wrote:
> >
> > > > Urgh, kasan_report() is
On Wed, Feb 27, 2019 at 06:28:16PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> > On Wed, Feb 27, 2019 at 3:33 PM Peter Zijlstra wrote:
>
> > > Urgh, kasan_report() is definitely unsafe. Now, admitedly we should
> > > 'never' hit that, but it
On Wed, Feb 27, 2019 at 9:30 AM Peter Zijlstra wrote:
>
> Right, but I was hoping to avoid having to do that; and I think we can
> do that if we push all of kasan_report into an exception, like that
> 'patch' I just posted.
>
> If I'm not mistaken the regular kasan house-keeping crud just prods
On Wed, Feb 27, 2019 at 08:18:21AM -0800, Linus Torvalds wrote:
> So the whole "run with AC on" thing isn't a big deal, apart from the
> scheduling case.
>
> And we know how to fix the scheduling case by just doing the
> save/restore thing..
Right, but I was hoping to avoid having to do that;
On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> On Wed, Feb 27, 2019 at 3:33 PM Peter Zijlstra wrote:
> > Urgh, kasan_report() is definitely unsafe. Now, admitedly we should
> > 'never' hit that, but it does leave us up a creek without a paddle.
> If SMAP detects additional
On Wed, Feb 27, 2019 at 6:08 AM Peter Zijlstra wrote:
>
> So KASAN is wildly unhappy..
Yeah, well, with KASAN you definitely end up doing lots and lots for
calls for just regular memory accesses.
Which we obviously need to do for most uaccess cases.
I think you should just say "ok, kasan
On Wed, Feb 27, 2019 at 3:33 PM Peter Zijlstra wrote:
>
> On Wed, Feb 27, 2019 at 03:26:23PM +0100, Peter Zijlstra wrote:
> > On Wed, Feb 27, 2019 at 05:17:58PM +0300, Andrey Ryabinin wrote:
> > >
> > >
> > > On 2/27/19 5:08 PM, Peter Zijlstra wrote:
> >
> > > > I can't actually find any
On Wed, Feb 27, 2019 at 03:26:23PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 27, 2019 at 05:17:58PM +0300, Andrey Ryabinin wrote:
> >
> >
> > On 2/27/19 5:08 PM, Peter Zijlstra wrote:
>
> > > I can't actually find any definitions of those functions, so I can't
> > > very well mark the safe,
On Wed, Feb 27, 2019 at 05:17:58PM +0300, Andrey Ryabinin wrote:
>
>
> On 2/27/19 5:08 PM, Peter Zijlstra wrote:
> > I can't actually find any definitions of those functions, so I can't
> > very well mark the safe, even if we wanted to.
> >
>
> They are macro-generated. Use 'git grep
On 2/27/19 5:08 PM, Peter Zijlstra wrote:
> On Mon, Feb 25, 2019 at 01:43:35PM +0100, Peter Zijlstra wrote:
>> It is important that UACCESS regions are as small as possible;
>> furthermore the UACCESS state is not scheduled, so doing anything that
>> might directly call into the scheduler will
On Mon, Feb 25, 2019 at 01:43:35PM +0100, Peter Zijlstra wrote:
> It is important that UACCESS regions are as small as possible;
> furthermore the UACCESS state is not scheduled, so doing anything that
> might directly call into the scheduler will cause random code to be
> ran with UACCESS
On Mon, Feb 25, 2019 at 06:15:31PM +0100, Peter Zijlstra wrote:
> Also, I think at the time we didn't use it because backporting efforts.
This part may have been my fault. I spread a vicious rumor (based on
reading docs instead of code) that old versions of GCC don't support
'%='. But it's
On Mon, Feb 25, 2019 at 9:15 AM Peter Zijlstra wrote:
>
> Ah, so the thing we need for inline-asm is %=, but Linus didn't like it:
Well, to be fair, I also didn't like the random big numbers.
I think that inline asm that has local labels should just use simple
enumeration, and always use the
On Mon, Feb 25, 2019 at 05:12:34PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 25, 2019 at 07:53:01AM -0800, Andy Lutomirski wrote:
> > On Mon, Feb 25, 2019 at 4:53 AM Peter Zijlstra wrote:
>
> > > +#define UACCESS_SAFE(func) \
> > > + asm
On Mon, Feb 25, 2019 at 07:53:01AM -0800, Andy Lutomirski wrote:
> On Mon, Feb 25, 2019 at 4:53 AM Peter Zijlstra wrote:
> > +#define UACCESS_SAFE(func) \
> > + asm (".pushsection .discard.uaccess_safe_strtab, \"S\", @3\n\t" \
> > +
On Mon, Feb 25, 2019 at 4:53 AM Peter Zijlstra wrote:
>
> It is important that UACCESS regions are as small as possible;
> furthermore the UACCESS state is not scheduled, so doing anything that
> might directly call into the scheduler will cause random code to be
> ran with UACCESS enabled.
>
>
It is important that UACCESS regions are as small as possible;
furthermore the UACCESS state is not scheduled, so doing anything that
might directly call into the scheduler will cause random code to be
ran with UACCESS enabled.
Teach objtool too track UACCESS state and warn about any CALL made
19 matches
Mail list logo
