Right, the __label__ declaration should take care of it. Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Mon, Dec 23, 2013 at 4:00 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> >> I guess I'm a bit puzzled... the current code should be just fine if >> everything is present, and do we really care about the performance if >we >> actually have an error condition? > >I think we should. You could make it to do something like eighteen >expensive page faults in a row for EFAULT, and that's just disgusting, >when there is no reason to do it. > >But to be honest, the resulting assembly is also easier to read, >because it doesn't have those annoying bogus branch targets all over >in the middle of the code. That was actually my main issue - looking >at the generated fs/stat.s file and not puking ;) > >(it's still hard to read with all the fixup section stuff, but it's >better. And it really does generate better code, so..) > >> I'm a bit concerned about the put_user_fail: label having uniqueness >> problem, which I know some versions of gcc at least get very noisy >over. > >Oh, you're right, I forgot to actually declare the label so that gcc >sees that it's a local one. > >So it needs a > > __label__ put_user_fail; > >in the put_user_try() (and yes, maybe the label name should have >underscores prepended or something, just to make sure it's internal). > >But gcc is perfectly fine with multiple labels in different scopes if >you do that. We already use that in a few places, so this isn't even a >new pattern for us. > > Linus -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
