linux-kernel - Re: mm: migrate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Mar 2007 19:57:58 +0100
From:	Michal Hocko <msts@...nam.cz>
To:	linux-kernel@...r.kernel.org
Cc:	kamezawa.hiroyu@...fujitsu.com
Subject: Re: mm: migrate_pages using

On Mon, Mar 12, 2007 at 04:32:55PM +0900, KAMEZAWA Hiroyuki wrote:
> 
> > When I try to put_page(original) (because I don't want it for this
> > moment) I get to bad_page path and need to reboot...
> > 
> > What am I missing? Am I using migrate_pages correctly?
> > 
> 
> ==
> migrate_pages()					    | refcnt = 2,
> 	-> unmap_and_move()			    | refcnt = 2,
> 		-> try_to_unmap()		    | refcnt = 1
> 		-> move_to_lru()		    | refcnt = 1
> 			-> lru_cache_add()  	    | refcnt = 1
> 				-> page_cache_get() | refcnt = 2
> 				-> pagevec_add()    | refcnt = 2 
> 			-> page_cache_put()         | refcnt 1
> ==

Thanks for clarification. 

> see pagevec codes and release_pages() in swap.c
> per-cpu pagevec caches freed pages for a while. 
> It will be pushed back to the free list when pagevec goes full.

I am not sure about that. When I looked inside lru_cache_add, it will
call __pagevec_lru_add if per-cpu pagevec goes empty and this function
will add all pages to the zone specific inactive list.

I want to prevent that because I need to use original page for other
purposes and so it can't be in inactive list. So I have created little
change to unmap_and_move function so that original page is added back tu
LRU only if required. migrate_pages uses variant with put_lru parameter
and I am using __migrate_pfn_page which uses put_lru=0. See the attached 
patch.
What do you think about that. Is this way correct?

(Please add me to CC, because I am not list member)

Best regards
-- 
Michal Hocko

View attachment "patch" of type "text/plain" (2467 bytes)