Messages in this thread | | | From | KOSAKI Motohiro <> | Date | Sun, 26 Jun 2011 00:10:48 +0900 | Subject | Re: [PATCH v2] futex: Fix regression with read only mappings |
| |
>> commit 7485d0d3758e8e6491a5c9468114e74dc050785d (futexes: Remove rw >> parameter from get_futex_key()) in 2.6.33 introduced a user-mode >> regression in that it additionally prevented futex operations on a >> region within a read only memory mapped file. For example this breaks >> workloads that have one or more reader processes doing a FUTEX_WAIT on a >> futex within a read only shared mapping, and a writer processes that has >> a writable mapping issuing the FUTEX_WAKE. >> >> This fixes the regression for futex operations that should be valid on >> RO mappings by trying a RO get_user_pages_fast() when the RW >> get_user_pages_fast() fails so as not to slow down the common path of >> writable anonymous maps and bailing when we used the RO path on >> anonymous memory. > > The goal here is to bail with EFAULT when we use a RO MAP_PRIVATE > mapping on file-backed memory correct?
The problem is, mapping knowledge is contained vma and it's required mma_sem (ie performance hurt). Therefore we have only three ways, maybe.
1) always take mmap_sem and walk vma, likes 2.6.18. (cons. slow) 2) prefault, likes current linus-tree. (cons don't work RO mappings) 3) combination prefault and mmap_sem. likes my previous post. http://groups.google.com/group/linux.kernel/msg/c41c819207e519c2?dmode=source
In other words, you hope to care RO private mapping thing, you can't avoid mmap_sem anymore. unfortunatelly. So, we have to select either cons.
> Final concern: > Are shared memory segments (shmget, etc.) considered "file backed?
It's another corner case. It similar with shared file mapping, but,
PageSwapBacked(page) => 1 PageAnon(page) => 0
Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |