On 7/19/2022 12:53 PM, Guilherme G. Piccoli wrote:
Currently we have a debug infrastructure in the notifiers file, but
it's very simple/limited. Extend it by:
(a) Showing all registered/unregistered notifiers' callback names;
I'm not yet convinced that this is the right direction.
The
On 7/19/2022 2:00 PM, Guilherme G. Piccoli wrote:
On 19/07/2022 17:48, Arjan van de Ven wrote:
[...]
I would totally support an approach where instead of pr_info, there's a
tracepoint
for these events (and that shouldnt' need to be conditional on a config option)
that's not what the patch
On 7/19/2022 1:44 PM, Guilherme G. Piccoli wrote:
On 19/07/2022 17:33, Arjan van de Ven wrote:
On 7/19/2022 12:53 PM, Guilherme G. Piccoli wrote:
Currently we have a debug infrastructure in the notifiers file, but
it's very simple/limited. Extend it by:
(a) Showing all registered/unregistered
Does anybody have any other ideas?
the only other weird case that comes to mind; what happens if there's a line
dirty in the caches,
but the memory is now mapped uncached. (Which could happen if kexec does muck
with MTRRs, CR0 or other similar
things in weird ways)... not sure what happens
Does anybody have any other ideas?
wbinvd is thankfully not common, but also not rare (MTRR setup and a bunch of
other cases)
and in some other operating systems it happens even more than on Linux.. it's
generally not totally broken like this.
I can only imagine a machine check case where a
