[Devel] [PATCH rh7] mm/tcache: replace BUG_ON()s with WARN_ON()s

[Andrey Ryabinin]

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 <aryabinin at 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.