linux-kernel - Re: [PATCH 2/5] debugobjects: Remove redundant checks in fill

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87plpl8422.ffs@tglx>
Date: Tue, 03 Sep 2024 11:44:21 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Zhen Lei <thunder.leizhen@...wei.com>, Andrew Morton
 <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org
Cc: Zhen Lei <thunder.leizhen@...wei.com>
Subject: Re: [PATCH 2/5] debugobjects: Remove redundant checks in fill_pool()

On Mon, Sep 02 2024 at 22:05, Zhen Lei wrote:
> The conditions for the inner and outer loops are exactly the same, so the
> outer 'while' should be changed to 'if'. Then we'll see that the
> second

We'll see nothing. Please write change logs in passive voice and do not
try to impersonate code.

> condition of the new 'if' is already guaranteed above and can be
> removed.

Yes, the conditions are the same. But a 'if' is not the same as a 'while'.

So you need to explain why the outer loop is not required and why it
does not make a difference in terms of functionality.

> @@ -142,8 +142,7 @@ static void fill_pool(void)
>  	 * READ_ONCE()s pair with the WRITE_ONCE()s in pool_lock critical
>  	 * sections.
>  	 */

The comment does not make sense anymore. Please fixup comments when
changing the code. It's a pain to read a comment and then see that the
code does something different.

> -	while (READ_ONCE(obj_nr_tofree) &&
> -	       READ_ONCE(obj_pool_free) < debug_objects_pool_min_level) {
> +	if (READ_ONCE(obj_nr_tofree)) {
>  		raw_spin_lock_irqsave(&pool_lock, flags);
>  		/*
>  		 * Recheck with the lock held as the worker thread might have

Thanks,

        tglx