On Tue, Aug 06, 2013 at 05:43:37PM +0900, Joonsoo Kim wrote: > If we fail due to some errorous situation, it is better to quit > without doing heavy work. So changing order of execution. > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > diff --git a/mm/rmap.c b/mm/rmap.c > index a149e3a..c2f51cb 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -278,19 +278,19 @@ int anon_vma_fork(struct vm_area_struct *vma, struct vm_area_struct *pvma) > if (!pvma->anon_vma) > return 0; > > + /* First, allocate required objects */ > + avc = anon_vma_chain_alloc(GFP_KERNEL); > + if (!avc) > + goto out_error; > + anon_vma = anon_vma_alloc(); > + if (!anon_vma) > + goto out_error_free_avc; > + > /* > - * First, attach the new VMA to the parent VMA's anon_vmas, > + * Then attach the new VMA to the parent VMA's anon_vmas, > * so rmap can find non-COWed pages in child processes. > */ > if (anon_vma_clone(vma, pvma)) > - return -ENOMEM; > - > - /* Then add our own anon_vma. */ > - anon_vma = anon_vma_alloc(); > - if (!anon_vma) > - goto out_error; > - avc = anon_vma_chain_alloc(GFP_KERNEL); > - if (!avc) > goto out_error_free_anon_vma; Which heavy work? anon_vma_clone() is anon_vma_chain_alloc() in a loop. Optimizing error paths only makes sense if they are common and you actually could save something by reordering. This matches neither. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>