Messages in this thread | | | Date | Thu, 1 Apr 2004 03:26:25 +0200 | From | Andrea Arcangeli <> | Subject | Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix |
| |
On Wed, Mar 31, 2004 at 05:22:16PM -0800, Andrew Morton wrote: > Andrea Arcangeli <andrea@suse.de> wrote: > > > > @@ -151,8 +151,11 @@ int rw_swap_page_sync(int rw, swp_entry_ > > lock_page(page); > > > > BUG_ON(page->mapping); > > - page->mapping = &swapper_space; > > - page->index = entry.val; > > + ret = add_to_page_cache(page, &swapper_space, entry.val, GFP_KERNEL); > > Doing a __GFP_FS allocation while holding lock_page() is worrisome. It's > OK if that page is private, but how do we know that the caller didn't pass > us some page which is on the LRU?
it _has_ to be private if it's using rw_swap_page_sync. How can a page be in a lru if we're going to execute add_to_page_cache on it? That would be pretty broken in the first place.
> Your patch seems reasonable to run with for now, but to be totally anal > about it, I'll run with the below monstrosity.
It's not needed IMO. We also already bugcheck on page->mapping, if you're scared about the page being in a lru, you can add further bugchecks on PageLru etc.. calling add_to_page_cache on anything that is already visible to the VM in some lru is broken by design and should be forbidden. All the users of swap suspend must work with freshly allocated pages, the page_mapped bugcheck already covers most of the cases. - 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/
| |