linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Hua Zhong" <hzhong@cisco.com>
To: linux-mm@kvack.org
Subject: [Q] task_lock and mm_struct protection
Date: Wed, 28 Aug 2002 12:58:13 -0700	[thread overview]
Message-ID: <FEEFKBEFIEBONNKJABKDGEAAFGAA.hzhong@cisco.com> (raw)
In-Reply-To: <FEEFKBEFIEBONNKJABKDGEPMFFAA.hzhong@cisco.com>

Please cc to me as I am not on the list....

I have a locking question regarding to task_lock and mm_struct.

Typically when we need to read mm_struct of another process, we do something
like:

	task_lock(task);
	mm = task->mm;
	if(mm)
		atomic_inc(&mm->mm_users);
	task_unlock(task);
	if (mm) {
		do_something_time_consuming(mm);
		mmput(mm);
	}

If the do_something_time_consuming() is not really time consuming, we may
just do:

	task_lock(task);
	mm = task->mm;
	if(mm)
		do_something(mm);
	task_unlock(task);

Is this correct? Do I need to do atomic_inc and mmput around do_something?
I.e., does task_lock already protect the mm_struct? I think so, otherwise
anything bad can happen b/t if(mm) and do_something(mm).

However I looked at the code of exit_mm(), and didn't find obvious code that
proves so. It seems to be a race condition to me. This is the code:

static inline void __exit_mm(struct task_struct * tsk)
{
	struct mm_struct * mm = tsk->mm;

	mm_release();
	if (mm) {
		atomic_inc(&mm->mm_count);
		if (mm != tsk->active_mm) BUG();
		/* more a memory barrier than a real lock */
		task_lock(tsk);
		tsk->mm = NULL;
		enter_lazy_tlb(mm, current, smp_processor_id());
		task_unlock(tsk);
		mmput(mm);
	}
}

Apparently, mmput(mm) doesn't require task_lock (it's outside). So could
this happen:

A (exit_mm)                      B (do something)
task_unlock(tsk)
                                 task_lock(tsk)
                                 mm = task->mm;
                                 if(mm)
mmput(mm)
                                     do_something(mm);
                                 task_unlock(task);

In this case even you do atomic_inc/mmput around do_something it wouldn't
work. I think I must be missing something, but it seems to me a race
condition anyway.

Thanks for your reply.

Hua

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

           reply	other threads:[~2002-08-28 19:58 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <FEEFKBEFIEBONNKJABKDGEPMFFAA.hzhong@cisco.com>]

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=FEEFKBEFIEBONNKJABKDGEAAFGAA.hzhong@cisco.com \
    --to=hzhong@cisco.com \
    --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