Messages in this thread | | | From | Nadav Amit <> | Subject | Re: [PATCH v2 1/6] Fix "x86/alternatives: Lockdep-enforce text_mutex in text_poke*()" | Date | Thu, 6 Sep 2018 19:58:40 +0000 |
| |
at 12:53 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, Sep 06, 2018 at 07:42:14PM +0000, Nadav Amit wrote: >> at 12:40 PM, Peter Zijlstra <peterz@infradead.org> wrote: >> >>> On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote: >>>> text_mutex is expected to be held before text_poke() is called, but we >>>> cannot add a lockdep assertion since kgdb does not take it, and instead >>>> *supposedly* ensures the lock is not taken and will not be acquired by >>>> any other core while text_poke() is running. >>>> >>>> The reason for the "supposedly" comment is that it is not entirely clear >>>> that this would be the case if gdb_do_roundup is zero. >>> >>> Argh, that's pretty shit code... >>> >>> Not only is that text_mutex abuse ugly, so too is the fixmap usage from >>> IRQ context. I suppose this really does require your alternative mm >>> patches for text_poke(). >> >> Right, I forgot about that… > > With that CR3 trickery, we can rid ourselves of the text_mutex > requirement, since concurrent text_poke is 'safe'. That would clean up > the kgdb code quite a bit.
I don’t know. I’m somewhat worried with multiple mechanisms potentially changing the same code at the same time - and maybe ending up with some mess.
| |