linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] some improvements for lockdep
@ 2021-06-18 14:55 Xiongwei Song
  2021-06-18 14:55 ` [PATCH v2 1/3] locking/lockdep: Unlikely bfs_error() inside Xiongwei Song
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Xiongwei Song @ 2021-06-18 14:55 UTC (permalink / raw)
  To: peterz, mingo, will, longman, boqun.feng; +Cc: linux-kernel, Xiongwei Song

From: Xiongwei Song <sxwjean@gmail.com>

Unlikely the checks of return values of graph walk will improve the
performance to some degree, patch 1 and patch 2 are for this.

The patch 3 will print a warning after counting lock deps when hitting
bfs errors.

v2:
* For patch 3, avoid to call lockdep_unlock() twice after counting deps.
  Please see https://lkml.org/lkml/2021/6/17/741. 

Xiongwei Song (3):
  locking/lockdep: Unlikely bfs_error() inside
  locking/lockdep: Unlikely conditons about BFS_RMATCH
  locking/lockdep: Print possible warning after counting deps

 kernel/locking/lockdep.c | 55 +++++++++++++++++++---------------------
 1 file changed, 26 insertions(+), 29 deletions(-)

-- 
2.30.2


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH v2 1/3] locking/lockdep: Unlikely bfs_error() inside
  2021-06-18 14:55 [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
@ 2021-06-18 14:55 ` Xiongwei Song
  2021-06-18 14:55 ` [PATCH v2 2/3] locking/lockdep: Unlikely conditons about BFS_RMATCH Xiongwei Song
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Xiongwei Song @ 2021-06-18 14:55 UTC (permalink / raw)
  To: peterz, mingo, will, longman, boqun.feng; +Cc: linux-kernel, Xiongwei Song

From: Xiongwei Song <sxwjean@gmail.com>

The error from graph walk is small probability event, and there are some
bfs_error calls during lockdep detection, so unlikely bfs_error inside
can improve performance a little bit.

Suggested-by: Waiman Long <longman@redhat.com>
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
 kernel/locking/lockdep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 7641bd407239..a8a66a2a9bc1 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1540,7 +1540,7 @@ enum bfs_result {
  */
 static inline bool bfs_error(enum bfs_result res)
 {
-	return res < 0;
+	return unlikely(res < 0);
 }
 
 /*
@@ -2089,7 +2089,7 @@ check_path(struct held_lock *target, struct lock_list *src_entry,
 
 	ret = __bfs_forwards(src_entry, target, match, skip, target_entry);
 
-	if (unlikely(bfs_error(ret)))
+	if (bfs_error(ret))
 		print_bfs_bug(ret);
 
 	return ret;
@@ -2936,7 +2936,7 @@ check_prev_add(struct task_struct *curr, struct held_lock *prev,
 	 * in the graph whose neighbours are to be checked.
 	 */
 	ret = check_noncircular(next, prev, trace);
-	if (unlikely(bfs_error(ret) || ret == BFS_RMATCH))
+	if (bfs_error(ret) || unlikely(ret == BFS_RMATCH))
 		return 0;
 
 	if (!check_irq_usage(curr, prev, next))
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH v2 2/3] locking/lockdep: Unlikely conditons about BFS_RMATCH
  2021-06-18 14:55 [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
  2021-06-18 14:55 ` [PATCH v2 1/3] locking/lockdep: Unlikely bfs_error() inside Xiongwei Song
