![]() | |||||||||||||
Messages in this thread |
On Wed, Aug 27, 2003 at 09:37:25AM +0100, Hugh Dickins wrote: > But I disagree over move_to/from_swap_cache: nothing should > be done there at all. Once you have mapping,index in struct > futex_q, it's irrelevant what tmpfs might be doing to the > page->mapping,page->index of the unmapped page. > I dare not think what locking may be necessary, to manage > the switch from hashing by struct page * to hashing by > swapper_space,index. PG_locked and mapping->page_lock held for writing are needed to switch in general AIUI; adding the vcache/futex locks into the mix sounds like some deep hierarchy, especially since the page is meant to go away in the middle of this process. move_to_swap_cache() has mapping->page_lock held for writing, as is needed; PG_locked is required to add_to_swap() and some other callers are from call chains not checking BUG_ON(!PageLocked(page)) so it sounds as if things are partly there, assuming vcache_lock/futex_lock stay at the bottom. I think it's worth coming up with an answer to in order to remove the DoS scenario and/or resource scalability limitations. -- wli - 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/ | ||||||||||||
| Last update: 2005-03-22 13:48 [from the cache] ©2003-2008 | |||||||||||||