On 2022/1/24 19:55, Marco Elver wrote: > On Mon, 24 Jan 2022 at 12:45, Marco Elver wrote: >> [ FYI, your reply was not plain text, so LKML may have rejected it. I >> advise that you switch your email client for LKML emails to plain >> text. ] >> >> On Mon, 24 Jan 2022 at 12:24, liupeng (DM) wrote: >> [...] >>>> I think the only reasonable way forward is if you add immediate patching >>>> support to the kernel as the "Note" suggests. >>> May you give us more details about "immediate patching"? >> [...] >>> Thank you for your patient suggestions, it's actually helpful and inspired. >>> We have integrated your latest work "skipping already covered allocations", >>> and will do more experiments about KFENCE. Finally, we really hope you can >>> give us more introductions about "immediate patching". >> "Immediate patching" would, similar to "static branches" or >> "alternatives" be based on code hot patching. >> >> https://www.kernel.org/doc/html/latest/staging/static-keys.html >> >> "Patching immediates" would essentially patch the immediate operands >> of certain (limited) instructions. I think designing this properly to >> work across various architectures (like static_keys/jump_label) is >> very complex. So it may not be a viable near-term option. >> >> What Dmitry suggests using a constant virtual address carveout is more >> realistic. But this means having to discuss with arch maintainers >> which virtual address ranges can be reserved. The nice thing about >> just relying on memblock and nothing else is that it is very portable >> and simple. You can have a look at how KASAN deals with organizing its >> shadow memory if you are interested. > Hmm, there may be more issues lurking here: > > https://lore.kernel.org/all/20200929140226.GB53442@C02TD0UTHF1T.local/ > https://lore.kernel.org/all/20200929142411.GC53442@C02TD0UTHF1T.local/ > > ... and I'm guessing if we assign a fixed virtual address range it'll > live outside the linear mapping, which is likely to break certain > requirements of kmalloc()'d allocations in certain situations (a > problem we had with v1 of KFENCE on arm64). > > So I don't even know if that's feasible. :-/ > > Thanks, > -- Marco > . Thank you very much, we will try the suggestions you give. Thanks, -- Peng Liu .