From: Piet Delaney <pdelaney@tensilica.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Piet Delaney <Piet.Delaney@tensilica.com>
Cc: piet delaney <piet.delaney@gmail.com>
Subject: Conceptual difference between VM_CAN_NONLINEAR and VM_NONLINEAR ; path by which VM_NONLINEAR is suppose to be set.
Date: Fri, 5 Mar 2010 02:37:53 -0800 [thread overview]
Message-ID: <4B90DF01.7070107@tensilica.com> (raw)
I'm getting a PANIC while working with mmap'd files due to the
VM_NONLINEAR not being set when working with the pte's. I looked quite
a few places and haven't found a clear explanation of how VM_NONLINEAR
differs conceptually from VM_CAN_NONLINEAR. It looks like VM_CAN_NONLINEAR
is suppose to be set earlier and VM_NONLINEAR later when something in
particular is done. I see it set via the remap_file_pages() system call
but not by mmap() via shmem_mmap().
Our open_posix_testsuite/conformance/interfaces/mmap/6-2.test panic is
avoided with by setting VM_NONLINEAR when the file is mapped but I really
doubt this is appropriate as the test runs fine on i386.
------------------------------------------------------------------------
static int shmem_mmap(struct file *file, struct vm_area_struct *vma)
{
file_accessed(file);
vma->vm_ops = &shmem_vm_ops;
#if 1
/* Wrong but didn't panic */
vma->vm_flags |= (VM_CAN_NONLINEAR|VM_NONLINEAR);
#else
/* Right but panics here via LTP posix mmap/6-2.test */
vma->vm_flags |= VM_CAN_NONLINEAR;
#endif
return 0;
}
-------------------------------------------------------------------------
I was hopping this hack would panic the system and that would help explain
why this approach is wrong, but unfortunately it worked.
Could someone take a minute and explain the conceptual difference of
these two vma flags and the path by which the VM_NONLINEAR flag is
suppose to be set.
-piet
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
reply other threads:[~2010-03-05 10:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4B90DF01.7070107@tensilica.com \
--to=pdelaney@tensilica.com \
--cc=Piet.Delaney@tensilica.com \
--cc=linux-mm@kvack.org \
--cc=piet.delaney@gmail.com \
/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.