Messages in this thread | | | Subject | Re: [PATCH] ARC: uaccess: get_user to zero out dest in cause of fault | From | "H. Peter Anvin" <> | Date | Sat, 20 Aug 2016 18:09:15 -0700 |
| |
On August 20, 2016 6:00:17 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote: >On Sat, Aug 20, 2016 at 5:45 PM, Linus Torvalds ><torvalds@linux-foundation.org> 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" - it _used_ to be purely a library thing >> back in the days of stupid compilers, but no more). > >Hmm. I may just be full of sh*t. > >I was pretty sure that there used to be a "setjmp" attribute that gcc >used to make sure that "setjmp()" really could return twice, without >bad things happening on the stack. > >But looking at the normal user space headers, I see nothing like that. >It's just > > extern int setjmp (jmp_buf __env) __THROWNL; > >where __THROWNL just sets the __nothrow__ attribute, which shouldn't >even matter in the kernel since we use -fno-exceptions. > >So my "setjmp does potentially bad things to the optimization of the >function calling it" seems to have been just some drug-induced fever >dream of mine. > >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. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
| |