Andrey Ryabinin [off-list ref] writes:

On 02/20/2015 03:15 AM, Rusty Russell wrote:

quoted

Andrey Ryabinin [off-list ref] writes:

quoted

On 02/19/2015 02:10 AM, Rusty Russell wrote:

quoted

This is not portable.  Other archs don't use vmalloc, or don't use
(or define) MODULES_VADDR.  If you really want to hook here, you'd
need a new flag (or maybe use PAGE_KERNEL_EXEC after an audit).

Well, instead of explicit (addr >= MODULES_VADDR && addr < MODULES_END)
I could hide this into arch-specific function: 'kasan_need_to_allocate_shadow(const void *addr)'
or make make all those functions weak and allow arch code to redefine them.

That adds another layer of indirection.  And how would the caller of
plain vmalloc() even know what to return?

I think I don't understand what do you mean here. vmalloc() callers shouldn't know
anything about kasan/shadow.

How else would kasan_need_to_allocate_shadow(const void *addr) work for
architectures which don't have a reserved vmalloc region for modules?

quoted

Hmm, how about a hybrid:

1) Add kasan_module_alloc(p, size) after module alloc as your original.
2) Hook into vfree(), and ignore it if you can't find the map.

That should work, but it looks messy IMO.

quoted

Or is the latter too expensive?

Not sure whether this will be too expensive or not,
but definitely more expensive than simple (addr >= MODULES_VADDR && addr < MODULES_END) check.

Sure, if that check were portable.  If you ever wanted kasan on other
vmalloc addresses it wouldn't work either.

I actually think this pattern is the *simplest* solution for auxilliary
data like kasan.

Cheers,
Rusty.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>