Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1501865
| Path | csiph.com!aioe.org!bofh.it!news.nic.it!robomod |
|---|---|
| From | Peter Zijlstra <peterz@infradead.org> |
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop |
| Date | Mon, 17 Oct 2016 12:50:01 +0200 |
| Message-ID | <stdEt-2li-9@gated-at.bofh.it> (permalink) |
| References | <spEWB-2dt-5@gated-at.bofh.it> <spFfX-2lv-15@gated-at.bofh.it> <srPXB-5cV-37@gated-at.bofh.it> |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=us-ascii |
| Content-Disposition | inline |
| User-Agent | Mutt/1.5.23.1 (2014-03-12) |
| Sender | robomod@news.nic.it |
| List-ID | <linux-kernel.vger.kernel.org> |
| X-Mailing-List | linux-kernel@vger.kernel.org |
| Approved | robomod@news.nic.it |
| Lines | 63 |
| Organization | linux.* mail to news gateway |
| X-Original-Cc | Linus Torvalds <torvalds@linux-foundation.org>, Waiman Long <waiman.long@hpe.com>, Jason Low <jason.low2@hpe.com>, Ding Tianhong <dingtianhong@huawei.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Imre Deak <imre.deak@intel.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Davidlohr Bueso <dave@stgolabs.net>, Tim Chen <tim.c.chen@linux.intel.com>, Terry Rudd <terry.rudd@hpe.com>, "Paul E. McKenney" <paulmck@us.ibm.com>, Jason Low <jason.low2@hp.com>, Chris Wilson <chris@chris-wilson.co.uk>, Daniel Vetter <daniel.vetter@ffwll.ch> |
| X-Original-Date | Mon, 17 Oct 2016 12:44:49 +0200 |
| X-Original-Message-ID | <20161017104449.GO3117@twins.programming.kicks-ass.net> |
| X-Original-References | <20161007145243.361481786@infradead.org> <20161007150211.271490994@infradead.org> <20161013151720.GB13138@arm.com> |
| X-Original-Sender | linux-kernel-owner@vger.kernel.org |
| Xref | csiph.com linux.kernel:1501865 |
Show key headers only | View raw
On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> Hi Peter,
>
> I'm struggling to get my head around the handoff code after this change...
>
> On Fri, Oct 07, 2016 at 04:52:49PM +0200, Peter Zijlstra wrote:
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.c
> > @@ -631,13 +631,21 @@ __mutex_lock_common(struct mutex *lock,
> >
> > lock_contended(&lock->dep_map, ip);
> >
> > + set_task_state(task, state);
> > for (;;) {
> > + /*
> > + * Once we hold wait_lock, we're serialized against
> > + * mutex_unlock() handing the lock off to us, do a trylock
> > + * before testing the error conditions to make sure we pick up
> > + * the handoff.
> > + */
> > if (__mutex_trylock(lock, first))
> > - break;
> > + goto acquired;
> >
> > /*
> > - * got a signal? (This code gets eliminated in the
> > - * TASK_UNINTERRUPTIBLE case.)
> > + * Check for signals and wound conditions while holding
> > + * wait_lock. This ensures the lock cancellation is ordered
> > + * against mutex_unlock() and wake-ups do not go missing.
> > */
> > if (unlikely(signal_pending_state(state, task))) {
> > ret = -EINTR;
> > @@ -650,16 +658,27 @@ __mutex_lock_common(struct mutex *lock,
> > goto err;
> > }
> >
> > - __set_task_state(task, state);
> > spin_unlock_mutex(&lock->wait_lock, flags);
> > schedule_preempt_disabled();
> > - spin_lock_mutex(&lock->wait_lock, flags);
> >
> > if (!first && __mutex_waiter_is_first(lock, &waiter)) {
> > first = true;
> > __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
> > }
> > +
> > + set_task_state(task, state);
>
> With this change, we no longer hold the lock wit_hen we set the task
> state, and it's ordered strictly *after* setting the HANDOFF flag.
> Doesn't that mean that the unlock code can see the HANDOFF flag, issue
> the wakeup, but then we come in and overwrite the task state?
>
> I'm struggling to work out whether that's an issue, but it certainly
> feels odd and is a change from the previous behaviour.
Right, so I think the code is fine, since in that case the
__mutex_trylock() must see the handoff and we'll break the loop and
(re)set the state to RUNNING.
But you're right in that its slightly odd. I'll reorder them and put the
set_task_state() above the !first thing.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop Will Deacon <will.deacon@arm.com> - 2016-10-13 17:20 +0200
Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop Peter Zijlstra <peterz@infradead.org> - 2016-10-17 12:50 +0200
Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop Peter Zijlstra <peterz@infradead.org> - 2016-10-17 15:30 +0200
Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop Boqun Feng <boqun.feng@gmail.com> - 2016-10-17 15:50 +0200
Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop Peter Zijlstra <peterz@infradead.org> - 2016-10-17 18:00 +0200
Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop Peter Zijlstra <peterz@infradead.org> - 2016-10-19 19:40 +0200
ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop) Davidlohr Bueso <dave@stgolabs.net> - 2016-10-24 04:00 +0200
Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop) Kent Overstreet <kent.overstreet@gmail.com> - 2016-10-24 15:30 +0200
Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop) Kent Overstreet <kent.overstreet@gmail.com> - 2016-10-24 16:30 +0200
Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop) Eric Wheeler <bcache@lists.ewheeler.net> - 2016-10-25 19:00 +0200
Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop) Kent Overstreet <kent.overstreet@gmail.com> - 2016-10-25 19:50 +0200
csiph-web