Hello, when testing recent DAX fixes, I was puzzled by shadow_lru_isolate() barfing on radix tree nodes attached to DAX mappings (as DAX mappings have no shadow entries and I took care to not insert radix tree nodes for such mappings into workingset_shadow_nodes LRU list. After some investigation, I think there is a use after free issue in the handling of radix tree nodes by workingset code. The following seems to be possible: Radix tree node is created, is has two page pointers for indices 0 and 1. Page pointer for index 0 gets replaced with a shadow entry, radix tree node gets inserted into workingset_shadow_nodes Truncate happens removing page at index 1, __radix_tree_delete_node() in page_cache_tree_delete() frees the radix tree node (as it has only single entry at index 0 and thus we can shrink the tree) while it is still in LRU list! Am I missing something? I'm not sure how to best fix this issue since the shrinking / expanding of the radix tree is fully under control of lib/radix-tree.c which is completely agnostic to the private_list used by mm/workingset.c... Maybe we'd need some callback when radix tree node gets freed? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>