[lkml]   [2003]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] Futex non-page-pinning fix
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:48    [W:0.122 / U:5.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site