linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: nan chen <nachenn@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Yuanhan Liu <yuanhan.liu@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 2/2] mutex: use spin_[un]lock instead of arch_spin_[un]lock
Date: Tue, 29 Jan 2013 10:01:26 +0100	[thread overview]
Message-ID: <20130129090126.GA5547@gmail.com> (raw)
In-Reply-To: <CABBm896XGVkubML9TyW_MTXMovd6nHoK0v24jbEDJOipzNqpDA@mail.gmail.com>


* nan chen <nachenn@gmail.com> wrote:

> 2013/1/25 Ingo Molnar <mingo@kernel.org>
> 
> >
> > * nan chen <nachenn@gmail.com> wrote:
> >
> > > 2013/1/25 Ingo Molnar <mingo@kernel.org>
> > >
> > > >
> > > > * Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > > On Thu, 24 Jan 2013 17:22:45 +0800
> > > > > Yuanhan Liu <yuanhan.liu@linux.intel.com> wrote:
> > > > >
> > > > > > Use spin_[un]lock instead of arch_spin_[un]lock in mutex-debug.h so
> > > > > > that we can collect the lock statistics of spin_lock_mutex from
> > > > > > /proc/lock_stat.
> > > >
> > > > So, as per the discussion we don't want this patch, because we
> > > > are using raw locks there to keep mutex lockdep overhead low.
> > > > The value of lockdep-checking such a basic locking primitive is
> > > > minimal - it's rarely tweaked and if it breaks we won't have a
> > > > bootable kernel to begin with.
> > > >
> > > > So instead I suggested a different patch: adding a comment to
> > > > explain why we don't lockdep-cover the mutex code spinlocks.
> > > >
> > > > > Also, I believe your patch permits this cleanup:
> > > > >
> > > > > ---
> > > >
> > a/kernel/mutex-debug.h~mutex-use-spin_lock-instead-of-arch_spin_lock-fix
> > > > > +++ a/kernel/mutex-debug.h
> > > > > @@ -42,14 +42,12 @@ static inline void mutex_clear_owner(str
> > > > >               struct mutex *l = container_of(lock, struct mutex,
> > > > wait_lock); \
> > > > >                                                       \
> > > > >               DEBUG_LOCKS_WARN_ON(in_interrupt());    \
> > > > > -             local_irq_save(flags);                  \
> > > > > -             spin_lock(lock);                        \
> > > > > +             spin_lock_irqsave(lock, flags);         \
> > > >
> > > > Yes, I mentioned that yesterday, but we really don't want the
> > > > change to begin with.
> > > >
> > > > Thanks,
> > > >
> > > >         Ingo
> > > >
> > >
> > > Hi,
> > >
> > > Looks like in mutex.h, it does not disable local interrupt.
> > > But why the code disable local interrupt in mutex-debug.h?
> >
> > To protect against preemption I suspect. preempt_disable() could
> > be used in the mutex-debug.h variant I suppose.
> >
> > Thanks,
> >
> >         Ingo
> >
> 
> 
> spin_lock() itself already protects against preemption.

Yes, but mutex-debug.h does not use spin_lock(), it uses 
arch_spin_lock():

#define spin_lock_mutex(lock, flags)                    \
        do {                                            \
                struct mutex *l = container_of(lock, struct mutex, wait_lock); \
                                                        \
                DEBUG_LOCKS_WARN_ON(in_interrupt());    \
                local_irq_save(flags);                  \
                arch_spin_lock(&(lock)->rlock.raw_lock);\
                DEBUG_LOCKS_WARN_ON(l->magic != l);     \
        } while (0)

The original question was why mutex-debug.h (unmodified) uses 
irq disabling.

Thanks,

	Ingo

  parent reply	other threads:[~2013-01-29  9:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24  9:22 [PATCH 1/2] lockstat: fix a typo Yuanhan Liu
2013-01-24  9:22 ` [PATCH 2/2] mutex: use spin_[un]lock instead of arch_spin_[un]lock Yuanhan Liu
2013-01-24  9:58   ` Ingo Molnar
2013-01-24 10:13     ` Yuanhan Liu
2013-01-24 10:14       ` Ingo Molnar
2013-01-24 10:27         ` Yuanhan Liu
2013-01-24 10:54           ` Ingo Molnar
2013-01-25  0:14   ` Andrew Morton
2013-01-25  0:50     ` Steven Rostedt
2013-01-25  0:56       ` Andrew Morton
2013-01-25  1:03         ` Steven Rostedt
2013-01-25  7:40     ` Ingo Molnar
     [not found]       ` <CABBm8944FSNDZ2u=PJy0CsZmz=Vm7e+Y5jX+3UFLN5NOSGRgWQ@mail.gmail.com>
2013-01-25  9:24         ` Ingo Molnar
     [not found]           ` <CABBm896XGVkubML9TyW_MTXMovd6nHoK0v24jbEDJOipzNqpDA@mail.gmail.com>
2013-01-29  9:01             ` Ingo Molnar [this message]
     [not found]               ` <CABBm8979+XVRA-MQRdczMbStJR7DyPwNUvQL+RTuQL0sECOo8g@mail.gmail.com>
2013-01-29  9:28                 ` Ingo Molnar
2013-01-24 20:03 ` [tip:core/locking] locking/stat: Fix a typo tip-bot for Yuanhan Liu
2013-02-22 12:20 ` tip-bot for Yuanhan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130129090126.GA5547@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nachenn@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=yuanhan.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).