(sorry for the delay responding, took a week off last week; spent a lot of it thinking about this case though) On Tue, Jan 18, 2022 at 3:01 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Tue, Jan 18, 2022 at 11:22:59AM -0800, Josh Poimboeuf wrote: > > On Sun, Jan 16, 2022 at 02:32:59PM +0100, Borislav Petkov wrote: > > > so I like the local label and how it is more readable this way. > > > > > > So, provided the memory clobber works (I wonder here if Josh has some > > > concrete failing cases which could be tested with your version) and > > > after the nitpicks have been addressed > > > > > > Acked-by: Borislav Petkov <bp@xxxxxxx> > > > > I think Nick was already able to recreate the original issue. I'll run > > it through some more testing. > > > > I wanted to make this change years ago, but couldn't because of legacy > > toolchains. Here's hoping this is the final solution for those @#$%^ > > macros. > > > > Boris, thanks for looping Nick in, I should have done so to begin with. No worries, we'll get all this sorted. There's also linux-toolchains@xxxxxxxxxxxxxxx that can help with spooky toolchain behavior. I suspect this is what's causing a flood of objtool warnings when we specify different instruction schedules via -march= (such as via CONFIG_MATOM), which are hiding some of the actual codegen bugs objtool has found in LLVM that we still need to fix. I was looking at the HAVE_ARCH_BUG implementation in arch/x86/include/asm/bug.h 2 weeks ago, and got the sinking feeling that we'll probably need labels in C code, then asm goto to ensure that control flow doesn't get folded in an unexpected way and which I'd imagine might help avoid the costs of a full compiler barrier (i.e. reloading all pointed-to values across it). I'll follow up more with Josh on IRC on some ideas for different approaches. Having 0day bot test Josh's branches is very much appreciated. > Apparently this patch isn't going to work after all :-( > > https://lkml.kernel.org/r/202201190632.lhlaiCBk-lkp@xxxxxxxxx I noticed in that report and https://lore.kernel.org/lkml/202201190702.XNSXrMTK-lkp@xxxxxxxxx/ that gcc-9 was used. I wonder if %= has been fixed in gcc-10+? Have there been other reports with gcc-10+ for my patch? Boris' case of xfrm_output_resume is yet a third case; Boris, what version of gcc did you spot that with? If this is fixed in gcc-10, then we can probably add a comment with a FIXME link to the issue or commit to replace __COUNTER__ with %= one day. If not, then we can probably come up with a reduced test case for the GCC devs to take a look at, then add the FIXME comment to kernel sources. I'm more confident that we can remove the `volatile` keyword (I was thinking about adding a new diagnostic to clang to warn that volatile is redundate+implied for asm goto or inline asm that doesn't have outputs) though that's not the problem here and will probably generate some kernel wide cleanup before we could enable such a flag. Perhaps there are known compiler versions that still require the keyword for those cases for some reason. > > With the two WARN_ONs in media_request_object_complete(), GCC apparently > considers the two reachable() asm statements as duplicates, and it > removes the second one. On Fri, Jan 14, 2022 at 1:58 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote: > > Perhaps it is worth mentioning in the next paragraph that this does not > contradict GCC's own documentation that you link to below, which > mentions that asm volatile statements can be reordered. > > "Note that the compiler can move even volatile asm instructions relative > to other code, including across jump instructions." On Sun, Jan 16, 2022 at 5:33 AM Borislav Petkov <bp@xxxxxxxxx> wrote: > > Yah, Nathan's note about talking about gcc reordering volatile inline > asms might make sense here as, apparently, that could have failed on gcc > too but it didn't for whatever reason and the most important thing is > that the memory clobber will prevent such reordering. Very much YES to both points. Will include those in the commit message for whatever we come up with for the final solution. -- Thanks, ~Nick Desaulniers
