On Mon, Aug 22, 2016 at 04:48:00PM -0700, Linus Torvalds wrote:
> On Mon, Aug 22, 2016 at 4:12 PM, H. Peter Anvin wrote:
> >
> > How about the gcc native __builtin_setjmp stuff which is supposedly better?
>
> How new is it? The whole point was that we'd not have to worry and
> wait for gcc featur
On August 22, 2016 4:57:10 PM PDT, David Miller wrote:
>From: Linus Torvalds
>Date: Mon, 22 Aug 2016 16:48:00 -0700
>
>> How new is it? The whole point was that we'd not have to worry and
>> wait for gcc features..
>
>It's been around for a long time.
>
>I'd say at least gcc-3.0 and later support
From: Linus Torvalds
Date: Mon, 22 Aug 2016 16:48:00 -0700
> How new is it? The whole point was that we'd not have to worry and
> wait for gcc features..
It's been around for a long time.
I'd say at least gcc-3.0 and later support it.
On August 22, 2016 4:48:00 PM PDT, Linus Torvalds
wrote:
>On Mon, Aug 22, 2016 at 4:12 PM, H. Peter Anvin wrote:
>>
>> How about the gcc native __builtin_setjmp stuff which is supposedly
>better?
>
>How new is it? The whole point was that we'd not have to worry and
>wait for gcc features..
>
>gl
On Mon, Aug 22, 2016 at 4:12 PM, H. Peter Anvin wrote:
>
> How about the gcc native __builtin_setjmp stuff which is supposedly better?
How new is it? The whole point was that we'd not have to worry and
wait for gcc features..
glibc doesn't use it, which worries me a bit. Has it ever gotten any
u
On August 22, 2016 3:23:06 PM PDT, Linus Torvalds
wrote:
>On Sun, Aug 21, 2016 at 10:52 AM, Linus Torvalds
> wrote:
>> On Sat, Aug 20, 2016 at 11:42 PM, Al Viro
>wrote:
>>>
>>> It's not exactly setjmp/longjmp; what I had in mind was along the
>lines of
>>
>> That ends up having all the exact sam
On August 22, 2016 3:23:06 PM PDT, Linus Torvalds
wrote:
>On Sun, Aug 21, 2016 at 10:52 AM, Linus Torvalds
> wrote:
>> On Sat, Aug 20, 2016 at 11:42 PM, Al Viro
>wrote:
>>>
>>> It's not exactly setjmp/longjmp; what I had in mind was along the
>lines of
>>
>> That ends up having all the exact sam
On Sun, Aug 21, 2016 at 10:52 AM, Linus Torvalds
wrote:
> On Sat, Aug 20, 2016 at 11:42 PM, Al Viro wrote:
>>
>> It's not exactly setjmp/longjmp; what I had in mind was along the lines of
>
> That ends up having all the exact same issues as setjmp, and generally
> you *do* want the compiler to kn
On Sat, Aug 20, 2016 at 11:42 PM, Al Viro wrote:
>
> It's not exactly setjmp/longjmp; what I had in mind was along the lines of
That ends up having all the exact same issues as setjmp, and generally
you *do* want the compiler to know about it.
For example, let's say that you have something like
On Sun, Aug 21, 2016 at 06:54:02AM +0200, Jakub Jelinek wrote:
> On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:
> If you plan to use setjmp/longjmp a lot, then it is certainly a major
> performance and compile time/memory problem.
> Older versions don't model it properly, and newe
On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:
> You have to save the stack pointer at the setjmp point too. And there
> might be other architecture-specific ABI rules for that. But you're
> right, it might be worth it.
>
> I *would* be a bit worried about code generation issues.
On Sat, Aug 20, 2016 at 06:09:15PM -0700, H. Peter Anvin wrote:
> >Sorry for the bogus noise. I don't know why I was so convinced setjmp
> >needed special gcc semantics.
> >
> > Linus
>
> I think the specific name setjmp() is magic in gcc.
It is; attribute equivalent is returns_twice
On August 20, 2016 6:00:17 PM PDT, Linus Torvalds
wrote:
>On Sat, Aug 20, 2016 at 5:45 PM, Linus Torvalds
> wrote:
>>
>> So I slightly considered it, because gcc actually has support for
>that
>> kind of behavior thanks to setjmp/longjmp (and yes, the compiler
>> actually needs to know about the
On Sat, Aug 20, 2016 at 5:45 PM, Linus Torvalds
wrote:
>
> So I slightly considered it, because gcc actually has support for that
> kind of behavior thanks to setjmp/longjmp (and yes, the compiler
> actually needs to know about the magic "this code can be entered a
> second time from elsewhere" -
On Sat, Aug 20, 2016 at 5:11 PM, Al Viro wrote:
>
> Interesting... BTW, how's this in the "really vile tricks" department?
>
> if (!uaccess_begin())
> goto fail;
So I slightly considered it, because gcc actually has support for that
kind of behavior thanks to setjmp/longj
On Sat, Aug 20, 2016 at 04:32:57PM -0700, Linus Torvalds wrote:
> Anyway, the asm coming out of gcc looks nasty, because it has all the
> ugly section stuiff and fixups for SMAP not existing on some CPU's
> etc. So the resulting fs/readdir.s file is hard to read. But if you
> look at the disassemb
On Fri, Aug 19, 2016 at 3:11 PM, Linus Torvalds
wrote:
>>
>> (I have some experimental patches that actually use "asm goto" in
>> "unsafe_put_user()" to get that nice code generation, but they only
>> work if your gcc version supports "asm goto", which some older
>> versions of gcc does not)
>
> S
On Fri, Aug 19, 2016 at 3:00 PM, Linus Torvalds
wrote:
>
> (I have some experimental patches that actually use "asm goto" in
> "unsafe_put_user()" to get that nice code generation, but they only
> work if your gcc version supports "asm goto", which some older
> versions of gcc does not)
Since you
On Fri, Aug 19, 2016 at 2:24 PM, Al Viro wrote:
> * x86-only get_user_ex(). Does *not* return anything, uses
> per-process
> flag to indicate errors, the entire sequence is bracketed by uaccess_try()
> and uaccess_catch(err), the latter dumps the flag into err.
I really don't want peopl
On Fri, Aug 19, 2016 at 12:10:02PM -0700, Vineet Gupta wrote:
> Al reported potential issue with ARC get_user() as it wasn't clearing
> out destination pointer in case of fault due to bad address etc.
Applied to my branch with other similar fixes. FWIW, there's another
interesting question in the
Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.
Verified using following
| {
| u32 bogus1 = 0xdeadbeef;
| u64 bogus2 = 0xdead;
| int rc1, rc2;
|
| pr_info("Orig values %x %llx\n", bogus1
21 matches
Mail list logo
