From: Andrei Vagin <avagin@gmail.com>
To: Peter Oskolkov <posk@posk.io>
Cc: Aaron Lu <aaron.lwe@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Darren Hart <dvhart@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Peter Oskolkov <posk@google.com>,
avagin@google.com, "pjt@google.com" <pjt@google.com>,
Ben Segall <bsegall@google.com>
Subject: Re: [RFC PATCH 1/3 v2] futex: introduce FUTEX_SWAP operation
Date: Tue, 23 Jun 2020 12:45:29 -0700 [thread overview]
Message-ID: <20200623194529.GA71413@gmail.com> (raw)
In-Reply-To: <d29a2ba031ecd96f785a602e703d97e24980ef15.camel@posk.io>
On Tue, Jun 23, 2020 at 11:30:30AM -0700, Peter Oskolkov wrote:
...
> > > /**
> > > +static int futex_swap(u32 __user *uaddr, unsigned int flags, u32
> > > val,
> > > + ktime_t *abs_time, u32 __user *uaddr2)
> > > +{
> > > + u32 bitset = FUTEX_BITSET_MATCH_ANY;
> > > + struct task_struct *next = NULL;
> > > + DEFINE_WAKE_Q(wake_q);
> > > + int ret;
> > > +
> > > + ret = prepare_wake_q(uaddr2, flags, 1, bitset, &wake_q);
> > > + if (!wake_q_empty(&wake_q)) {
> > > + /* Pull the first wakee out of the queue to swap into.
> > > */
> > > + next = container_of(wake_q.first, struct task_struct,
> > > wake_q);
> > > + wake_q.first = wake_q.first->next;
> > > + next->wake_q.next = NULL;
> > > + /*
> > > + * Note that wake_up_q does not touch wake_q.last, so
> > > we
> > > + * do not bother with it here.
> > > + */
> > > + wake_up_q(&wake_q);
> >
> > wake_up_q() doesn't seem to serve any purpose in that the above
> > assignment of wake_q.first shall make it an empty queue now?
> > Also, I don't see a need to touch wake_q.first either so I think we
> > can
> > get rid of wake_q altogether here.
>
> The futex at uaddr2 may have more than one waiter, so we cannot assume
> that wake_q will be empty when we remove the first element.
The third argument of prepare_wake_q is nr_wake which is one in this
case, so we can be sure that wake_q will be empty, can't we?
>
> >
> > > + }
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + return futex_wait(uaddr, flags, val, abs_time, bitset, next);
> > > +}
> >
next prev parent reply other threads:[~2020-06-23 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 17:22 [RFC PATCH 1/3 v2] futex: introduce FUTEX_SWAP operation Peter Oskolkov
2020-06-18 0:48 ` Andrei Vagin
2020-06-23 13:25 ` Aaron Lu
2020-06-23 18:30 ` Peter Oskolkov
2020-06-23 19:45 ` Andrei Vagin [this message]
2020-06-23 20:59 ` Peter Oskolkov
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=20200623194529.GA71413@gmail.com \
--to=avagin@gmail.com \
--cc=aaron.lwe@gmail.com \
--cc=avagin@google.com \
--cc=bsegall@google.com \
--cc=dvhart@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=posk@google.com \
--cc=posk@posk.io \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
/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