On Tue, 14 Jul 2020, Josh Poimboeuf wrote:

On Tue, Jul 14, 2020 at 12:56:21PM +0200, Miroslav Benes wrote:

quoted

On Thu, 2 Jul 2020, Josh Poimboeuf wrote:

quoted

On Tue, Jun 23, 2020 at 08:06:07AM -0700, Randy Dunlap wrote:

quoted

On 6/22/20 11:28 PM, Stephen Rothwell wrote:

quoted

Hi all,

Changes since 20200622:

on x86_64:

arch/x86/kernel/cpu/mce/core.o: warning: objtool: mce_timed_out()+0x24: unreachable instruction
kernel/exit.o: warning: objtool: __x64_sys_exit_group()+0x14: unreachable instruction

Full randconfig file is attached.

More livepatch...

Correct.

Both are known and I thought Josh had fixes queued somewhere for both, but 
my memory fails me quite often. See below.

I did have fixes for some of them in a stash somewhere, but I never
finished them because I decided it's a GCC bug.

Same here.
 

quoted

However, I think it is time to decide how to approach this whole saga. It 
seems that there are not so many places in the kernel in need of 
__noreturn annotation in the end and as jikos argued at least some of 
those should be fixed regardless.

I would agree that global functions like do_group_exit() deserve a
__noreturn annotation, though it should be in the header file.  But
static functions shouldn't need it.

Agreed. I'll post the patches for global functions eventually, but see 
below first.

quoted

Josh, should I prepare proper patches and submit them to relevant
maintainers to see where this path is going?

If that's how you want to handle it, ok, but it doesn't seem right to
me, for the static functions at least.

quoted

It would be much better to fix it in GCC, but it has been like banging 
one's head against a wall so far. Josh, you wanted to create a bug 
for GCC in this respect in the past? Has that happened?

I didn't open a bug, but I could, if you think that would help.  I
haven't had a lot of success with GCC bugs in the past.

Understood.

quoted

If I remember correctly, we discussed briefly a possibility to cope with 
that in objtool, but no solution was presented.

That would also feel like a GCC workaround and might impede objtool's
ability to find bugs like this one, and possibly more serious bugs.

quoted

Removing -flive-patching is also a possibility. I don't like it much, but 
we discussed it with Petr M. a couple of months ago and it might be a way 
too.

-flive-patching has many problems which I outlined before.  None of them
have been addressed.  I still feel the same way, that it should be
reverted until it's ready.  Otherwise it's a drain on upstream.

Also, if the GCC developers won't acknowledge this bug then it doesn't
give me confidence in their ability to keep the feature working as
optimizations are added or changed.

I must admit that I've started to share the sentiment recently. And it is 
probably the main reason for changing my mind about the whole thing.

I still think a potential alternative exists: objtool could be used as a
simple tree-wide object diff tool by generating a checksum for each
function.  Then the patch can be applied and built to see exactly which
functions have changed, based on the changed checksums.  In which case
this feature would no longer be needed anyway, would you agree?

Yes.

I also think that could be a first step for converging our patch
creation processes.

Yes again.

Petr, would you agree to revert -flive-patching due to reasons above? Is 
there anything you want to add?

Miroslav