On Wed, Oct 18, 2023 at 08:22:23PM +0200, Borislav Petkov wrote: > On Wed, Oct 18, 2023 at 11:14:31AM -0700, Josh Poimboeuf wrote: > > > > > WARN_ONCE() is not enough considering that if this fires, it means we're > > > > > not really properly protected against one of those RET-speculation > > > > > things. > > > > > > > > > > It needs to be warning constantly but then still allow booting. I.e, > > > > > a ratelimited warn of sorts but I don't think we have that... yet. > > > ^ > -----| this here. > > > > > > I'm not sure a rate-limited WARN() would be a good thing. Either the > > > > user is regularly checking dmesg (most likely in some automated fashion) > > > > or they're not. If the latter, a rate-limited WARN() would wrap dmesg > > > > pretty quickly. > > > > > > Well, freezing the box without any mention about why it happens is not > > > viable either. So for lack of a better solution, overflowing dmesg is > > > all we could do. > > > > Why not just WARN_ONCE() then? > > See above....^ And see my reply to that? Not trying to be daft, I just didn't see how your reply was responsive. A single WARN_ONCE() has the benefit of not overflowing dmesg, while also making the warning available to those looking at dmesg (or the taint flag), as those who care should be. A rate-limited WARN() is problematic, as it overflows dmesg (and possibly wrapping other logs), potentially obscuring other important data. > > Ok. A revert is fine for now, but either way we do need to get to the > > bottom of why objtool is messing up. Can you share the config? > > Attached. > > And as said, you need gcc 13. Thanks, I'll see if I can recreate. -- Josh
|