[RT,20/25] kmemleak: Cosmetic changes
diff mbox series

Message ID c3cf47877f79afa92634bf376488c8aa71378a26.1582320278.git.zanussi@kernel.org
State New
Headers show
Series
  • Linux v4.14.170-rt75-rc1
Related show

Commit Message

Tom Zanussi Feb. 21, 2020, 9:24 p.m. UTC
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

v4.14.170-rt75-rc1 stable review patch.
If anyone has any objections, please let me know.

-----------


[ Upstream commit 65a387a0b45cdd6844b7c6269e6333c9f0113410 ]

Align with the patch, that got sent upstream for review. Only cosmetic
changes.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Tom Zanussi <zanussi@kernel.org>
---
 mm/kmemleak.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

Comments

Sebastian Andrzej Siewior Feb. 24, 2020, 9:12 a.m. UTC | #1
On 2020-02-21 15:24:48 [-0600], zanussi@kernel.org wrote:
> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> 
> v4.14.170-rt75-rc1 stable review patch.
> If anyone has any objections, please let me know.

This makes no sense to apply it. I updated my patch in the RT queue to
what has been sent (and later merged) upstream. Then I was forced to
sync the non-rebase branch with the rebase branch. This is the result.

What should be applied instead is
	fb2c57edcb943 ("kmemleak: Change the lock of kmemleak_object to raw_spinlock_t")

from the v4.19-RT branch.

Sebastian
Tom Zanussi Feb. 24, 2020, 3:18 p.m. UTC | #2
On Mon, 2020-02-24 at 10:12 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-02-21 15:24:48 [-0600], zanussi@kernel.org wrote:
> > From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > 
> > v4.14.170-rt75-rc1 stable review patch.
> > If anyone has any objections, please let me know.
> 
> This makes no sense to apply it. I updated my patch in the RT queue
> to
> what has been sent (and later merged) upstream. Then I was forced to
> sync the non-rebase branch with the rebase branch. This is the
> result.
> 
> What should be applied instead is
> 	fb2c57edcb943 ("kmemleak: Change the lock of kmemleak_object to
> raw_spinlock_t")
> 

I did apply that patch (as patch 14/25 of this series).  This patch
seemed like it was adding some comment bits mised for that one, which
is all it does.

Thanks,

Tom

> from the v4.19-RT branch.
> 
> Sebastian
Sebastian Andrzej Siewior Feb. 24, 2020, 3:52 p.m. UTC | #3
On 2020-02-24 09:18:23 [-0600], Tom Zanussi wrote:
> > What should be applied instead is
> > 	fb2c57edcb943 ("kmemleak: Change the lock of kmemleak_object to
> > raw_spinlock_t")
> > 
> 
> I did apply that patch (as patch 14/25 of this series).  This patch
> seemed like it was adding some comment bits mised for that one, which
> is all it does.

Bah. So I saw that (#14/25), considered okay but while looking at this
patch I was comparing against v4.14.164-rt73 and forgot about it…

> Thanks,
> 
> Tom

Sebastian.

Patch
diff mbox series

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 17718a11782b..d7925ee4b052 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -26,7 +26,7 @@ 
  *
  * The following locks and mutexes are used by kmemleak:
  *
- * - kmemleak_lock (raw spinlock): protects the object_list modifications and
+ * - kmemleak_lock (raw_spinlock_t): protects the object_list modifications and
  *   accesses to the object_tree_root. The object_list is the main list
  *   holding the metadata (struct kmemleak_object) for the allocated memory
  *   blocks. The object_tree_root is a red black tree used to look-up
@@ -35,13 +35,13 @@ 
  *   object_tree_root in the create_object() function called from the
  *   kmemleak_alloc() callback and removed in delete_object() called from the
  *   kmemleak_free() callback
- * - kmemleak_object.lock (spinlock): protects a kmemleak_object. Accesses to
- *   the metadata (e.g. count) are protected by this lock. Note that some
- *   members of this structure may be protected by other means (atomic or
- *   kmemleak_lock). This lock is also held when scanning the corresponding
- *   memory block to avoid the kernel freeing it via the kmemleak_free()
- *   callback. This is less heavyweight than holding a global lock like
- *   kmemleak_lock during scanning
+ * - kmemleak_object.lock (raw_spinlock_t): protects a kmemleak_object.
+ *   Accesses to the metadata (e.g. count) are protected by this lock. Note
+ *   that some members of this structure may be protected by other means
+ *   (atomic or kmemleak_lock). This lock is also held when scanning the
+ *   corresponding memory block to avoid the kernel freeing it via the
+ *   kmemleak_free() callback. This is less heavyweight than holding a global
+ *   lock like kmemleak_lock during scanning.
  * - scan_mutex (mutex): ensures that only one thread may scan the memory for
  *   unreferenced objects at a time. The gray_list contains the objects which
  *   are already referenced or marked as false positives and need to be
@@ -197,7 +197,7 @@  static LIST_HEAD(object_list);
 static LIST_HEAD(gray_list);
 /* search tree for object boundaries */
 static struct rb_root object_tree_root = RB_ROOT;
-/* rw_lock protecting the access to object_list and object_tree_root */
+/* protecting the access to object_list and object_tree_root */
 static DEFINE_RAW_SPINLOCK(kmemleak_lock);
 
 /* allocation caches for kmemleak internal data */