On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote: >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote: >> > Hi Josh, >> > >> > I recently did some randconfig testing with a plain 4.14-stable kernel >> > and gcc-7.3.0, and came across three distinct objtool warnings: >> > >> > drivers/misc/lkdtm_bugs.o: warning: objtool: >> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame > > While this is probably an objtool bug, the code is very odd: > > 00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>: > 1a8: e8 00 00 00 00 callq 1ad <lkdtm_CORRUPT_LIST_ADD+0x5> > 1a9: R_X86_64_PC32 __fentry__-0x4 > 1ad: 55 push %rbp > 1ae: 48 89 e5 mov %rsp,%rbp > 1b1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp > 1b5: 48 83 ec 20 sub $0x20,%rsp > 1b9: 48 89 ec mov %rbp,%rsp > 1bc: 5d pop %rbp > 1bd: c3 retq > > The function just allocates/aligns its stack space and then returns. It > seems like GCC was too smart for its own good here, as the function > doesn't test what it's supposed to. AFAIU, there is an optimization step in gcc that eliminates basic blocks that contain an unconditional NULL pointer dereference, based on the assumption that it's undefined behavior, and if we ever get here, it is free to drop not only code after but also before it as long as it doesn't have any side-effects. I would have expected an actual NULL pointer dereference to remain in the function though, or at least another trapping instruction. > Can you share the config for this one? https://pastebin.com/qFV6SPWP Arnd