On 11/30/2017 04:24 PM, Kirill Tkhai wrote: > On 30.11.2017 15:06, Andrey Ryabinin wrote: >> Tcache code filled with BUG_ON() checks. However the most cases >> issues that BUG_ON() supposed to catch are not serious enough >> to kill machine. So relax it's to WARN_ON. >> Remove BUG_ON() in tcache_init_fs(), because it's useless. >> It's called from the only one place in the kernel, which looks >> like this: >> pool_id = cleancache_ops->init_fs(PAGE_SIZE); >> >> https://jira.sw.ru/browse/PSBM-77154 >> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> >> --- >> mm/tcache.c | 15 ++++++++------- >> 1 file changed, 8 insertions(+), 7 deletions(-) >> >> diff --git a/mm/tcache.c b/mm/tcache.c >> index b5157d9861d0..99c799a9d290 100644 >> --- a/mm/tcache.c >> +++ b/mm/tcache.c >> @@ -473,7 +473,7 @@ static void tcache_destroy_pool(int id) >> for (i = 0; i < num_node_trees; i++) >> tcache_invalidate_node_tree(&pool->node_tree[i]); >> >> - BUG_ON(atomic_long_read(&pool->nr_nodes) != 0); >> + WARN_ON(atomic_long_read(&pool->nr_nodes) != 0); > > Patch looks good for me. One small question about above. Shouldn't we abort > pool destroy in case of this WARN_ON() fires like you did for node below?
Yeah, it's better to leak few bytes rather than cause potential use-after-free. > Also, if so it seems it would be useful to know the exact count of > pool->nr_nodes: > either there is overcount or undercount... > Ok. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
