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....@lge.com> > > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
