btrfs: fix the memory leak caused in lzo_compress_pages()
[BUG] Fstests generic/027 is pretty easy to trigger a slow but steady memory leak if run with "-o compress=lzo" mount option. Normally one single run of generic/027 is enough to eat up at least 4G ram. [CAUSE] In commitd4088803f5
("btrfs: subpage: make lzo_compress_pages() compatible") we changed how @page_in is released. But that refactoring makes @page_in only released after all pages being compressed. This leaves error path not releasing @page_in. And by "error path" things like incompressible data will also be treated as an error (-E2BIG). Thus it can cause a memory leak if even nothing wrong happened. [FIX] Add check under @out label to release @page_in when needed, so when we hit any error, the input page is properly released. Reported-by: Josef Bacik <josef@toxicpanda.com> Fixes:d4088803f5
("btrfs: subpage: make lzo_compress_pages() compatible") Reviewed-and-tested-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
Родитель
6c405b2409
Коммит
daf87e9535
|
@ -276,6 +276,8 @@ int lzo_compress_pages(struct list_head *ws, struct address_space *mapping,
|
|||
*total_out = cur_out;
|
||||
*total_in = cur_in - start;
|
||||
out:
|
||||
if (page_in)
|
||||
put_page(page_in);
|
||||
*out_pages = DIV_ROUND_UP(cur_out, PAGE_SIZE);
|
||||
return ret;
|
||||
}
|
||||
|
|
Загрузка…
Ссылка в новой задаче