On Fri, May 20, 2022 at 3:01 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > So this change, effectively, makes the tag in page->flags for GFP_USER > > pages to be reset at allocation time. And the current approach of > > resetting the tag when the kernel is about to access these pages is > > not good because: 1. it's inconvenient to track all places where this > > should be done and 2. the tag reset can race with page_to_virt() even > > with patch #1 applied. Is my understanding correct? > > Yes. Regarding (1), it's pretty impractical. There are some clear places > like copy_user_highpage() where we could untag the page address. In > others others it may not be as simple. We could try to reset the page > flags when we do a get_user_pages() to cover another class. But we still > have swap, page migration that may read a page with a mismatched tag. I see. > > This will reset the tags for all kinds of GFP_USER allocations, not > > only for the ones intended for MAP_ANONYMOUS and RAM-based file > > mappings, for which userspace can set tags, right? This will thus > > weaken in-kernel MTE for pages whose tags can't even be set by > > userspace. Is there a way to deal with this? > > That's correct, it will weaken some of the allocations where the user > doesn't care about MTE. Well, while this is unfortunate, I don't mind the change. I've left some comments on the patches. > > > Since clearing the flags in the arch code doesn't work, try to do this > > > at page allocation time by a new flag added to GFP_USER. Does this have to be GFP_USER? Can we add new flags to GFP_HIGHUSER_MOVABLE instead? For instance, Peter added __GFP_SKIP_KASAN_POISON to GFP_HIGHUSER_MOVABLE in c275c5c6d50a0. > > > Could we > > > instead add __GFP_SKIP_KASAN_UNPOISON rather than a new flag? Adding __GFP_SKIP_KASAN_UNPOISON makes sense, but we still need to reset the tag in page->flags. Thanks!
