On Fri, 28 Feb 2014, Ning Qu wrote: > In shmem/tmpfs, we also use the generic filemap_map_pages, > seems the additional checking is not worth a separate version > of map_pages for it. > > Signed-off-by: Ning Qu <quning@xxxxxxxxxx> > --- > mm/shmem.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/shmem.c b/mm/shmem.c > index 1f18c9d..2ea4e89 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -2783,6 +2783,7 @@ static const struct super_operations shmem_ops = { > > static const struct vm_operations_struct shmem_vm_ops = { > .fault = shmem_fault, > + .map_pages = filemap_map_pages, > #ifdef CONFIG_NUMA > .set_policy = shmem_set_policy, > .get_policy = shmem_get_policy, > -- (There's no need for a 0/1, all the info should go into the one patch.) I expect this will prove to be a very sensible and adequate patch, thank you: it probably wouldn't be worth more effort to give shmem anything special of its own, and filemap_map_pages() is already (almost) coping with exceptional entries. But I can't Ack it until I've tested it some more, won't be able to do so until Sunday; and even then some doubt, since this and Kirill's are built upon mmotm/next, which after a while gives me spinlock lockups under load these days, yet to be investigated. "almost" above because, Kirill, even without Ning's extension to shmem, your filemap_map_page() soon crashes on an exceptional entry: Don't try to dereference an exceptional entry. Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> --- mmotm+kirill/mm/filemap.c 2014-02-28 15:17:50.984019060 -0800 +++ linux/mm/filemap.c 2014-02-28 16:38:04.976633308 -0800 @@ -2084,7 +2084,7 @@ repeat: if (radix_tree_deref_retry(page)) break; else - goto next; + continue; } if (!page_cache_get_speculative(page)) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html