From: Darren Hart <dvhart@infradead.org>
To: Julia Cartwright <julia@ni.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Gratian Crisan <gratian.crisan@ni.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>
Subject: Re: PI futexes + lock stealing woes
Date: Fri, 1 Dec 2017 16:32:38 -0800 [thread overview]
Message-ID: <20171202003238.GA27831@fury> (raw)
In-Reply-To: <20171201214901.GB32696@jcartwri.amer.corp.natinst.com>
On Fri, Dec 01, 2017 at 03:49:01PM -0600, Julia Cartwright wrote:
> On Fri, Dec 01, 2017 at 12:11:15PM -0800, Darren Hart wrote:
> > On Wed, Nov 29, 2017 at 11:56:05AM -0600, Julia Cartwright wrote:
> >
> > > The actual kernel we've been testing is 4.9.33-rt23, w/ 153fbd1226fb3
> > > ("futex: Fix more put_pi_state() vs. exit_pi_state_list() races")
> >
> > And this does not exhibit the behavior above, correct?
>
> Sorry if I was unclear. This combination _does_ exhibit this incorrect
> behavior.
>
> > > cherry-picked w/ PREEMPT_RT_FULL. However, it appears that this issue
> > > may affect v4.15-rc1?
> >
> > And this does?
>
> I only meant that: as far as I can tell the affected codepaths are
> mostly the same between v4.9.33-rt23 and v4.15-rc1, as the futex
> reworking stuff was cherry-picked back.
>
Can you compare the futex and rtmutex related histories and see if there
is possibly something missing from the backport? A diff from current
version of the relevant files would be worth doing as well. There is
enough subtly here, that I'd want to be as confident as possible that we
aren't missing something here.
> We haven't yet tried reproducing on v4.15-rc1, and aren't really at a
> place where we can do so quickly. It's unclear whether or not
> PREEMPT_RT is required to reproduce.
Obviously reproducing on an unmodified upstream (RT or not) would be a
very valuable data point.
>
> Thanks!
> Julia
>
--
Darren Hart
VMware Open Source Technology Center
next prev parent reply other threads:[~2017-12-02 0:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 17:56 PI futexes + lock stealing woes Julia Cartwright
2017-12-01 20:11 ` Darren Hart
2017-12-01 21:49 ` Julia Cartwright
2017-12-02 0:32 ` Darren Hart [this message]
2017-12-06 23:46 ` Peter Zijlstra
2017-12-07 2:09 ` Gratian Crisan
2017-12-07 10:45 ` Peter Zijlstra
2017-12-07 14:26 ` Peter Zijlstra
2017-12-07 14:57 ` Gratian Crisan
2017-12-07 19:50 ` Julia Cartwright
2017-12-07 23:02 ` Gratian Crisan
2017-12-08 12:49 ` [PATCH] futex: Avoid violating the 10th rule of futex Peter Zijlstra
2017-12-08 16:04 ` Gratian Crisan
2018-01-08 21:09 ` Julia Cartwright
2018-01-14 18:06 ` [tip:locking/urgent] " tip-bot for Peter Zijlstra
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=20171202003238.GA27831@fury \
--to=dvhart@infradead.org \
--cc=gratian.crisan@ni.com \
--cc=julia@ni.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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).