[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi7xda+zM=iRGXWbU9i8S7kbNaSfPhXVXR-vK6uEFNx_w@mail.gmail.com>
Date: Fri, 29 May 2020 12:31:04 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Christoph Hellwig <hch@....de>,
Randy Dunlap <rdunlap@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mark Brown <broonie@...nel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Michal Hocko <mhocko@...e.cz>, mm-commits@...r.kernel.org,
Stephen Rothwell <sfr@...b.auug.org.au>,
Al Viro <viro@...iv.linux.org.uk>,
"the arch/x86 maintainers" <x86@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: mmotm 2020-05-13-20-30 uploaded (objtool warnings)
On Fri, May 29, 2020 at 9:50 AM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> From staring at the asm I think the generated code is correct, it's just
> that the nested likelys with ftrace profiling cause GCC to converge the
> error/success paths. But objtool doesn't do register value tracking so
> it's not smart enough to know that it's safe.
I'm surprised that gcc doesn't end up doing the obvious CSE and then
branch following and folding it all away in the end, but your patch is
obviously the right thing to do regardless, so ack on that.
Al - I think this had best go into your uaccess cleanup branch with
that csum-wrapper update, to avoid any unnecessary conflicts or
dependencies.
Linus
Powered by blists - more mailing lists