what is the state of current after an mm_fault occurs?

what is the state of current after an mm_fault occurs?

[jeff shia]

Hello,
       In my opinion, the state of current should be TASK_RUNNING
after an mm_fault occurs.But I donot know why the function of
handle_mm_fault() set the state of current TASK_RUNNING.
/*
 * By the time we get here, we already hold the mm semaphore
 */
int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct * vma,
	unsigned long address, int write_access)
{
	pgd_t *pgd;
	pmd_t *pmd;

	__set_current_state(TASK_RUNNING);
	pgd = pgd_offset(mm, address);

	inc_page_state(pgfault);

	if (is_vm_hugetlb_page(vma))
		return VM_FAULT_SIGBUS;	/* mapping truncation does this. */

	/*
	 * We need the page table lock to synchronize with kswapd
	 * and the SMP-safe atomic PTE updates.
	 */
	spin_lock(&mm->page_table_lock);
	pmd = pmd_alloc(mm, pgd, address);

	if (pmd) {
		pte_t * pte = pte_alloc_map(mm, pmd, address);
		if (pte)
			return handle_pte_fault(mm, vma, address, write_access, pte, pmd);
	}
	spin_unlock(&mm->page_table_lock);
	return VM_FAULT_OOM;
}

any help will be preferred.
Thank you!!

Jeff

Re: what is the state of current after an mm_fault occurs?

[Andrew Morton]

jeff shia <tshxiayu@gmail.com> wrote:
>
>        In my opinion, the state of current should be TASK_RUNNING
>  after an mm_fault occurs.But I donot know why the function of
>  handle_mm_fault() set the state of current TASK_RUNNING.

It was a long time ago.. 2.4.early, perhaps.

There was a place (maybe in the select() code) where we were doing
copy_*_user() while in state TASK_INTERRUPTIBLE.  And iirc there was a
place in the pagefault code which did schedule().  So we would occasionally
hit schedule() in state TASK_INTERRUPTIBLE, when we expected to be in state
TASK_RUNNING.

So we made handle_mm_fault() set TASK_RUNNING to prevent any further such
things.

Re: what is the state of current after an mm_fault occurs?

[jeff shia]

en,
 You mean in some pagefault place we do schedule()?
  Where?
  Thank you !



On 1/5/06, Andrew Morton <akpm@osdl.org> wrote:
> jeff shia <tshxiayu@gmail.com> wrote:
> >
> >        In my opinion, the state of current should be TASK_RUNNING
> >  after an mm_fault occurs.But I donot know why the function of
> >  handle_mm_fault() set the state of current TASK_RUNNING.
>
> It was a long time ago.. 2.4.early, perhaps.
>
> There was a place (maybe in the select() code) where we were doing
> copy_*_user() while in state TASK_INTERRUPTIBLE.  And iirc there was a
> place in the pagefault code which did schedule().  So we would occasionally
> hit schedule() in state TASK_INTERRUPTIBLE, when we expected to be in state
> TASK_RUNNING.
>
> So we made handle_mm_fault() set TASK_RUNNING to prevent any further such
> things.
>
>

Re: what is the state of current after an mm_fault occurs?

[Andrew Morton]

jeff shia <tshxiayu@gmail.com> wrote:
>
> en,

Please see http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt

>  You mean in some pagefault place we do schedule()?

We used to - that should no longer be the case.  The TASK_RUNNING thing is
probably redundant now.

Re: what is the state of current after an mm_fault occurs?

[Christoph Lameter]

On Wed, 4 Jan 2006, Andrew Morton wrote:

> >  You mean in some pagefault place we do schedule()?
> 
> We used to - that should no longer be the case.  The TASK_RUNNING thing is
> probably redundant now.

The page fault handler calls the page allocator in various places 
which may sleep. 

current may not point to the current process if the page fault handler was 
called from get_user_pages.

Re: what is the state of current after an mm_fault occurs?

[Andrew Morton]

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> On Wed, 4 Jan 2006, Andrew Morton wrote:
> 
> > >  You mean in some pagefault place we do schedule()?
> > 
> > We used to - that should no longer be the case.  The TASK_RUNNING thing is
> > probably redundant now.
> 
> The page fault handler calls the page allocator in various places 
> which may sleep. 

That's OK - they should all do set_current_state() before sleeping.  It's
the bare schedule() without previously setting TASK_foo which is the
problem.  We used to do that sort of thing in 2.4 as a lame yield point but
we really shouldn't be doing that at all anywhere any more.

> current may not point to the current process if the page fault handler was 
> called from get_user_pages.

current always points at the current process.  In the situation
ptrace->access_process_vm->get_user_pages->pagefault we'll have mm !=
current->mm.

Re: what is the state of current after an mm_fault occurs?

[Ram Gupta]

On 1/4/06, jeff shia <tshxiayu@gmail.com> wrote:
> en,
>  You mean in some pagefault place we do schedule()?
>   Where?
>   Thank you !

It used to be in earlier kernel at least in 2.5.45 version  .It is
called from pte_alloc_one when it fails to allocate page & waits by
calling schedule_timeout.


Ram