From: Peter Oskolkov <posk@posk.io>
To: Thierry Delisle <tdelisle@uwaterloo.ca>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
linux-mm@kvack.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org, Paul Turner <pjt@google.com>,
Ben Segall <bsegall@google.com>, Peter Oskolkov <posk@google.com>,
Andrei Vagin <avagin@google.com>, Jann Horn <jannh@google.com>
Subject: Re: [PATCH v0.8 3/6] sched/umcg: implement UMCG syscalls
Date: Sun, 7 Nov 2021 20:09:04 -0800 [thread overview]
Message-ID: <CAFTs51XU1rKqSscdFK69RUCtaKrLJ1r5pdXSBJ1qc3=ZMNorBw@mail.gmail.com> (raw)
In-Reply-To: <ec84f37d-da30-8f03-3864-0c94078f6e21@uwaterloo.ca>
On Fri, Nov 5, 2021 at 4:48 PM Thierry Delisle <tdelisle@uwaterloo.ca> wrote:
>
> On 2021-11-04 3:58 p.m., Peter Oskolkov wrote:
> > +/*
> > + * Try to wake up. May be called with preempt_disable set. May be called
> > + * cross-process.
> > + *
> > + * Note: umcg_ttwu succeeds even if ttwu fails: see wait/wake state
> > + * ordering logic.
> > + */
> > +static int umcg_ttwu(u32 next_tid, int wake_flags)
> > +{
> > + struct task_struct *next;
> > +
> > + rcu_read_lock();
> > + next = find_task_by_vpid(next_tid);
> > + if (!next || !umcg_wakeup_allowed(next)) {
> > + rcu_read_unlock();
> > + return -ESRCH;
> > + }
> > +
> > + /* The result of ttwu below is ignored. */
> > + try_to_wake_up(next, TASK_NORMAL, wake_flags);
> > + rcu_read_unlock();
> > +
> > + return 0;
> > +}
>
> Doesn't try_to_wake_up return different values based on whether or not a
> task
> was woken up? I think it could be useful to propagate that result instead of
> always returning zero. Even if it only helps for debugging.
>
The protocol is to mark the wakee as UMCG_TASK_RUNNING and call ttwu;
if you look at umcg_idle_loop(), you will see that the ordering is set
so that the wakee will indeed either wake or not go to sleep at all,
regardless of whether ttwu succeeds. So in terms of correctness we do
not need to check ttwu result; returning anything different here "for
debugging"? Maybe. If/when this is merged, feel free to send a patch.
Or maybe I'll add this in a next patchset version...
>
>
> > +static bool enqueue_idle_worker(struct umcg_task __user *ut_worker)
> > +{
> > + u64 __user *node = &ut_worker->idle_workers_ptr;
> > + u64 __user *head_ptr;
> > + u64 first = (u64)node;
> > + u64 head;
> > +
> > + if (get_user(head, node) || !head)
> > + return false;
> > +
> > + head_ptr = (u64 __user *)head;
> > +
> > + /* Mark the worker as pending. */
> > + if (put_user(UMCG_IDLE_NODE_PENDING, node))
> > + return false;
> > +
> > + /* Make the head point to the worker. */
> > + if (xchg_user_64(head_ptr, &first))
> > + return false;
> > +
> > + /* Make the worker point to the previous head. */
> > + if (put_user(first, node))
> > + return false;
> > +
> > + return true;
> > +}
>
> If the last two operation return false, whichever task tries to consume the
> list could deadlock, depending on whether or not the ensuing
> force_sig(SIGKILL); reaches the consuming task. Does the force_sig kill
> the task or the entire process. Is it possible to consume this list from a
> different process that shares the memory? I'm wondering if the last
> two "return false" should attempt to retract the
> UMCG_IDLE_NODE_PENDING.
The function will return false only on a memory access error, and the
whole process will be killed as a result. At least this is the
intention. Do you think the code does anything different?
next prev parent reply other threads:[~2021-11-08 4:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 19:57 [PATCH v0.8 0/6] sched,mm,x86/uaccess: implement User Managed Concurrency Groups Peter Oskolkov
2021-11-04 19:57 ` [PATCH v0.8 1/6] sched/umcg: add WF_CURRENT_CPU and externise ttwu Peter Oskolkov
2021-11-04 19:58 ` [PATCH v0.8 2/6] mm, x86/uaccess: add userspace atomic helpers Peter Oskolkov
2021-11-05 6:10 ` kernel test robot
2021-11-09 4:18 ` Tao Zhou
2021-11-04 19:58 ` [PATCH v0.8 3/6] sched/umcg: implement UMCG syscalls Peter Oskolkov
2021-11-05 12:55 ` kernel test robot
2021-11-05 23:48 ` Thierry Delisle
2021-11-08 4:09 ` Peter Oskolkov [this message]
2021-11-06 17:20 ` Tao Zhou
2021-11-07 18:26 ` Peter Oskolkov
2021-11-08 6:57 ` Tao Zhou
2021-11-15 20:11 ` kernel test robot
2021-11-21 21:08 ` Peter Oskolkov
2021-11-04 19:58 ` [PATCH v0.8 4/6] sched/umcg, lib/umcg: implement libumcg Peter Oskolkov
2021-11-07 16:34 ` Tao Zhou
2021-11-07 18:27 ` Peter Oskolkov
2021-11-08 7:12 ` Tao Zhou
2021-11-04 19:58 ` [PATCH v0.8 5/6] sched/umcg: add Documentation/userspace-api/umcg.txt Peter Oskolkov
2021-11-04 19:58 ` [PATCH v0.8 6/6] sched/umcg, lib/umcg: add tools/lib/umcg/libumcg.txt Peter Oskolkov
2021-11-09 8:55 ` [PATCH v0.8 0/6] sched,mm,x86/uaccess: implement User Managed Concurrency Groups Barry Song
2021-11-09 16:31 ` 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='CAFTs51XU1rKqSscdFK69RUCtaKrLJ1r5pdXSBJ1qc3=ZMNorBw@mail.gmail.com' \
--to=posk@posk.io \
--cc=akpm@linux-foundation.org \
--cc=avagin@google.com \
--cc=bsegall@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=posk@google.com \
--cc=tdelisle@uwaterloo.ca \
--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