From: Christoph Lameter <cl@linux.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] fix move/migrate_pages() race on task struct
Date: Thu, 23 Feb 2012 12:45:33 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.00.1202231240590.9878@router.home> (raw)
In-Reply-To: <20120223180740.C4EC4156@kernel>
On Thu, 23 Feb 2012, Dave Hansen wrote:
> I think I got lucky that my task_struct was bogus in the oops
> below. It's probably quite feasible that a task_struct could get
> freed back in to the slab, reallocated as another task_struct,
> and then we do these cred checks against a valid, but basically
> random task.
Ok I buy that.
> This patch takes the pid-to-task code along with the credential
> and security checks in sys_move_pages() and sys_migrate_pages()
> and consolidates them. It now takes a task reference in
> the new function and requires the caller to drop it. I
> believe this resolves the race.
And this way its safer?
> diff -puN include/linux/migrate.h~movememory-helper include/linux/migrate.h
> --- linux-2.6.git/include/linux/migrate.h~movememory-helper 2012-02-16 09:59:17.270207242 -0800
> +++ linux-2.6.git-dave/include/linux/migrate.h 2012-02-16 09:59:17.286207438 -0800
> @@ -31,6 +31,7 @@ extern int migrate_vmas(struct mm_struct
> extern void migrate_page_copy(struct page *newpage, struct page *page);
> extern int migrate_huge_page_move_mapping(struct address_space *mapping,
> struct page *newpage, struct page *page);
> +struct task_struct *can_migrate_get_task(pid_t pid);
Could we use something easier to understand? try_get_task()?
> +++ linux-2.6.git-dave/mm/mempolicy.c 2012-02-16 09:59:17.286207438 -0800
> diff -puN mm/migrate.c~movememory-helper mm/migrate.c
> --- linux-2.6.git/mm/migrate.c~movememory-helper 2012-02-16 09:59:17.278207340 -0800
> +++ linux-2.6.git-dave/mm/migrate.c 2012-02-16 09:59:17.286207438 -0800
> @@ -1339,38 +1339,22 @@ static int do_pages_stat(struct mm_struc
> }
>
> /*
> - * Move a list of pages in the address space of the currently executing
> - * process.
> + * If successful, takes a task_struct reference that
> + * the caller is responsible for releasing.
> */
> -SYSCALL_DEFINE6(move_pages, pid_t, pid, unsigned long, nr_pages,
> - const void __user * __user *, pages,
> - const int __user *, nodes,
> - int __user *, status, int, flags)
> +struct task_struct *can_migrate_get_task(pid_t pid)
> {
> - const struct cred *cred = current_cred(), *tcred;
> struct task_struct *task;
> - struct mm_struct *mm;
> - int err;
> -
> - /* Check flags */
> - if (flags & ~(MPOL_MF_MOVE|MPOL_MF_MOVE_ALL))
> - return -EINVAL;
> -
> - if ((flags & MPOL_MF_MOVE_ALL) && !capable(CAP_SYS_NICE))
> - return -EPERM;
> + const struct cred *cred = current_cred(), *tcred;
> + int err = 0;
>
> - /* Find the mm_struct */
> rcu_read_lock();
> task = pid ? find_task_by_vpid(pid) : current;
> if (!task) {
> rcu_read_unlock();
> - return -ESRCH;
> + return ERR_PTR(-ESRCH);
> }
> - mm = get_task_mm(task);
> - rcu_read_unlock();
> -
> - if (!mm)
> - return -EINVAL;
> + get_task_struct(task);
Hmmm isnt the race still there between the determination of the task and
the get_task_struct()? You would have to verify after the get_task_struct
that this is really the task we wanted to avoid the race.
next prev parent reply other threads:[~2012-02-23 18:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 18:07 [RFC][PATCH] fix move/migrate_pages() race on task struct Dave Hansen
2012-02-23 18:45 ` Andi Kleen
2012-02-23 18:45 ` Christoph Lameter [this message]
2012-02-23 19:10 ` Dave Hansen
2012-02-23 19:40 ` Christoph Lameter
2012-02-23 20:04 ` Dave Hansen
2012-02-23 21:41 ` Christoph Lameter
2012-02-24 3:14 ` Eric W. Biederman
2012-02-24 15:20 ` Christoph Lameter
2012-02-24 15:41 ` Eric W. Biederman
2012-02-24 16:48 ` Dave Hansen
2012-02-24 16:54 ` Christoph Lameter
2012-02-24 17:04 ` Dave Hansen
2012-02-24 17:08 ` Christoph Lameter
2012-02-24 17:25 ` Dave Hansen
2012-02-24 17:32 ` Christoph Lameter
2012-02-24 21:37 ` Dave Hansen
2012-02-24 23:12 ` Eric W. Biederman
2012-02-27 16:43 ` Christoph Lameter
2012-02-25 12:13 ` Eric W. Biederman
2012-02-27 19:01 ` Christoph Lameter
2012-02-27 20:15 ` Eric W. Biederman
2012-02-27 22:39 ` Christoph Lameter
2012-02-28 19:30 ` Christoph Lameter
2012-02-29 20:31 ` Andrew Morton
2012-02-29 20:33 ` Christoph Lameter
2012-02-29 20:36 ` Dave Hansen
2012-02-24 17:07 ` KOSAKI Motohiro
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=alpine.DEB.2.00.1202231240590.9878@router.home \
--to=cl@linux.com \
--cc=dave@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).