On 2021-11-01 2:09 p.m., Helge Deller wrote:
On 11/1/21 01:06, John David Anglin wrote:
On 2021-10-31 8:01 p.m., John David Anglin wrote:
On 2021-10-31 7:56 p.m., John David Anglin wrote:
n 2021-10-31 7:07 p.m., Helge Deller wrote:
On 10/31/21 23:47, John David Anglin wrote:
My sense is the invalidate patch isn't correct. The main difference between pdc and fdc is that
it is optional whether pdc writes the cache line back to memory when it's dirty at priority 0.
That's true, nevertheless I've seen different behaviour on real hardware.
It might be, that:
- flush_kernel_vmap_range((void *)fixmap, (p-fixmap) * sizeof(*p));
+ invalidate_kernel_vmap_range((void *)fixmap, (p-fixmap) * sizeof(*p));
(here the flush might be sufficient)
if (mapped)
patch_unmap(FIX_TEXT_POKE0, &flags);
+ invalidate_kernel_vmap_range((void *)start, end - start);
(but here the pdc is necessary to actually drop data from I-cache)
flush_icache_range(start, end);
I can test tomorrow...
Maybe sync is needed before releasing lock. pdc/fdc are weakly ordered.
Forget that. There already is a sync.
Could it be we incorrectly change the flush/purge operations to nops?
89: ALTERNATIVE(88b, 89b, ALT_COND_NO_DCACHE, INSN_NOP)
No, can't be.
The alternative patching hasn't run yet when the kprobe testcases run.
I was concerned about the flush vs. purge write back behavior, not the kprobe problem.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
