Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1336156 > unrolled thread

[PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

Started byByungchul Park <byungchul.park@lge.com>
First post2016-02-17 10:20 +0100
Last post2016-02-18 09:20 +0100
Articles 5 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up() Byungchul Park <byungchul.park@lge.com> - 2016-02-17 10:20 +0100
    Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within  up() Ingo Molnar <mingo@kernel.org> - 2016-02-17 10:30 +0100
      Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within  up() Byungchul Park <byungchul.park@lge.com> - 2016-02-18 09:10 +0100
    Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within  up() Peter Zijlstra <peterz@infradead.org> - 2016-02-17 11:50 +0100
      Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within  up() Byungchul Park <byungchul.park@lge.com> - 2016-02-18 09:20 +0100

#1336156 — [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

FromByungchul Park <byungchul.park@lge.com>
Date2016-02-17 10:20 +0100
Subject[PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()
Message-ID<r36r7-4hD-1@gated-at.bofh.it>
change from v2 to v3
- the way to solve it in v2 is racy, so I changed the approach entirely.
- just make semaphore's trylock use spinlock's trylock.

change from v1 to v2
- remove unnecessary overhead by the redundant spin(un)lock.

Since I faced a infinite recursive printk() bug, I've tried to propose
patches the title of which is "lib/spinlock_debug.c: prevent a recursive
cycle in the debug code". But I noticed the root problem cannot be fixed
by that, through some discussion thanks to Sergey and Peter. So I focused
on preventing the deadlock.

-----8<-----
From 43e029ca920890ac644e30d873be69cf5d01efdb Mon Sep 17 00:00:00 2001
From: Byungchul Park <byungchul.park@lge.com>
Date: Wed, 17 Feb 2016 17:22:18 +0900
Subject: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

One of semaphore acquisition functions, down_trylock() is implemented
using raw_spin_lock_irqsave(&sem->lock) even though it's enough to use
raw_spin_trylock_irqsave(). Furthermore, using raw_spin_lock_irqsave()
can cause a unnecessary deadlock as described below. Just make it use
the spinlock trylock to implement the semaphore trylock so that we can
avoid the unnecessary deadlock happened.

The scenario the bad thing can happen is,

printk
  console_trylock
  console_unlock
    up_console_sem
      up
        raw_spin_lock_irqsave(&sem->lock, flags)
        __up
          wake_up_process
            try_to_wake_up
              raw_spin_lock_irqsave(&p->pi_lock)
                __spin_lock_debug
                  spin_dump
                    printk
                      console_trylock
                        raw_spin_lock_irqsave(&sem->lock, flags)
                        >>> DEADLOCK <<<

Signed-off-by: Byungchul Park <byungchul.park@lge.com>
---
 kernel/locking/semaphore.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index b8120ab..6634b68 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -130,13 +130,14 @@ EXPORT_SYMBOL(down_killable);
 int down_trylock(struct semaphore *sem)
 {
 	unsigned long flags;
-	int count;
+	int count = -1;
 
-	raw_spin_lock_irqsave(&sem->lock, flags);
-	count = sem->count - 1;
-	if (likely(count >= 0))
-		sem->count = count;
-	raw_spin_unlock_irqrestore(&sem->lock, flags);
+	if (raw_spin_trylock_irqsave(&sem->lock, flags)) {
+		count = sem->count - 1;
+		if (likely(count >= 0))
+			sem->count = count;
+		raw_spin_unlock_irqrestore(&sem->lock, flags);
+	}
 
 	return (count < 0);
 }
-- 
1.9.1

[toc] | [next] | [standalone]


#1336158 — Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

FromIngo Molnar <mingo@kernel.org>
Date2016-02-17 10:30 +0100
SubjectRe: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()
Message-ID<r36AO-4lp-1@gated-at.bofh.it>
In reply to#1336156
* Byungchul Park <byungchul.park@lge.com> wrote:

> diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
> index b8120ab..6634b68 100644
> --- a/kernel/locking/semaphore.c
> +++ b/kernel/locking/semaphore.c
> @@ -130,13 +130,14 @@ EXPORT_SYMBOL(down_killable);
>  int down_trylock(struct semaphore *sem)
>  {
>  	unsigned long flags;
> -	int count;
> +	int count = -1;
>  
> -	raw_spin_lock_irqsave(&sem->lock, flags);
> -	count = sem->count - 1;
> -	if (likely(count >= 0))
> -		sem->count = count;
> -	raw_spin_unlock_irqrestore(&sem->lock, flags);
> +	if (raw_spin_trylock_irqsave(&sem->lock, flags)) {
> +		count = sem->count - 1;
> +		if (likely(count >= 0))
> +			sem->count = count;
> +		raw_spin_unlock_irqrestore(&sem->lock, flags);
> +	}

I still don't really like it: two parallel trylocks will cause one of them to fail 
- while with the previous code they would both succeed.

None of these changes are necessary with all the printk robustification 
changes/enhancements we talked about, right?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1337121 — Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

FromByungchul Park <byungchul.park@lge.com>
Date2016-02-18 09:10 +0100
SubjectRe: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()
Message-ID<r3rOW-2FS-25@gated-at.bofh.it>
In reply to#1336158
On Wed, Feb 17, 2016 at 10:28:29AM +0100, Ingo Molnar wrote:
> 
> * Byungchul Park <byungchul.park@lge.com> wrote:
> 
> > diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
> > index b8120ab..6634b68 100644
> > --- a/kernel/locking/semaphore.c
> > +++ b/kernel/locking/semaphore.c
> > @@ -130,13 +130,14 @@ EXPORT_SYMBOL(down_killable);
> >  int down_trylock(struct semaphore *sem)
> >  {
> >  	unsigned long flags;
> > -	int count;
> > +	int count = -1;
> >  
> > -	raw_spin_lock_irqsave(&sem->lock, flags);
> > -	count = sem->count - 1;
> > -	if (likely(count >= 0))
> > -		sem->count = count;
> > -	raw_spin_unlock_irqrestore(&sem->lock, flags);
> > +	if (raw_spin_trylock_irqsave(&sem->lock, flags)) {
> > +		count = sem->count - 1;
> > +		if (likely(count >= 0))
> > +			sem->count = count;
> > +		raw_spin_unlock_irqrestore(&sem->lock, flags);
> > +	}
> 
> I still don't really like it: two parallel trylocks will cause one of them to fail 
> - while with the previous code they would both succeed.
> 
> None of these changes are necessary with all the printk robustification 
> changes/enhancements we talked about, right?

Right. I expect that Jan's patch which Sergey informed can make printk
robuster. Actually I'm waiting for the patch done. And I thought that it's
also a problem that a trylock implementation can make a system deadlock.
Don't you think it need to make a trylock only either acquire or fail in
any case? IMHO, waiting something within trylock is wrong. I'm just
curious.

Thanks,
Byungchul

> 
> Thanks,
> 
> 	Ingo

[toc] | [prev] | [next] | [standalone]


#1336247 — Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

FromPeter Zijlstra <peterz@infradead.org>
Date2016-02-17 11:50 +0100
SubjectRe: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()
Message-ID<r37Qf-59r-59@gated-at.bofh.it>
In reply to#1336156
On Wed, Feb 17, 2016 at 06:11:51PM +0900, Byungchul Park wrote:
> change from v2 to v3
> - the way to solve it in v2 is racy, so I changed the approach entirely.
> - just make semaphore's trylock use spinlock's trylock.
> 
> change from v1 to v2
> - remove unnecessary overhead by the redundant spin(un)lock.
> 
> Since I faced a infinite recursive printk() bug, I've tried to propose
> patches the title of which is "lib/spinlock_debug.c: prevent a recursive
> cycle in the debug code". But I noticed the root problem cannot be fixed
> by that, through some discussion thanks to Sergey and Peter. So I focused
> on preventing the deadlock.
> 
> -----8<-----
> From 43e029ca920890ac644e30d873be69cf5d01efdb Mon Sep 17 00:00:00 2001
> From: Byungchul Park <byungchul.park@lge.com>
> Date: Wed, 17 Feb 2016 17:22:18 +0900
> Subject: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()
> 
> One of semaphore acquisition functions, down_trylock() is implemented
> using raw_spin_lock_irqsave(&sem->lock) even though it's enough to use
> raw_spin_trylock_irqsave(). Furthermore, using raw_spin_lock_irqsave()
> can cause a unnecessary deadlock as described below. Just make it use
> the spinlock trylock to implement the semaphore trylock so that we can
> avoid the unnecessary deadlock happened.
> 
> The scenario the bad thing can happen is,
> 
> printk
>   console_trylock
>   console_unlock
>     up_console_sem
>       up
>         raw_spin_lock_irqsave(&sem->lock, flags)
>         __up
>           wake_up_process
>             try_to_wake_up
>               raw_spin_lock_irqsave(&p->pi_lock)
>                 __spin_lock_debug
>                   spin_dump
>                     printk
>                       console_trylock
>                         raw_spin_lock_irqsave(&sem->lock, flags)
>                         >>> DEADLOCK <<<
> 
> Signed-off-by: Byungchul Park <byungchul.park@lge.com>

Mucking with the semaphore implementation just because printk() is
terminally broken shite really doesn't fly.

[toc] | [prev] | [next] | [standalone]


#1337127 — Re: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()

FromByungchul Park <byungchul.park@lge.com>
Date2016-02-18 09:20 +0100
SubjectRe: [PATCH v3] lock/semaphore: Avoid an unnecessary deadlock within up()
Message-ID<r3rYC-2K0-15@gated-at.bofh.it>
In reply to#1336247
On Wed, Feb 17, 2016 at 11:40:49AM +0100, Peter Zijlstra wrote:
> Mucking with the semaphore implementation just because printk() is
> terminally broken shite really doesn't fly.

Jan is currently working on the terminally broken shite, and I expect it
makes printk() robuster. I just tried this patch because I though the
semaphore also need to be fixed and furthermore it can fix a deadlock by
removing the waiting within trylock. I think it's reasonable. Wrong?

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web