On 21/11/24 12:00, Peter Zijlstra wrote: > On Wed, Nov 20, 2024 at 08:55:15AM -0800, Josh Poimboeuf wrote: >> On Wed, Nov 20, 2024 at 03:57:46PM +0100, Peter Zijlstra wrote: >> > On Wed, Nov 20, 2024 at 03:56:49PM +0100, Peter Zijlstra wrote: >> > >> > > But I think we can make the fall-back safer, we can simply force the IPI >> > > when we poke at noinstr code -- then NOHZ_FULL gets to keep the pieces, >> > > but at least we don't violate any correctness constraints. >> > >> > I should have read more; that's what is being proposed. >> >> Hm, now I'm wondering what you read, as I only see the text poke IPIs >> being forced when the caller sets force_ipi, rather than the text poke >> code itself detecting a write to .noinstr. > > Right, so I had much confusion and my initial thought was that it would > do something dangerous. Then upon reading more I see it forces the IPI > for these special keys -- with that force_ipi thing. > > Now, there's only two keys marked special, and both have a noinstr > presence -- the entire reason they get marked. > > So effectively we force the IPI when patching noinstr, no? > > But yeah, this is not quite the same as not marking anything and simply > forcing the IPI when the target address is noinstr. > > And having written all that; perhaps that is the better solution, it > sticks the logic in text_poke and ensure it automagically work for all > its users, obviating the need for special marking. > Okay so forcing the IPI for .noinstr patching lets us get rid of all the force_ipi faff; however I would still want the special marking to tell objtool "yep we're okay with this one", and still get warnings when a new .noinstr key gets added so we double think about it.
