On Wed, Mar 17, 2010 at 12:15 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Wed, 17 Mar 2010 12:00:15 +0900 > Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > >> On Wed, Mar 17, 2010 at 11:12 AM, KAMEZAWA Hiroyuki >> > BTW, I doubt freeing anon_vma can happen even when we check mapcount. >> > >> > "unmap" is 2-stage operation. >> > 1. unmap_vmas() => modify ptes, free pages, etc. >> > 2. free_pgtables() => free pgtables, unlink vma and free it. >> > >> > Then, if migration is enough slow. >> > >> > Migration(): Exit(): >> > check mapcount >> > rcu_read_lock >> > pte_lock >> > replace pte with migration pte >> > pte_unlock >> > pte_lock >> > copy page etc... zap pte (clear pte) >> > pte_unlock >> > free_pgtables >> > ->free vma >> > ->free anon_vma >> > pte_lock >> > remap pte with new pfn(fail) >> > pte_unlock >> > >> > lock anon_vma->lock # modification after free. >> > check list is empty >> >> check list is empty? >> Do you mean anon_vma->head? >> > yes. > >> If it is, is it possible that that list isn't empty since anon_vma is >> used by others due to >> SLAB_DESTROY_BY_RCU? >> > There are 4 cases. > A) anon_vma->list is not empty because anon_vma is not freed. > B) anon_vma->list is empty because it's freed. > C) anon_vma->list is empty but it's reused. > D) anon_vma->list is not empty but it's reused. E) anon_vma is used for other object. That's because we don't hold rcu_read_lock. I think Mel met this E) situation. AFAIU, even slab page of SLAB_BY_RCU can be freed after grace period. Do I miss something? > >> but such case is handled by page_check_address, vma_address, I think. >> > yes. Then, this corrupt nothing, as I wrote. We just modify anon_vma->lock > and it's safe because of SLAB_DESTROY_BY_RCU. > > >> > unlock anon_vma->lock >> > free anon_vma >> > rcu_read_unlock >> > >> > >> > Hmm. IIUC, anon_vma is allocated as SLAB_DESTROY_BY_RCU. Then, while >> > rcu_read_lock() is taken, anon_vma is anon_vma even if freed. But it >> > may reused as anon_vma for someone else. >> > (IOW, it may be reused but never pushed back to general purpose memory >> > until RCU grace period.) >> > Then, touching anon_vma->lock never cause any corruption. >> > >> > Does use-after-free check for SLAB_DESTROY_BY_RCU correct behavior ? >> >> Could you elaborate your point? >> > > Ah, my point is "how use-after-free is detected ?" > > If use-after-free is detected by free_pages() (DEBUG_PGALLOC), it seems > strange because DESTROY_BY_RCU guarantee that never happens. > > So, I assume use-after-free is detected in SLAB layer. If so, > in above B), C), D) case, it seems there is use-after free in slab's point > of view but it works as expected, no corruption. > > Then, my question is > "Does use-after-free check for SLAB_DESTROY_BY_RCU work correctly ?" > I am not sure Mel found that by DEBUG_PGALLOC. But, E) case can be founded by DEBUG_PGALLOC. > and implies we need this patch ? > (But this will prevent unnecessary page copy etc. by easy check.) > > Thanks, > -Kame > > > > -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href