Hello, Shrinker API does not handle nicely unregister_shrinker() on a not-registered ->shrinker. Looking at shrinker users, they all have to (a) carry on some sort of a flag to make sure that "unregister_shrinker()" will not blow up later (b) be fishy (potentially can Oops) (c) access private members `struct shrinker' (e.g. `shrink.list.next') Change unregister_shrinker() to consider all-zeroes shrinker as 'initialized, but not registered' shrinker, so we can avoid NULL dereference when unregister_shrinker() accidentally receives such a struct. Introduce init_shrinker() function to init `critical' shrinkers members when the entire shrinker cannot be, for some reason, zeroed out. This also helps to avoid Oops in unregister_shrinker() in some cases (when unregister_shrinker() receives not initialized and not registered shrinker). Sergey Senozhatsky (2): mm/shrinker: do not NULL dereference uninitialized shrinker mm/shrinker: add init_shrinker() function include/linux/shrinker.h | 1 + mm/vmscan.c | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+) -- 2.4.5 -- 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>