On Mon, 12 Nov 2018, Masami Hiramatsu wrote:
> > text_mutex is currently expected to be held before text_poke() is
> > called, but we kgdb does not take the mutex, and instead *supposedly*
> > ensures the lock is not taken and will not be acquired by any other
> > core while text_poke() is
On Mon, 12 Nov 2018, Masami Hiramatsu wrote:
> > text_mutex is currently expected to be held before text_poke() is
> > called, but we kgdb does not take the mutex, and instead *supposedly*
> > ensures the lock is not taken and will not be acquired by any other
> > core while text_poke() is
On Sat, 10 Nov 2018 15:17:23 -0800
Nadav Amit wrote:
> text_mutex is currently expected to be held before text_poke() is
> called, but we kgdb does not take the mutex, and instead *supposedly*
> ensures the lock is not taken and will not be acquired by any other core
> while text_poke() is
On Sat, 10 Nov 2018 15:17:23 -0800
Nadav Amit wrote:
> text_mutex is currently expected to be held before text_poke() is
> called, but we kgdb does not take the mutex, and instead *supposedly*
> ensures the lock is not taken and will not be acquired by any other core
> while text_poke() is
text_mutex is currently expected to be held before text_poke() is
called, but we kgdb does not take the mutex, 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
text_mutex is currently expected to be held before text_poke() is
called, but we kgdb does not take the mutex, 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
6 matches
Mail list logo
