From: Oleg Nesterov <oleg@redhat.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: akpm@linux-foundation.org, peterz@infradead.org,
paulmck@kernel.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH 1/2] kernel/sys: only rely on rcu for getpriority(2)
Date: Tue, 12 May 2020 18:41:31 +0200 [thread overview]
Message-ID: <20200512164130.GC28621@redhat.com> (raw)
In-Reply-To: <20200512160915.n3plwrwwrlpfqyrs@linux-p48b>
On 05/12, Davidlohr Bueso wrote:
>
> On Tue, 12 May 2020, Oleg Nesterov wrote:
>
> >do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
> >which moves the task from one hlist to another. Yes, it is safe in
> >that task_struct can't go away. But still this is not right because
> >do_each_pid_task() can scan the wrong (2nd) hlist.
>
> Hmm I didn't think about this case, I guess this is also busted in
> ioprio_get(2) then.
agreed...
> >
> >could you explain in details why do you think this PF_EXITING check
> >makes any sense?
>
> My logic was that if the task with the highest prio exited while we
> were iterating the list, it would not be necessarily seen with rcu
> and the syscall would return the highest prio of a task that exited;
> and checking against PF_EXITING was a way to ignore such scenarios
> as we were going to race with it anyway.
Sorry, still can't understand. The PF_EXITING flag is not protected by
tasklist_lock or rcu_lock.
OK, if nothing else. Suppose that a prgp has a single process P, this
proces has already exited but its parent didn't do wait().
Currently getpriority() returns task_nice(P). With the PF_EXITING check
it will return -ESRCH. Hmm?
Oleg.
next prev parent reply other threads:[~2020-05-12 16:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 0:03 [PATCH -next v2 0/2] kernel/sys: reduce tasklist_lock usage get/set priorities Davidlohr Bueso
2020-05-12 0:03 ` [PATCH 1/2] kernel/sys: only rely on rcu for getpriority(2) Davidlohr Bueso
2020-05-12 15:09 ` Oleg Nesterov
2020-05-12 16:09 ` Davidlohr Bueso
2020-05-12 16:41 ` Oleg Nesterov [this message]
2020-05-12 16:58 ` Davidlohr Bueso
2020-05-12 18:16 ` Oleg Nesterov
2020-05-12 0:03 ` [PATCH 2/2] kernel/sys: do not grab tasklist_lock for sys_setpriority(PRIO_PROCESS) Davidlohr Bueso
2020-05-12 16:10 ` Oleg Nesterov
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=20200512164130.GC28621@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.