@ 2021-06-18 14:55 ` Xiongwei Song
  2021-06-18 14:55 ` [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps Xiongwei Song
  2021-07-12  8:19 ` [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
  3 siblings, 0 replies; 7+ messages in thread
From: Xiongwei Song @ 2021-06-18 14:55 UTC (permalink / raw)
  To: peterz, mingo, will, longman, boqun.feng; +Cc: linux-kernel, Xiongwei Song

From: Xiongwei Song <sxwjean@gmail.com>

The probability that graph walk will return BFS_RMATCH is slim, so unlikey
conditons about BFS_RMATCH can improve performance a little bit.

Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
 kernel/locking/lockdep.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index a8a66a2a9bc1..cb94097014d8 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2750,7 +2750,7 @@ check_redundant(struct held_lock *src, struct held_lock *target)
 	 */
 	ret = check_path(target, &src_entry, hlock_equal, usage_skip, &target_entry);
 
-	if (ret == BFS_RMATCH)
+	if (unlikely(ret == BFS_RMATCH))
 		debug_atomic_inc(nr_redundant);
 
 	return ret;
@@ -2992,7 +2992,7 @@ check_prev_add(struct task_struct *curr, struct held_lock *prev,
 	ret = check_redundant(prev, next);
 	if (bfs_error(ret))
 		return 0;
-	else if (ret == BFS_RMATCH)
+	else if (unlikely(ret == BFS_RMATCH))
 		return 2;
 
 	if (!*trace) {
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps
  2021-06-18 14:55 [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
  2021-06-18 14:55 ` [PATCH v2 1/3] locking/lockdep: Unlikely bfs_error() inside Xiongwei Song
  2021-06-18 14:55 ` [PATCH v2 2/3] locking/lockdep: Unlikely conditons about BFS_RMATCH Xiongwei Song
@ 2021-06-18 14:55 ` Xiongwei Song
  2021-06-24  8:03   ` Xiongwei Song
  2021-06-24 13:45   ` Boqun Feng
  2021-07-12  8:19 ` [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
  3 siblings, 2 replies; 7+ messages in thread
From: Xiongwei Song @ 2021-06-18 14:55 UTC (permalink / raw)
  To: peterz, mingo, will, longman, boqun.feng; +Cc: linux-kernel, Xiongwei Song

From: Xiongwei Song <sxwjean@gmail.com>

The graph walk might hit error when counting dependencies. Once the
return value is negative, print a warning to reminder users.

However, lockdep_unlock() would be called twice if we call print_bfs_bug()
directly in __lockdep_count_*_deps(), so as the suggestion from Boqun:
"
Here print_bfs_bug() will eventually call debug_locks_off_graph_unlock()
to release the graph lock, and the caller (lockdep_count_fowards_deps())
will also call graph_unlock() afterwards, and that means we unlock
*twice* if a BFS error happens... although in that case, lockdep should
stop working so messing up with the graph lock may not hurt anything,
but still, I don't think we want to do that.

So probably you can open-code __lockdep_count_forward_deps() into
lockdep_count_forwards_deps(), and call print_bfs_bug() or
graph_unlock() accordingly. The body of __lockdep_count_forward_deps()
is really small, so I think it's OK to open-code it into its caller.
"
we put the code in __lockdep_count_*_deps() into lockdep_count_*_deps().

Suggested-by: Waiman Long <longman@redhat.com>
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
---
 kernel/locking/lockdep.c | 45 +++++++++++++++++++---------------------
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index cb94097014d8..c29453b1df50 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2024,55 +2024,52 @@ static bool noop_count(struct lock_list *entry, void *data)
 	return false;
 }
 
-static unsigned long __lockdep_count_forward_deps(struct lock_list *this)
-{
-	unsigned long  count = 0;
-	struct lock_list *target_entry;
-
-	__bfs_forwards(this, (void *)&count, noop_count, NULL, &target_entry);
-
-	return count;
-}
 unsigned long lockdep_count_forward_deps(struct lock_class *class)
 {
-	unsigned long ret, flags;
+	unsigned long count = 0, flags;
 	struct lock_list this;
+	struct lock_list *target_entry;
+	enum bfs_result result;
 
 	__bfs_init_root(&this, class);
 
 	raw_local_irq_save(flags);
 	lockdep_lock();
-	ret = __lockdep_count_forward_deps(&this);
-	lockdep_unlock();
-	raw_local_irq_restore(flags);
 
-	return ret;
-}
+	result = __bfs_forwards(&this, (void *)&count, noop_count, NULL, &target_entry);
 
-static unsigned long __lockdep_count_backward_deps(struct lock_list *this)
-{
-	unsigned long  count = 0;
-	struct lock_list *target_entry;
+	if (bfs_error(result))
+		print_bfs_bug(result);
+	else
+		lockdep_unlock();
 
-	__bfs_backwards(this, (void *)&count, noop_count, NULL, &target_entry);
+	raw_local_irq_restore(flags);
 
 	return count;
 }
 
 unsigned long lockdep_count_backward_deps(struct lock_class *class)
 {
-	unsigned long ret, flags;
+	unsigned long  count = 0, flags;
 	struct lock_list this;
+	struct lock_list *target_entry;
+	enum bfs_result result;
 
 	__bfs_init_root(&this, class);
 
 	raw_local_irq_save(flags);
 	lockdep_lock();
-	ret = __lockdep_count_backward_deps(&this);
-	lockdep_unlock();
+
+	result = __bfs_backwards(&this, (void *)&count, noop_count, NULL, &target_entry);
+
+	if (bfs_error(result))
+		print_bfs_bug(result);
+	else
+		lockdep_unlock();
+
 	raw_local_irq_restore(flags);
 
-	return ret;
+	return count;
 }
 
 /*
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps
  2021-06-18 14:55 ` [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps Xiongwei Song
@ 2021-06-24  8:03   ` Xiongwei Song
  2021-06-24 13:45   ` Boqun Feng
  1 sibling, 0 replies; 7+ messages in thread
From: Xiongwei Song @ 2021-06-24  8:03 UTC (permalink / raw)
  To: Xiongwei Song
  Cc: peterz, mingo, will, longman, Boqun Feng, Linux Kernel Mailing List

Hi experts & Boqun,

Any comments here?

I did a test for the series, got the results below:

/ # cat /proc/lockdep
all lock classes:
ffffffffa6b63c90 FD:   37 BD:    1 +.+.: cgroup_mutex
 -> [ffffffffa6b78d70] pcpu_alloc_mutex
 -> [ffff8a783d5e8760] lock#2
 -> [ffffffffa6b8dc90] iattr_mutex
 -> [ffffffffa6b8de10] kernfs_mutex
 -> [ffffffffa6b63ab8] cgroup_file_kn_lock
 -> [ffffffffa6b63bd8] css_set_lock
 -> [ffffffffa6b65770] freezer_mutex

ffffffffa6b54fd8 FD:    1 BD:   56 -...: (console_sem).lock

ffffffffa6b54f80 FD:   68 BD:   11 +.+.: console_lock
 -> [ffffffffa6a74d58] console_owner_lock
 -> [ffffffffa6a74da0] console_owner
 -> [ffffffffa6a6a2f8] resource_lock
 -> [ffffffffa8013710] &zone->lock
 -> [ffffffffa6bea758] kbd_event_lock
 -> [ffffffffa6be12f8] vga_lock
 -> [ffffffffa6b54fd8] (console_sem).lock
 -> [ffffffffa6b54f38] syslog_lock
 -> [ffffffffa6b802e0] fs_reclaim
 -> [ffffffffa8042500] &x->wait#5
 -> [ffffffffa6bfdc70] gdp_mutex
 -> [ffffffffa80328a0] &k->list_lock
 -> [ffff8a783d5e8760] lock#2
 -> [ffffffffa6b8dc90] iattr_mutex
 -> [ffffffffa6b8de10] kernfs_mutex
 -> [ffffffffa6be2838] bus_type_sem
 -> [ffffffffa6b8e018] sysfs_symlink_target_lock
 -> [ffffffffa80421a0] &dev->power.lock
 -> [ffffffffa6c01110] dpm_list_mtx
 -> [ffffffffa6bdedd0] uevent_sock_mutex
 -> [ffffffffa8032cb0] subsys mutex#7
 -> [ffffffffa6c00958] req_lock
 -> [ffffffffa74e4ce0] &p->pi_lock
 -> [ffffffffa80423e0] &x->wait#7
 -> [ffffffffa74e7f70] &rq->__lock
 -> [ffffffffa8036c30] subsys mutex#19

I compared the TOP 3 of deps count output, the results are completely
same with/without the series patch.

Regards,
Xiongwei


On Fri, Jun 18, 2021 at 10:56 PM Xiongwei Song <sxwjean@me.com> wrote:
>
> From: Xiongwei Song <sxwjean@gmail.com>
>
> The graph walk might hit error when counting dependencies. Once the
> return value is negative, print a warning to reminder users.
>
> However, lockdep_unlock() would be called twice if we call print_bfs_bug()
> directly in __lockdep_count_*_deps(), so as the suggestion from Boqun:
> "
> Here print_bfs_bug() will eventually call debug_locks_off_graph_unlock()
> to release the graph lock, and the caller (lockdep_count_fowards_deps())
> will also call graph_unlock() afterwards, and that means we unlock
> *twice* if a BFS error happens... although in that case, lockdep should
> stop working so messing up with the graph lock may not hurt anything,
> but still, I don't think we want to do that.
>
> So probably you can open-code __lockdep_count_forward_deps() into
> lockdep_count_forwards_deps(), and call print_bfs_bug() or
> graph_unlock() accordingly. The body of __lockdep_count_forward_deps()
> is really small, so I think it's OK to open-code it into its caller.
> "
> we put the code in __lockdep_count_*_deps() into lockdep_count_*_deps().
>
> Suggested-by: Waiman Long <longman@redhat.com>
> Suggested-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
> ---
>  kernel/locking/lockdep.c | 45 +++++++++++++++++++---------------------
>  1 file changed, 21 insertions(+), 24 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index cb94097014d8..c29453b1df50 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2024,55 +2024,52 @@ static bool noop_count(struct lock_list *entry, void *data)
>         return false;
>  }
>
> -static unsigned long __lockdep_count_forward_deps(struct lock_list *this)
> -{
> -       unsigned long  count = 0;
> -       struct lock_list *target_entry;
> -
> -       __bfs_forwards(this, (void *)&count, noop_count, NULL, &target_entry);
> -
> -       return count;
> -}
>  unsigned long lockdep_count_forward_deps(struct lock_class *class)
>  {
> -       unsigned long ret, flags;
> +       unsigned long count = 0, flags;
>         struct lock_list this;
> +       struct lock_list *target_entry;
> +       enum bfs_result result;
>
>         __bfs_init_root(&this, class);
>
>         raw_local_irq_save(flags);
>         lockdep_lock();
> -       ret = __lockdep_count_forward_deps(&this);
> -       lockdep_unlock();
> -       raw_local_irq_restore(flags);
>
> -       return ret;
> -}
> +       result = __bfs_forwards(&this, (void *)&count, noop_count, NULL, &target_entry);
>
> -static unsigned long __lockdep_count_backward_deps(struct lock_list *this)
> -{
> -       unsigned long  count = 0;
> -       struct lock_list *target_entry;
> +       if (bfs_error(result))
> +               print_bfs_bug(result);
> +       else
> +               lockdep_unlock();
>
> -       __bfs_backwards(this, (void *)&count, noop_count, NULL, &target_entry);
> +       raw_local_irq_restore(flags);
>
>         return count;
>  }
>
>  unsigned long lockdep_count_backward_deps(struct lock_class *class)
>  {
> -       unsigned long ret, flags;
> +       unsigned long  count = 0, flags;
>         struct lock_list this;
> +       struct lock_list *target_entry;
> +       enum bfs_result result;
>
>         __bfs_init_root(&this, class);
>
>         raw_local_irq_save(flags);
>         lockdep_lock();
> -       ret = __lockdep_count_backward_deps(&this);
> -       lockdep_unlock();
> +
> +       result = __bfs_backwards(&this, (void *)&count, noop_count, NULL, &target_entry);
> +
> +       if (bfs_error(result))
> +               print_bfs_bug(result);
> +       else
> +               lockdep_unlock();
> +
>         raw_local_irq_restore(flags);
>
> -       return ret;
> +       return count;
>  }
>
>  /*
> --
> 2.30.2
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps
  2021-06-18 14:55 ` [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps Xiongwei Song
  2021-06-24  8:03   ` Xiongwei Song
@ 2021-06-24 13:45   ` Boqun Feng
  1 sibling, 0 replies; 7+ messages in thread
From: Boqun Feng @ 2021-06-24 13:45 UTC (permalink / raw)
  To: Xiongwei Song; +Cc: peterz, mingo, will, longman, linux-kernel, Xiongwei Song

On Fri, Jun 18, 2021 at 10:55:34PM +0800, Xiongwei Song wrote:
> From: Xiongwei Song <sxwjean@gmail.com>
> 
> The graph walk might hit error when counting dependencies. Once the
> return value is negative, print a warning to reminder users.
> 
> However, lockdep_unlock() would be called twice if we call print_bfs_bug()
> directly in __lockdep_count_*_deps(), so as the suggestion from Boqun:
> "
> Here print_bfs_bug() will eventually call debug_locks_off_graph_unlock()
> to release the graph lock, and the caller (lockdep_count_fowards_deps())
> will also call graph_unlock() afterwards, and that means we unlock
> *twice* if a BFS error happens... although in that case, lockdep should
> stop working so messing up with the graph lock may not hurt anything,
> but still, I don't think we want to do that.
> 
> So probably you can open-code __lockdep_count_forward_deps() into
> lockdep_count_forwards_deps(), and call print_bfs_bug() or
> graph_unlock() accordingly. The body of __lockdep_count_forward_deps()
> is really small, so I think it's OK to open-code it into its caller.
> "
> we put the code in __lockdep_count_*_deps() into lockdep_count_*_deps().
> 
> Suggested-by: Waiman Long <longman@redhat.com>
> Suggested-by: Boqun Feng <boqun.feng@gmail.com>
> Signed-off-by: Xiongwei Song <sxwjean@gmail.com>

Reviewed-by: Boqun Feng <boqun.feng@gmail.com>

Thanks!

Regards,
Boqun

> ---
>  kernel/locking/lockdep.c | 45 +++++++++++++++++++---------------------
>  1 file changed, 21 insertions(+), 24 deletions(-)
> 
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index cb94097014d8..c29453b1df50 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2024,55 +2024,52 @@ static bool noop_count(struct lock_list *entry, void *data)
>  	return false;
>  }
>  
> -static unsigned long __lockdep_count_forward_deps(struct lock_list *this)
> -{
> -	unsigned long  count = 0;
> -	struct lock_list *target_entry;
> -
> -	__bfs_forwards(this, (void *)&count, noop_count, NULL, &target_entry);
> -
> -	return count;
> -}
>  unsigned long lockdep_count_forward_deps(struct lock_class *class)
>  {
> -	unsigned long ret, flags;
> +	unsigned long count = 0, flags;
>  	struct lock_list this;
> +	struct lock_list *target_entry;
> +	enum bfs_result result;
>  
>  	__bfs_init_root(&this, class);
>  
>  	raw_local_irq_save(flags);
>  	lockdep_lock();
> -	ret = __lockdep_count_forward_deps(&this);
> -	lockdep_unlock();
> -	raw_local_irq_restore(flags);
>  
> -	return ret;
> -}
> +	result = __bfs_forwards(&this, (void *)&count, noop_count, NULL, &target_entry);
>  
> -static unsigned long __lockdep_count_backward_deps(struct lock_list *this)
> -{
> -	unsigned long  count = 0;
> -	struct lock_list *target_entry;
> +	if (bfs_error(result))
> +		print_bfs_bug(result);
> +	else
> +		lockdep_unlock();
>  
> -	__bfs_backwards(this, (void *)&count, noop_count, NULL, &target_entry);
> +	raw_local_irq_restore(flags);
>  
>  	return count;
>  }
>  
>  unsigned long lockdep_count_backward_deps(struct lock_class *class)
>  {
> -	unsigned long ret, flags;
> +	unsigned long  count = 0, flags;
>  	struct lock_list this;
> +	struct lock_list *target_entry;
> +	enum bfs_result result;
>  
>  	__bfs_init_root(&this, class);
>  
>  	raw_local_irq_save(flags);
>  	lockdep_lock();
> -	ret = __lockdep_count_backward_deps(&this);
> -	lockdep_unlock();
> +
> +	result = __bfs_backwards(&this, (void *)&count, noop_count, NULL, &target_entry);
> +
> +	if (bfs_error(result))
> +		print_bfs_bug(result);
> +	else
> +		lockdep_unlock();
> +
>  	raw_local_irq_restore(flags);
>  
> -	return ret;
> +	return count;
>  }
>  
>  /*
> -- 
> 2.30.2
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2 0/3] some improvements for lockdep
  2021-06-18 14:55 [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
                   ` (2 preceding siblings ...)
  2021-06-18 14:55 ` [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps Xiongwei Song
@ 2021-07-12  8:19 ` Xiongwei Song
  3 siblings, 0 replies; 7+ messages in thread
From: Xiongwei Song @ 2021-07-12  8:19 UTC (permalink / raw)
  To: Xiongwei Song
  Cc: peterz, mingo, will, longman, Boqun Feng, Linux Kernel Mailing List

Hi Peter,

Will  you pick up this series?

Regards,
Xiongwei

On Fri, Jun 18, 2021 at 10:55 PM Xiongwei Song <sxwjean@me.com> wrote:
>
> From: Xiongwei Song <sxwjean@gmail.com>
>
> Unlikely the checks of return values of graph walk will improve the
> performance to some degree, patch 1 and patch 2 are for this.
>
> The patch 3 will print a warning after counting lock deps when hitting
> bfs errors.
>
> v2:
> * For patch 3, avoid to call lockdep_unlock() twice after counting deps.
>   Please see https://lkml.org/lkml/2021/6/17/741.
>
> Xiongwei Song (3):
>   locking/lockdep: Unlikely bfs_error() inside
>   locking/lockdep: Unlikely conditons about BFS_RMATCH
>   locking/lockdep: Print possible warning after counting deps
>
>  kernel/locking/lockdep.c | 55 +++++++++++++++++++---------------------
>  1 file changed, 26 insertions(+), 29 deletions(-)
>
> --
> 2.30.2
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-07-12  9:04 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-18 14:55 [PATCH v2 0/3] some improvements for lockdep Xiongwei Song
2021-06-18 14:55 ` [PATCH v2 1/3] locking/lockdep: Unlikely bfs_error() inside Xiongwei Song
2021-06-18 14:55 ` [PATCH v2 2/3] locking/lockdep: Unlikely conditons about BFS_RMATCH Xiongwei Song
2021-06-18 14:55 ` [PATCH v2 3/3] locking/lockdep: Print possible warning after counting deps Xiongwei Song
2021-06-24  8:03   ` Xiongwei Song
2021-06-24 13:45   ` Boqun Feng
2021-07-12  8:19 ` [PATCH v2 0/3] some improvements for lockdep Xiongwei Song

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).