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] [day] [month] [year] [list]
Date:   Wed, 27 May 2020 08:40:12 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Zhang Qiang <qiang.zhang@...driver.com>, Tejun Heo <tj@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>
Cc:     linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v4] workqueue: Remove unnecessary kfree() call in
 rcu_free_wq()

> The callback function "rcu_free_wq" could be called after memory
> was released for "wq->rescuer" already and assignment is empty. so
> remove unnecessary kfree(NULL).

I have got the impression that also this wording approach contains weaknesses.
How do you think about a wording variant like the following?

   The data structure member “wq->rescuer” was reset to a null pointer
   in one if branch. It was passed to a call of the function “kfree”
   in the callback function “rcu_free_wq” (which was eventually executed).
   The function “kfree” does not perform more meaningful data processing
   for a passed null pointer (besides immediately returning from such a call).
   Thus delete this function call which became unnecessary with the referenced
   software update.


> Fixes: def98c84b6cd ("workqueue: Fix spurious sanity check failures in destroy_workqueue()")

This change triggered another collateral evolution finally.
Would you like to detect similarly questionable function calls
by advanced source code analysis?


> Fixes: 8efe1223d73c ("workqueue: Fix missing kfree(rescuer) in destroy_workqueue()")

Please delete this tag from the change description
(because I find that it is not so relevant here.)


>  v1->v2->v3->v4:
>  Modify wrong submission information.

Will it be nicer to mention the adjustment of the commit message?

Regards,
Markus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