linux-kernel - Re: Clarification on last_comp_len logic in zram_write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <zod7krcdvew5ntmcpbpgzpan2yph6jz7tfao2xowh7c2wmbckm@vc3bsf4fsoyf>
Date: Fri, 13 Dec 2024 17:00:20 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@...il.com>
Cc: minchan@...nel.org, senozhatsky@...omium.org, axboe@...nel.dk, 
	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: Clarification on last_comp_len logic in zram_write_page

On (24/12/13 12:49), Dheeraj Reddy Jonnalagadda wrote:
> I am writing to seek clarification regarding the use of last_comp_len
> variable in zram_write_page function. Specifically, Coverity has flagged 
> the issue (CID 1602439) in zram/zram_drv.c
> 
> Currently, last_comp_len is initialized to 0 but never updated within the
> function. This renders the conditional block shown below as dead code.
> 
> 	if (last_comp_len && (last_comp_len != comp_len)) {
>     		zs_free(zram->mem_pool, handle);
>     		handle = -ENOMEM;
> 	}

That's a "known issue" [1], I deleted one extra line during rebase.
However, I expect last_comp_len patch do get withdrawn soon [2].

[1] https://lore.kernel.org/linux-kernel/20241211100638.GA2228457@google.com
[2] https://lore.kernel.org/mm-commits/3awo2svbnsv2mvozhaqspwztgxhifphj7ffpmykc35py6wp6ol@xlt2q5qgv6c3